In this session, Mitchell Hashimoto walks Richard Feldman through his approach to using AI when building Ghostty. Specifically, they went through this recent commit in detail.
You can watch their chat on YouTube or read below for some selected quotes.
Maintaining Architectural Control
"My approach is that I'm more or less the architect of the software project. I still like to come up with the code structure, the expected data flow through the app, where state lives. I give tooling that guidance where it's like, 'I want you to achieve this end goal, but using this shape.”
"If I just say 'this bug exists, please fix it' - it probably would have done it, but it would have done it in a terrible hammer-meets-nail way that isn't maintainable long term."
Prompting Like Coaching Junior Engineers
"The best way I found to coach juniors is to give them a well-scoped problem with a lot of guardrails...it's sort of like bowling with bumpers, so that they can reach the pins with guardrails along the way."
"This is exactly what I would tell a junior engineer that was new on the project, and this was a well-scoped problem for them. I find that when I have junior engineers, sending them off on open-ended problems is a disaster. And AI is sort of in that state right now."
"I sort of treat it as if I had someone that I could efficiently say, 'can you please debug this and figure out why this is happening? Go off and do it.' That's how I try to use AI."
Working in Parallel with Agents
"I very easily could have done these cleanups in the prior three prompts, but I couldn't do those cleanups and concurrently be QA testing the fix. I had deferred this easy work to the AI and the whole time I was still in this context alongside it, but I was running and clicking and stress testing it, and I found a bug."
"A benefit of these AI assisted-tools is you don't need to respond right away. When Claude posts this notification that it wants your attention, I don't need to go to it. If I'm heavily into something, I'll keep doing it."
From Working Code to Maintainable Code
"The bug is fixed, but now let's massage this into what I actually want to see. It's sort of a trade off between, like, do I just go in there manually and do that? In this case, there was just some obvious stuff that it could do real quick to get there."
"All these agents are really good at refactoring. If they're not fixing bugs or introducing new functionality, they're just renaming things and shuffling and restructuring - they're almost perfect. Anytime I ask it to do that, it's always perfect."
"Most of the work I do right now with LLMs is just getting it to more of a senior quality point of view. When I think about how we're going to continue to fix bugs, how we're going to verify this doesn't regress, how other people on the team are going to understand this - it's not very good at that."
Current Limitations with Agents
"Anything more than trivial changes to Zig code bases is still hopeless with that language. The workaround I found is when it's helpful, I have it rewrite its solution in another language that it's good at, whether that's C or Rust or Swift or Python, and then I'll do the conversion back to Zig myself."
"I think it's pretty bad at architectural problems. I think it's still very bad at high performance data structure type work. It's so knowledgeable on standard data structures, but it doesn't understand the data structure in the context of what you're trying to achieve."
Model Selection and Testing
"Sometimes I actually have multiple checkouts of Ghostty - ghostty, ghostty2, ghostty3, ghostty4. I will run different models and different agents on the different code bases on the same task with the same prompt. It's a competition."
"I've so far had the most success with Claude. Gemini was good for a while, but whenever I ask simple questions, it produces a monumental amount of text as a response. It's not efficient to me."