Vibing a non-trivial Ghostty feature
mitchellh.com
mitchellh.com
This right here is the single biggest win for coding agents. I see and directionally agree with all the concerns people have about maintainability and sprawl in AI-mediated projects. I don't care, though, because the moment I can get a project up on its legs, to where I can interact with some substantial part of its functionality and refine it, I'm off to the races. It's getting to that golden moment that constitutes 80% of what's costly about programming for me.
This is the part where I simply don't understand the objections people have to coding agents. It seems so self-evidently valuable --- even if you do nothing else with an agent, even if you literally throw all the code away.
PS
Put a weight on that bacon!
Because I have a coworker who is pushing slop at unsustainable levels, and proclaiming to management how much more productive he is. It’s now even more of a risk to my career to speak up about how awful his PRs are to review (and I’m not the only one on the team who wishes to speak up).
The internet is rife with people who claim to be living in the future where they are now a 10x dev. Making these claims costs almost nothing, but it is negatively effecting mine and many others day to day.
I’m not necessarily blaming these internet voices (I don’t blame a bear for killing a hiker), but the damage they’re doing is still real.
Because agents are good on this one specific axis (which I agree with and use fwiw), there’s no reason to object to them as a whole
My argument is:
The juice isn’t worth the squeeze. The small win (among others) is not worth the amounts of slop devs now have to deal with.
The ones who spend more time developing their agentic coding as a skillset have gotten much better results.
In our team people are also more willing to respond to feedback because nitpicks and requests to restructure/rearchitect are evaluated on merit instead of how time-consuming or boring they would have been to take on.
Is that true? There have been a couple of papers that show that people have the perception that they are more productive because the AI feels like motion (you're "stuck" less often) when in reality it has been a net negative.
Also, update your resume and get some applications out so you’re not just a victim.
Done right you should get mostly reasonable code out of the "execution focused peer".
Should we really advocate for using AI to both create and then destroy huge amounts of data that will never be used?
Edit: Do I advocate for this? 1000%. This isn't crypto burning electricity to make a ledger. This objectively will make the life of the craftsmanship focused engineer easier. Sloppy execution oriented engineers are not a new phenomenon, just magnified with the fire hose that an agentic AI can be.
What can keep up with the scale of it?
We know that AI is more capable by what's input into it for the prompt side so chances are code review might be a little more sensible.
Maybe this comment/idea will be a breakthrough in improving AI coding. :p
I would argue against this. Most of the time the things we find in review are due to extra considerations, often business, architectural etc, things which the AI doesn't have context of and it is quite bothersome to provide this context.
I also feel all of those things can be explained over time into a compendium that is input. For example, every time it is right, or wrong, comment and add it to an .md file. Better yet, have the CLI Ai tool append it.
We know what is included as part of a prompt (like the above) is more accurately paid attention to.
My intent isn't to make more work, it's just to make it easier to highlight the issues with code that's mindlessly generated, or is overly convoluted when a simple approach will do.
That's what's valuable to you. For me the zero to one part is the most rewarding and fun part, because that's when the possibilities are near endless, and you get to create something truly original and new. I feel I'd lose a lot of that if I let an AI model prime me into one direction.
Also: productivity is for machines, not for people.
This isn’t selling your soul; it is possible to let AI scaffold some tedious garbage while also dreaming up cool stuff the old fashioned way.
No, not really: https://news.ycombinator.com/item?id=45232159
> This isn’t selling your soul;
There is a plethora of ethical reasons to reject AI even if it was useful.
It's not FUN building all the scaffolding and setting up build scripts and all the main functions and directory structures.
Nor do I want to use some kind of initialiser or skeleton project, they always overdo things in my opinion, adding too much and too little at the same time.
With AI I can have it whip up an MVP-level happy-paths-only skeleton project in minutes and then I can start iterating with the fun bits of the project.
But, if it is the interview from 2 years ago, it revolved more around autocomplete and language servers. Agentic tooling was still nascent so a lot of what we were seeing back then was basically tab models and chat models.
As the popular quote goes, "When the Facts Change, I Change My Mind. What Do You Do, Sir?"
The facts and circumstances have changed considerably in recent years, and I have too!
They even used the quote as the title of the accompanying blog post.
As I say, I didn’t mean this as a gotcha or anything- I totally agree with the change and I have done similarly. I’ve always disabled autocomplete, tool tips, suggestions etc but now I am actively using Cursor daily.
Yeah this is from 2021 (!!!) and is directly related to LSPs. ChatGPT didn't even get launched until Nov 2022. So I think the quote doesn't really work in the context of today, it's literally from an era where I was looking at faster horses when cars were right around the corner and I had not a damn clue. Hah.
Off topic: I still dislike [most] LSPs and don't use them.
External agent where I can say "rename this field from X to Y" or "rewrite this into a dedicated class and update all callers" and so on works way better. Obviously, you have to be careful reviewing it since its not working at the same level of guarantee an LSP is but its worth it.
I suppose in some languages it's undecidable in the worst case, but it should work in reasonably hygienic codebases.
Also, they tend to freeze or crash for no reason.
This should be everyone's default if we are learning. Not saying that's what the OP did here, but I hate how people dig out something that was said years ago like it's some gotcha. I think it's a bigger issue if people never change their minds about anything because it would show hubris and a lack of learning.
Not only are the suggestions better, but they are presented much less obtrusively now in IDEs. For example it no longer ambushes you with a 500 line suggestion while you are typing, it shows a bit of what it wants to add next and seems to pull away if you are laying down code while ignoring it.
> "Put a weight on that bacon!" ?
AI is an absolute boon for "getting off the ground" by offloading a lot of the boilerplate and scaffolding that one tends to lose enthusiasm for after having to do it for the 99th time.
> AI is excellent at being my muse.
I'm guessing we have a different definition for muse. Though I admit I'm speaking more about writing (than coding) here but for myself, a muse is the veritable fount of creation - the source of ideas.
Feel free to crank the "temperature" on your LLM until the literal and figurative oceans boil off into space, at the end of the day you're still getting the ultimate statistical distillation.
- People who like the act and craftsmanship of coding itself. AI can encourage slop from other engineers and it trivializes the work. AI is a negative.
- People who like general engineering. AI is positive for reducing the amount of (mundane) code to write, but still requires significant high-level architectural guidance. It’s a tool.
- People who like product. AI can be useful for prototyping but won’t won’t be able to make a good product on its own. It’s a tool.
- People who just want to build a MVP. AI is honestly amazing at making something that at least works. It might be bad code but you are testing product fit. Koolaid mode.
That’s why everyone has a totally different viewpoint.
I don't think it's an unfair statement that LLM-generated code typically is not very good - you can work with it and set up enough guard rails and guidance and whatnot that it can start to produce decent code, but out of the box, speed is definitely the selling point. They're basically junior interns.
If you consider an engineer's job to be writing code, sure, you could read OP's post as a shot, but I tend to switch between the personas they're listing pretty regularly in my job, and I think the read's about right.
To the OP's point, if the thing you like doing is actually crafting and writing the code, the LLMs have substantially less value - they're doing the thing you like doing and they're not putting the care into it you normally would. It's like giving a painter an inkjet printer - sure, it's faster, but that's not really the point here. Typically, when building the part of the system that's doing the heavy lifting, I'm writing that myself. That's where the dragons live, that's what's gotta be right, and it's usually not worth the effort to incorporate the LLMs.
If you're trying to build something that will provide long-term value to other people, the LLMs can reduce some of the boilerplate stuff (convert this spec into a struct, create matching endpoints for these other four objects, etc) - the "I build one, it builds the rest" model tends to actually work pretty well and can be a real force multiplier (alternatively, you can wind up in a state where the LLM has absolutely no idea what you're doing and its proposals are totally unhinged, or worse, where it's introducing bugs because it doesn't quite understand which objects are which).
If you've got your product manager hat on, being able to quickly prototype designs and interactions can make a huge, huge difference in what kind of feedback you get from your users - "hey try this out and let me know what you think" as opposed to "would you use this imaginary thing if I built it?" The point is to poke at the toy, not build something durable.
Same with the MVP/technical prototyping - usually the question you're trying to answer is "would this work at all", and letting the LLM crap out the shittiest version of the thing that could possibly work is often sufficient to find out.
The thing is, I think these are all things good engineers _do_. We're not always painting the Sistine Chapel, we also have to build the rest of the building, run the plumbing, design the thing, and try to get buy-in from the relevant parties. LLMs are a tool like any other - they're not the one you pull out when you're painting Adam, but an awful lot of our work doesn't need to be done to that standard.
No, I think my response was fair, if worded sharply. I stand by it.
self evident truths have a habit of doing that
I agree with your frustration with the framing that _all_ people who like the act and craftsmanship feel AI is negative, and the consequence that if one does like AI, then they must not like the act of craftsmanship. Many such people view it as a tool, Mitchell included.
On the other hand I understand your point that some people got into coding because of coding and they like doing that manually. Unfortunately, we're not being paid to do what we like, but to solve problems with code. What we like is usually a hobby. Software engineering had a golden run for 20-30 years where we were paid well to do things we enjoyed doing, but unfortunately that might change. As an analogy, think about woodworking: there's craftsmanship in a nice wood table, but at the end of day I won't pay thousands of dollars for one, when a couple of hundred dollars will buy me a good enough one from IKEA (maybe you're not like that, but the general population is).
To take your table analogy, which I fully agree with, if I wanted to take the effort of crafting a nice wooden table, I'd happily have someone cut the pieces for me and do the basic stuff that doesn't require specific skills, and then spend my time applying the finer details that makes the difference between a basic table and a great table. I get that some people would want to do everything "from scratch", but I'd rather focus on where I can make the most difference.
A week or so ago, I gave Claude a task of making it compile rubyspecs. I then asked it to keep making specs pass. I do need to babysit it, but it's doing debugging and work no junior I've ever worked with could be trusted to do. It knows how to work with gdb, and trace x86 assembler. It understands how to read the code of a complex compiler, and modify code generation and parsers that even I - who wrote it in the first place - sometimes find challenging.
It's currently (as I'm writing this) working its way through adding bignum support. Which in Ruby is tricky because it now no longer splits it in two classes - the code need to handle tagged integers that gets auto-promoted to heap allocated objects, that to the user has the same class. I spent the morning swearing at it, but then reset with a clearer description and it produced an extensive plan, and started working through it.
I'll agree it's not great code without a lot of coaxing, but it's doing stuff that even a lot of senior, highly experienced developers would struggle with.
I will agree it needs oversight, and someone experienced guiding it, like a junior developer would, but if I had junior developers producing things this complex, I'd lock them in a basement and never let them go (okay, maybe not).
One of the hardest things, I find, where I will agree it smells of junior developer sometimes, is that it's impatient (once it even said "this is getting tedious") and skipping ahead instead of carefully testing assumptions and building up a solution step by step if you don't tell it very clearly how to work.
I don't think we disagree that much, btw., I just wanted to describe my recent experience with it - it's been amazing to see, and is changing how I work with LLMs, in terms of giving it plenty of scratchpads and focusing on guiding how it works, making it create an ambitious plan to work to, and getting out of its way more, instead of continuously giving it small tasks and obsessing over reviewing intermediate work product.
What I'm seeing often with this approach is that whenever I see something that annoys me scroll past, it's often fixed before I've even had a chance to tell it off for doing something stupid.
Those who value craftsmanships would value LLM, since they can pick up new languages or frameworks much faster. They can then master the newly acquired skills on their own if preferred, or they can use LLM to help along the way.
> People who like product. AI can be useful for prototyping but won’t won’t be able to make a good product on its own. It’s a tool.
Any serious product often comprises of multiple modules, layers, interfaces. LLM can help greatly with building some of those building blocks. Definitely a useful tool for product building.
That's like saying those who value books would value movie adaptations because they can pick up new stories much faster.
Is it really so alien to you the someone might prefer learning a new language or framework by, gasp, reading its documentation?
The second is that a hand-done prototype still teaches you something about the tech stack and the implementation - yes, the primary purpose is to get it running quickly so you can feel how it works, but there's usually some learning you get on the technical side, and often I've found my prototypes inform the underlying technical direction. With vibe coded prototypes, you don't get this - not only is the code basically unusable, but you really are back to starting from scratch if you decide to move forward - you've tested the idea, but you haven't really tested the tech or design.
I still think they're useful - I'm a big proponent of "prototype early," and we've been able to throw together some surprisingly large systems almost instantly with the LLMs - but I think you've gotta shift your understanding of the process. Non-LLM prototypes tend to be around step 4 or 5 of a hypothetical 10-step production process, LLM prototypes are closer to step 2. That's fine, but you need to set expectations around how much is left to do past the prototype, because it's more than it was before.
Then just don’t show it to management, no?
It sounds like the blank page problem is a big issue for you, so tools that remove it are a big productivity boost.
Not everyone has the same problems, though. Software development is a very personal endeavor.
Just to be clear, I am not saying that people in category A or category B are better/worse programmers. Just that everyone’s workflow is different so everyone’s experience with tools is also different.
The key is to be empathetic and trust people when they say a tool does or doesn’t work for them. Both sides of the LLM argument tend to assume everyone is like them.
I really like building things, but they're all basically putting the same code together in slightly different ways, so the part I find rewarding isn't the coding, it's the seeing everything come together in the end. That's why I really like LLMs, they let me do all the fun parts without any of the boring parts I've done a thousand times before.
It's not that I find it hard, I've just done it so many times that it's boring. Maybe I should be solving different/harder problems, but I don't mind having the LLM write the code, and I'm doing what I like and I'm more productive than ever, so eh!
It depends on the project as well, for throwaway things I'm fine to just let it do whatever it wants, but for projects that I need to last more than a few days, I review everything.
I fully get why people won't trust it, but I'm leaning more and more on reigning it in with specs and tests and process, and then letting it run for extended amounts of time, and then giving it instructions to fix obvious issues, before finally reviewing the result, and letting it fix whatever comes up.
I'll stare blankly at a blank screen/file for hours seeking inspiration, but the moment I have something to criticise I am immediately productive and can focus.
[0]: https://en.wikipedia.org/wiki/Ward_Cunningham#Law
> The best way to get the right answer on the Internet is not to ask a question; it's to post the wrong answer.
So it works in real life too
Also this article shows responsible use of AI when programming; I don't think it fits the original definition of vibe coding that caused hysterics.
He called it "vibing" in the headline, which matches my suspicion that the term "vibe" is evolving to mean anything that uses generative AI, see also Microsoft "vibe working": https://www.microsoft.com/en-us/microsoft-365/blog/2025/09/2...
I'm not baiting for general engagement, I don't really care about that. I'm baiting for people who are extremist on either side of the "vibe" spectrum such that it'd trigger them to read this, because either way I think it could be good for them.
If you're an extreme pro-vibe person, I wanted to give an example of what I feel is a positive usage of AI. There's a lot of extreme vibe hype boys who are... sloppy.
And if you're an extreme anti-vibe person, I wanted to give an example that clearly refutes many criticisms. (Not all, of course, e.g. there's no discussion here one way or another about say... resource usage).
So, sorry!
Yep. It's vibe engineering, which simonw coined here: https://simonwillison.net/2025/Oct/7/vibe-engineering/
It’s not that I don’t know how to implement something, it’s that the agent can do so much of the tedious searching and trial and error that accompanies this ui framework code.
Notice that Mitchell maintains understanding of all the code through the session. It’s because he already understands what he needs to do. This is a far cry from the definition of “vibe coding” I think a lot of people are riding on. There’s no shortcut to becoming an expert.
Loving Ghostty!
https://github.com/ghostty-org/ghostty/issues?q=is%3Aissue%2...
Have you tried the suggestions in https://ghostty.org/docs/help/terminfo#ssh? I don't know what issue you may be experiencing but this solved my issue with using htop in an ssh session.
There’s interesting things to discuss here about LLM tooling and approaches to coding. But of course we’d rather complain about cmd-f ;)
Word to the wise: Ghostty’s default scrollback buffer is only ~10MB, but it can easily be changed with a config option.
https://ghostty.org/docs/install/release-notes/1-2-0#roadmap
That said, it certainly made me appreciate the complexity of such a "basic" feature when I started thinking about how to make this work when tailing a stream of text.
It looks like Mitchell is using an agentic framework called Amp (I’d never heard of it) - does anybody else here use it or tried it? Curious how it stacks up against Claude Code.
Claude Code, Codex CLI and Gemini CLI are all (loosely) locked to their own models.
BTW, appreciate your many great write-ups - they’ve been invaluable for keeping up to date in this space.
I'll often make these few hail mary attempts to fix a bug. If the agent can figure it out, I can study it and learn myself. If it doesn't, it costs me very little. If the agent figures it out and I don't understand it, I back it out. I'm not shipping code I don't understand. While it's failing, I'm also tabbed out searching the issue and trying to figure it out myself."
Awesome characterization ("slop zone"), pragmatic strategy (let it try; research in parallel) and essential principle ("I'm not shipping code I don't understand.")
IMHO this post is gold, for real-world project details and commentary from an expert doing their thing.
https://ampcode.com/threads/T-9fc3eb88-5aa2-45e4-8f6d-03697f...
The user says "Consult the oracle." at the end of the prompt and the AI begins its answer with:
"I'm going to ask the oracle for advice on planning custom UI for Sparkle update notifications in the titlebar."
What does this refer to?
EDIT: Another comment in this thread says "It's currently Sonnet 4.5 by default but uses GPT-5 for the "oracle" second opinion", so I guess that is what it means.
This is pretty much how I use AI. I don't have it in my editor, I always use it in a browser window, but I bounce ideas off it, use it like a better search engine and even if I don't use the exact code it produces I do feel there's some value.
So not vibe coded, but AI assisted.
quite apart from the article itself, I'm reminded of how much we put up with from our operating systems. presentations and screen sharing have been a fact of life for a couple of decades now; why is it so hard to tell the operating system to strictly not allow anything other than that one window access to the screen?
At work, they help me to kickstart a task - taking the first step is very often the hardest part. It helps me grok new codebases and write boring parts.
But side projects is where the real fun starts - I can materialize random ideas extremely quickly. No more hours spent on writing boilerplate or fighting the tooling. I can delegate the parts I'm not good at the agent. Or one-prompt a feature, if I don't like the result or it doesn't work, I roll it back.
I'm slowly wondering if coding AI agents are turning into the best case scenario for workers. Maybe I'm being hopeful haha.
But having something that doesn't make you faster but just lets you be less concentrated and focused and mentally lazier while producing the same amount of work in the same time as a super dedicated and focused session would have. That's best case scenario here.
This is a post by a hugely respected developer (due to his past & current accomplishments), writing about his experiences in how to best leverage an AI coding assistant.
This is definitely the sweet spot imo. Any time I've been able to come up with a solid, hand coded pattern and have AI repeat in several similar areas has been the most rewarding experiences that I have had with it.
I once needed to define a large table of trigrams in C (for the purpose of distinguishing "English" from "not English"). Setting it up looked like this:
1. Download a book from Project Gutenberg.
2. Write something that went through the book character-by-character, and for every character, remembered the trigram ending there.
3. Make the form of "remembering" be "append a line of code to this file that says `array[char1][char2][char3] = 1`".
4. Now I have a really long C file that compiles into the dictionary I want.
It sounds to me kind of like you want to replace step 3 with an LLM. If that's right... what value is the LLM adding?
It worked so well that I am always trying to look for opportunities like this but honestly, it isn't that common. Many times you aren't creating a pattern and repeating - you are creating a new pattern. AI is good to chat with to get ideas and come up with an approach in these situations seems to be more effective to me.
I suggest that you already knowing the pattern actually makes it harder for you to review code that you expect to contain the pattern. You're likely to perceive it as being there whether it is or not. This strikes me as a way of using LLMs that is more dangerous than average.
Relatedly, proofreading your own work is much more error-prone than proofreading someone else's work, precisely because you have a mental model of your own work (created when you produced it) and you're likely to consult the mental model rather than the work.
Welp, that explains it. I haven't changed terminal in a while anyway...
- language - product - level of experience / seniority
This definitely relaxes my ai-hype anxiety
And to clarify, I don't mean output as "this feature works, awesome", but "this feature works, it's maintainable and the code looks as beautiful as I can make it"
Developers whining that they can do it better and that it will ruin software forget that business always goes with the “good enough” option.
Human receptionists were far better than IVRs and “press 3 for” automation, but it was cheaper and good enough. Now very few companies have human phone operators.
SDEs need to come to terms with the fact that the value associated with human coding has been degraded. Salaries don’t just go up forever. Human SDEs aren’t going away, and 10x engineers will still be very valuable, but overall the perceived value of SDEs and their comp as a job family will likely start slide rapidly from this point forward.
The "people yelling" are overwhelmingly pro-AI. I find the other side to be relatively quiet.
Good enough? Depends on who you ask. It was and is clearly terrible for the users (customers). People hate to navigate huge, invisible menus by slowly pressing buttons or speaking single words very clearly, but the business doesn't really care about that and deems it "worth it" for the money saved.
This is a pattern one can find all over the place: make something worse but cheaper, as long as someone else, not the business, bears the cost.