Yes, it felt like the universe provided in this case. I invest in my batch mate. We end up becoming best friends, our wifes become best friends. Biotech VCs are afraid click chemistry isn't hot enough. I lead multiple rounds and become the biggest investor and it becomes my biggest investment. The year I get cancer click-chemistry wins a Nobel prize. And I become a patient. Unbelievable.
This is awesome! I just came back from Cancun with my family, and I was on a WestJet flight. I was taken aback by a) free Wifi and b) how fast it was to support everyone streaming YouTube even. Your tracker let me figure out that it was a WestJet flight; now I know that I have to seek out these flights from now on.
I am having the greatest time professionally with AI coding. I now have the engineering team I’ve always dreamed of. In the last 2 months I have created:
- a web-based app for a F500 client for a workflow they’ve been trying to build for 2 years; won the contract
- built an iPad app for same client for their sales teams to use
- built the engineering agent platform that I’m going to raise funding
I see a lot of people in this thread struggling with AI coding at work. I think my platform is going to save you. The existing tools don’t work anymore, we need to think differently. That said, the old engineering principles still work; heck, they work even better now.
I can't comment about the quality of the code you delivered for your client so I checked your side project. Unfortunately it looks like there is only a landing page (very nice!) but the way from a vibe-coded project to production is usually quite long.
Not wrong at all, that’s why I’m building my own platform for this. That’s also why I haven’t publicly done much on First Cut yet. I’m using my platform to actually build the product, so the intent is that I use my expertise and oversight to ensure it’s not just slop code. So most of the effort has gone into building that platform, which has made building First Cut itself slower. But I’ve actually got my platform running well-enough that now my team is able to get involved, and I can start to work on First Cut again, which means that I should be able to answer your “concern” definitively. I share it.
Having incorporated libghostty into my current web-based project, I can't say enough thanks. I've lived in the terminal since 2003, resisting IDEs, VSCode, everything because I'm a die hard Vim + tmux guy. Vibe coding coming back to the terminal, and being able to use libghostty to facilitate that is a serious vindication of my steadfast resistance to move away from the terminal.
I'm sure you feel the same watching Ghostty become what it has. Big thank you.
Furthermore, it's actually kind of annoying that the LLMs are not better than us, and still benefit from having code properly typed, well-architected, and split into modules/files. I was lamenting this fact the other day; the only reason we moved away from Assembly and BASIC, using GOTOs in a single huge file was because us humans needed the organization to help us maintain context. Turns out, because of how they're trained, so do the LLMs.
So TypeScript types and tests actually do help a lot, simply because they're deterministic guardrails that the LLM can use to check its work and be steered to producing code that actually works.
I don't think LLMs benefit from having code properly typed (at the call definition). It's costly to have to check a possibly remote file to check. The LLM should be able to intuit what the types are at the callsite and elixir has ~strong conventions that LLMs probably take advantage of
Think about fitts law: the fastest place to click under a cursor is the location of the cursor. For an LLM the least context-expensive feedback is no feedback at all.
I think codebases that are strongly typed sometimes have bad habits that "you can get away with" because of the typing and feedback loops, the LLM has learned this.
This is well put. If the LLM gets the type wrong, then we're already discussing a failure scenario with a feedback loop involving back-and-forth changes.
LLMs are not really good at this. The idea that LLMs benefit from TypeScript is a case of people anthropomorphizing AI.
The kinds of mistakes AI makes are very different. It's WAY better than humans at copying stuff verbatim accurately and nailing the 'form' of the logic. What it struggles with is 'substance' because it doesn't have a complete worldview so it doesn't fully understand what we mean or what we want.
LLMs struggle more with requirements engineering and architecture since architecture ties into anticipating requirements changes.
> The kinds of mistakes AI makes are very different.
I think that's a bit extreme. If a programming language has good ergonomics for a short attention span human, it will likely be better for an LLM too.
However, to make good predictions about what an LLM will or will not be good at you should have a good "theory of mind" for the LLMs that will in some ways be different from a human.
I have my own fork here: https://github.com/HorizonXP/voxtral.c where I’m working on a CUDA implementation, plus some other niceties. It’s working quite well so far, but I haven’t got it to match Mistral AI’s API endpoint speed just yet.
There is also another Mistral implementation: https://github.com/EricLBuehler/mistral.rs Not sure what the difference is, but it seems to be just be overall better received.
mistral.rs is more like llama.cpp, it's a full inference library written in rust that supports a ton of models and many hardware architectures, not just mistral models.
how does someone get started with doing things like these (writing inference code/ cuda etc..). any guidance is appreciated. i understand one doesn't just directly write these things and this would require some kind of reading. would be great to receive some pointers.
You know, I love this comment because you are where I was 15 years ago when I naively decided that I wanted to do my master's in medical biophysics and try to use NVIDIA CUDA to help accelerate some of the work that we were doing. So I have a very... storied history with NVIDIA CUDA, but frankly, it's been years since I've actually written C code at all, let alone CUDA.
I have to admit that I wrote none of the code in this repo. I asked Codex to go and do it for me. I did a lot of prompting and guidance through some of the benchmarking and tools that I expected it to use to get the result that I was looking for.
Most of the plans that it generated were outside of my wheelhouse and not something I'm particularly familiar with, but I know it well enough to understand that its plan roughly made sense to me and I just let it go. So the fact that this worked at all is a miracle, but I cannot take credit for it other than telling the AI: what I wanted, how to do it, in loose terms, and helping it when it got stuck.
BTW, everything above was dictated with the code we generated, except for this sentence. And I added breaklines for paragraphs. That's it.
This is actually a really good description of the situation. But I will say, as someone that prided myself on being the second one you described, I am becoming very concerned about how much of my work was misclassified. It does feel like a lot of work I did in the second class is being automated where maybe previously it overinflated my ego.
SWE is more like formula 1 where each race presents a unique combination of track, car, driver, conditions. You may have tools to build the thing, but designing the thing is the main issue. Code editor, linter, test runner, build tools are for building the thing. Understanding the requirements and the technical challenges is designing the thing.
The other day I said something along the lines of, "be interested in the class, not the instance" and I meant to try to articulate a sense of metaprogramming and metaanalysis of a problem.
Y is causing Z and we should fix that. But if we stop and study the problem, we might discover that X causes the class of Y problem so we can fix the entire class, not just the instance. And perhaps W causes the class of X issue. I find my job more and more being about how far up this causality tree can I reason, how confident am I about my findings, and how far up does it make business sense to address right now, later, or ever?
is it? I really fail to see the metaphor as an F1 fan. The cars do not change that much; only the setup does, based on track and conditions. The drivers are fairly consistent through the season. Once a car is built and a pecking order is established in the season, it is pretty unrealistic to expect a team with a slower car to outcompete a team with a faster car, no matter what track it is (since the conditions affect everyone equally).
Over the last 16 years, Red Bull has won 8 times, Mercedes 7 times and Mclaren 1. Which means, regardless of the change in tracks and conditions, the winners are usually the same.
So either every other team sucks at "understanding the requirements and the technical challenges" on a clinical basis or the metaphor doesn't make a lot of sense.
Most projects don’t change that much either. Head over to a big open source project, and more often you will only see tweaks. To be able to do the tweaks require a very good understanding of the whole project (Naur’s theory of programming).
Also in software, we can do big refactors. F1 teams are restricted to the version they’ve put in the first race. But we do have a lot of projects that were designed well enough that they’ve never changed the initial version, just build on top of it.
I wonder about how true this was historically. I imagine race car driving had periods of rapid, exciting innovation. But I can see how a lot of it has probably reached levels of optimization where the rules, safety, and technology change well within the realm of diminishing returns. I'm sure there's still a ridiculous about of R&D though? (I don't really know race car driving)
Sure there is crazy levels of R&D but that mostly happens off season or if there is a change in regulations which happen every 4-5 years usually. Interestingly, this year the entire grid starts with new regs and we don't really know the pecking order yet.
But my whole point was that race to race, it really isn't that much different for the teams as the comment implied and I am still kind of lost how it fits to SWE unless you're really stretching things.
Even then, most teams dont even make their own engines etc.
Do you really think that rainy Canada is the same as Jedddah, or Singapore? And what is the purpose of the free practice sessions?
You’ve got the big bet to design the car between the season (which is kinda the big architectural decisions you make at the beginning of the project). Then you got the refinement over the season, which are like bug fixings and performance tweaks. There’s the parts upgrade, which are like small features added on top of the initial software.
For the next season, you either improve on the design or start from scratch depending on what you’ve learned. In the first case, It is the new version of the software. In the second, that’s the big refactor.
I remember that the reserve drivers may do a lot of simulations to provide data to the engineers.
I’ve been doing Vim + aider, and now Claude Code. Those tools I understood. I never got into Cursor because I’m too old to give up Vim.
Clawd.bot really annoyed me at first. The setup is super tedious and broken and not fun. That’s mostly because I’m too impatient to tinker like I used to.
However, once you tinker, it’s so-so. I don’t think it’s a lot better than Claude Code or anything, but I think it’s just a focused vector for the same AI model, one focused on being your personal assistant. It’s like Claude Code vs. Claude Cowork. They’re the same thing. But given the low cost of creating custom tools, why not give people something that Clawd.bot that gives them focused guardrails?
Anyway, I could end up abandoning all of this too. And it’s all a kludge around things that should really be an API. But I do like that I can run it on my Mac Mini and have it control my desktop. It’ll be a cold day if I let it message for me; I’d rather it write deterministic code that does that, rather than do it directly.
Maybe this is the issue I’m facing. I’m already using Claude, Claude projects, Claude cowork, and Claude code a lot.
I used Claude projects for an entire proposal. That was one of the best proposals I think I’ve ever written.
I’ve been using cowork to help organize my downloads folder, which had 1500 files and I just didn’t have the patience to organize them.
So maybe the differences with Claude bought not as big because I’m able to vibe code my way into things like like integrations and other things that I’ve already been using?
For the app that I wrote to help manage my business, I exposed everything over MCP so I’m able to do things like timesheets and adding and removing people and purchase orders and all that stuff using MCP. So which is why I’m already kind of feeling the magic with my existing stuff maybe?
The one thing in ClawdBot’s favor is the scheduled stuff maybe?
Aider isn't abandoned, but it feels like it's basically in maintenance mode at this point. Updates over the last year
were limited to small improvements and fixes. There are some forks aimed at making it more "agentic" (more like Claude Code, etc). I haven't tried them personally.
Neovim is the only reason I've given vim a serious look. I love Emacs more, but Neovim lets me use any UI on top of it, which means I can have better visual indicators for things I don't know how to do in VIM. Emacs has a GUI but a lot of it is "beyond flat" and it just doesn't translate well to my brain. The best plugin for Emacs for me is still Spacemacs, and no I don't use it with the vim mode stuff, I prefer it with regular emacs commands (for anyone curious).
But Neovim just works for me every time, even vanilla its fine.
I'm a strict Emacs-only user (although sometimes I'll jump into nano for quick edits of isolated files). When I just started out, I went with Spacemacs, which served me pretty well. But there were a few pain points that I can no longer remember, and eventually I gave Doom a try. Haven't looked back.
Amazing project and write up, very good timing too! I’ve been into amateur astronomy since I was 13, owning a few telescopes and spending many hours with family at star parties.
This week I pulled out our big Meade 10” SCT and our small Meade 4” Newtonian to show my 7yo son the moon and Saturn from my parents Bortle 8 backyard. It was wonderful seeing his awe and surprise, and the fact that my parents were there to see it too.
That 10” SCT is on an old fork mount which is motorized but has no GOTO capabilities at all. I’ve also gone down the rabbit hole of researching mount options, thinking I could just buy my way out of it. However, as much as I like the idea of GOTO, a big part of the fun is finding the objects. So I’ve never been able to pull the trigger. I did buy a ZWO 585MC though, I’ve always wanted a dedicated cooled camera.
That said, we have lost way too many hours to trying to find objects. The Telrad isn’t always enough!
I’ve been looking into using my 3D printer and electronics know-how to build my way out of this. I was even thinking of swapping the motors for NEMA 17 steppers.
Then I stumbled upon PiFinder, and I think this project is going to be the exact balance of automation and Push-to guidance that I would like.
It’s a wonderful hobby and I think the latest in 3D printing and PCB manufacturing does mean we’re going to be able to solve a lot of these problems soon.
>However, as much as I like the idea of GOTO, a big part of the fun is finding the objects.
I love reading this because it shows how different people are and how much room there is in the hobby for different interests. I am grateful for goto mounts specifically because finding the object is one of my least favorite parts of it. :D
Irony: I have a 1960s 100mm "Goto" refractor made by what is now the Goto planetarium company of Fuchu City, Tokyo. It's a headache to search for online.
https://www.goto.co.jp/english/about/
Thanks! If you hook your ZWO up to Kstars/EKOS you can use plate-solving in software to find out exactly where your scope is pointed at and then adjust accordingly.
reply