Live data from Hacker News

Vibing a non-trivial Ghostty feature

mitchellh.com

71–80 of 160 posts

Re: Vibing a non-trivial Ghostty feature

#71

Earlier quoted context omitted.

Yes, this. If you can describe why it is slop, an AI can probably identify the underlying issues automatically. Done right you should get mostly reasonable code out of the "execution focused peer".

In climate terms, or even simply in terms of $cost, this very much feels like throwing failing on a bonfire. Should we really advocate for using AI to both create and then destroy huge amounts of data that will never be used?

I don't think it is a long term solution. More like training wheels. Ideally the engineers learn to use AI to produce better code the first time. You just have a quality gate.

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.

Re: Vibing a non-trivial Ghostty feature

#72
post #5

Tip: I very often use AI for inspiration. In this case, I ended up keeping a lot (not all) of the UI code it made, but I will very often prompt an agent, throw away everything it did, and redo it myself (manually!). I find the "zero to one" stage of creation very difficult and time consuming and AI is excellent at being my muse. This right here is the single biggest win for coding agents. I see and directionally agre…

Just this week I watched an interview with Mitchell about his dev setup and when asked about using neovim instead of an IDE he said something along the lines of "I don't want something that writes code for me". I'm not pointing this out as a criticism, but rather that it's worth taking note that an accomplished developer like him sees value in LLMs that he didn't see in previous intellisense-like tooling.

Cognitive Dissonance. Still there, even in the best of us.

Re: Vibing a non-trivial Ghostty feature

#73
post #67
post #64

Earlier quoted context omitted.

People get into this field for very different reasons. - 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. A…

Real subtle. Why not just write "there are good programmers and bad programmers and AI is good for bad programmers and only bad programmers"? Think about what you just said about Mitchell Hashimoto here.

I'm not sure that's a fair take.

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.

Re: Vibing a non-trivial Ghostty feature

#74
post #20
post #16

Earlier quoted context omitted.

My understanding of your argument is: 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.

Sounds like a very poorly managed team.

In tech? Say it ain't so.

Re: Vibing a non-trivial Ghostty feature

#75

Ghostty is awesome and I almost dropped iTerm for it until I hit cmd-f and nothing happened. https://github.com/ghostty-org/ghostty/issues?q=is%3Aissue%2...

Funnily enough, I spent the last weekend implementing search in Ghostty using Claude. There's already a kinda working implementation of the actual searching, so most of the job was just wiring it up to the UI. After two sessions of maybe 10 hours in total, I had basic searching with highlighting and go to next/previous match working in the Linux frontend. The search implementation is explicitly a work in progress though, so not something that's ready for general use.

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.

Re: Vibing a non-trivial Ghostty feature

#76
post #5

Tip: I very often use AI for inspiration. In this case, I ended up keeping a lot (not all) of the UI code it made, but I will very often prompt an agent, throw away everything it did, and redo it myself (manually!). I find the "zero to one" stage of creation very difficult and time consuming and AI is excellent at being my muse. This right here is the single biggest win for coding agents. I see and directionally agre…

Just this week I watched an interview with Mitchell about his dev setup and when asked about using neovim instead of an IDE he said something along the lines of "I don't want something that writes code for me". I'm not pointing this out as a criticism, but rather that it's worth taking note that an accomplished developer like him sees value in LLMs that he didn't see in previous intellisense-like tooling.

Not sure exactly what you're referring to, but I'm guessing it may be this interview I did 2 years ago: https://youtu.be/rysgxl35EGc?t=214 (timestamp linked to LLM-relevant section) I'm genuinely curious because I don't quite remember saying the quote you're saying I did. I'm not denying it, but I'd love to know more of the context. :)

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!

Re: Vibing a non-trivial Ghostty feature

#78
post #62
post #23

Earlier quoted context omitted.

yeah the usage of "vibe coding" here doesn't fit at all. That term is so overused.

Worth noting that Mitchell didn't actually use the term "vibe coding" anywhere in this article. 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'll add the title is a bit of bait. I don't use the word "vibe" (in any of its forms) anywhere outside of the title.

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!

Re: Vibing a non-trivial Ghostty feature

#79
post #5

Tip: I very often use AI for inspiration. In this case, I ended up keeping a lot (not all) of the UI code it made, but I will very often prompt an agent, throw away everything it did, and redo it myself (manually!). I find the "zero to one" stage of creation very difficult and time consuming and AI is excellent at being my muse. This right here is the single biggest win for coding agents. I see and directionally agre…

> 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.

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.

Re: Vibing a non-trivial Ghostty feature

#80

Earlier quoted context omitted.

Just this week I watched an interview with Mitchell about his dev setup and when asked about using neovim instead of an IDE he said something along the lines of "I don't want something that writes code for me". I'm not pointing this out as a criticism, but rather that it's worth taking note that an accomplished developer like him sees value in LLMs that he didn't see in previous intellisense-like tooling.

Not sure exactly what you're referring to, but I'm guessing it may be this interview I did 2 years ago: https://youtu.be/rysgxl35EGc?t=214 (timestamp linked to LLM-relevant section) I'm genuinely curious because I don't quite remember saying the quote you're saying I did. I'm not denying it, but I'd love to know more of the context. :) But, if it is the interview from 2 years ago, it revolved more around autocomplete…

It was this one: https://sourcegraph.com/blog/dev-tool-time-mitchell-hashimot...

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.

Post reply on HN