[HN Gopher] Vibing a non-trivial Ghostty feature
___________________________________________________________________
Vibing a non-trivial Ghostty feature
Author : skevy
Score : 314 points
Date : 2025-10-11 14:31 UTC (1 days ago)
(HTM) web link (mitchellh.com)
(TXT) w3m dump (mitchellh.com)
| ColinEberhardt wrote:
| As an aside, the Ghostty recently made it mandatory to disclose
| the use of AI coding tools:
|
| https://github.com/ghostty-org/ghostty/pull/8289
| Shadowmist wrote:
| 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...
| uzername wrote:
| Missing search and weird ssh control character issues are my
| blockers. It's great otherwise!
| PyWoody wrote:
| Reposting my comment from [0]: 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.
|
| [0] https://news.ycombinator.com/item?id=45359239
| senderista wrote:
| This is the blocker for me as well.
| sevg wrote:
| I wonder what people would discuss in all these ghostty posts
| if cmd-f had been present from the start. It's getting a little
| boring hearing about it in every post!
|
| There's interesting things to discuss here about LLM tooling
| and approaches to coding. But of course we'd rather complain
| about cmd-f ;)
| wahnfrieden wrote:
| People don't care about advanced use cases when fundamentals
| are missing
| sevg wrote:
| Advanced use cases? Did you read the article? Making the
| update modal less intrusive isn't an "advanced use case",
| or even prime material for dicussion ;) The article is
| mainly about LLM-assisted coding, regardless of the
| terminal being used.
| do_not_redeem wrote:
| Since we're here, I'm just waiting for them to implement
| drag-and-drop on KDE. Right now it only works on GNOME, and
| although Ghostty is great I'm not going to switch to GNOME
| just for a terminal emulator.
| ghosty141 wrote:
| Missing scrollbars. That and ctrl f are my two annoyances,
| apart from that I love ghostty and use it daily at work.
| jumploops wrote:
| Yeah I quickly (and unfortunately!) switched back to Warp, as
| Ghostty was a little too barebones for my use case.
|
| Word to the wise: Ghostty's default scrollback buffer is only
| ~10MB, but it can easily be changed with a config option.
| JimDabell wrote:
| It's planned for v1.3 in March 2026.
|
| https://ghostty.org/docs/install/release-notes/1-2-0#roadmap
| nevon wrote:
| 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.
| tptacek wrote:
| _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 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!
| ramon156 wrote:
| It's invaluable if you don't know how to work with it
| sjdjsin wrote:
| > This is the part where I simply don't understand the
| objections people have to coding agents
|
| 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.
| tptacek wrote:
| I don't think you read the sentence you're responding to
| carefully enough. The antecedent of "this" isn't "coding
| agents" generally: it's "the value of an agent getting you
| past the blank page stage to a point where the substantive
| core of your feature functions well enough to start iterating
| on". If you want to respond to the argument I made there, you
| have to respond to the actual argument, not a broader one
| that's easier (and much less interesting) to take swipes at.
| sjdjsin wrote:
| 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.
| tptacek wrote:
| Sounds like a very poorly managed team.
| JasonSage wrote:
| I have to agree. My experience working on a team with
| mixed levels of seniority and coding experience is that
| everybody got some increase in productivity and some
| increase in quality.
|
| 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.
| bsder wrote:
| > My experience working on a team with mixed levels of
| seniority and coding experience is that everybody got
| some increase in productivity and some increase in
| quality.
|
| 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.
| roughly wrote:
| In tech? Say it ain't so.
| dingnuts wrote:
| in any organization???
| wilg wrote:
| Not sure what to tell you, if there's a problem you have to
| speak up.
| fn-mote wrote:
| And the longer you wait, the worse it will be.
|
| Also, update your resume and get some applications out so
| you're not just a victim.
| j45 wrote:
| Maybe it's possible to use AI to help review the PRs and
| claim it's the AI making the PR's hyperproductive?
| XenophileJKO wrote:
| 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".
| austinjp wrote:
| 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?
| wahnfrieden wrote:
| The environmental cost of AI is mostly in training afaik.
| The inference energy cost is similar to the google
| searches and reddit etc loads you might do during
| handwritten dev last I checked. This might be completely
| wrong though
| pastel8739 wrote:
| I hear this argument a lot, but it doesn't hold water for
| me. Obviously the use of the AI is the thing that makes
| it worthwhile to do the training, so you obviously need
| to amortize the training cost over the inference. I don't
| know whether or not doing so makes the environmental cost
| substantially higher, though.
| XenophileJKO wrote:
| 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.
| j45 wrote:
| Who said anything about advocating for it.
|
| 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
| yggdrasil_ai wrote:
| > If you can describe why it is slop, an AI can probably
| identify the underlying issues automatically
|
| 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.
| j45 wrote:
| I generally agree that vague 1 shot prompting might vary.
|
| 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.
| matwood wrote:
| What if your coworker was pushing tons of crap code and AI
| didn't exist? How would you deal with the situation then? Do
| that.
| chotmat wrote:
| It's not the same because, with AI, they will likely be
| called anti-ai or anti-progress if they push back against
| it.
| matwood wrote:
| Don't mention AI, just point out why the code is bad.
| I've had co-workers who were vim wizards and others who
| literally hunt and pecked to type. At no point did their
| tools ever come up when reviewing their code. AI is a
| tool like anything else, treat it that way. This also
| means that the OPs default can't be AI == bad; focus on
| the result.
| ttiurani wrote:
| > 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. [...] This is the part where I
| simply don't understand the objections people have to coding
| agents.
|
| 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.
| wahnfrieden wrote:
| OP is considering output productivity, but your comment is
| about personal satisfaction of process
| ttiurani wrote:
| That's true, but when the work is rewarding, I also do it
| quite fast. When it's tedious tweaking, I have force myself
| to keep on typing.
|
| Also: productivity is for machines, not for people.
| simonw wrote:
| Tedious tweaking is my favorite thing to outsource to
| coding agents these days.
| srcreigh wrote:
| Surely there are _some_ things which you can't be arsed to
| take from zero to one?
|
| 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.
| ttiurani wrote:
| > Surely there are some things which you can't be arsed to
| take from zero to one?
|
| 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.
| ipaddr wrote:
| This is an artefact of a language ecosystem that does not
| prioritize getting started. If you picked php/laravel with a
| few commands you are ahead of the days of work piping golang or
| node requires to get to a starting point.
| trenchpilgrim wrote:
| I guess it depends on your business. I rarely start new
| professional projects, but I maintain them for 5+ years - a
| few pieces of production software I started are now in the
| double digits. Ghostty definitely aims to be in that camp of
| software.
| Xss3 wrote:
| My trouble is that the remaining 20% of work takes 80% of my
| time. Ai assistance or not. The edge
| shinycode wrote:
| 100% agree and LLM does have many blind spots and high
| confidence which makes it hard to really trust without
| checking
| jebarker wrote:
| 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.
| scns wrote:
| Cognitive Dissonance. Still there, even in the best of us.
| mitchellh wrote:
| 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!
| jebarker wrote:
| 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.
| mitchellh wrote:
| Yeah understood, I'm not taking it negatively, I just
| genuinely wanted to understand where it came from.
|
| 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.
| Fraterkes wrote:
| What do you not like about LSPs? When you do eg
| refactoring isn't it nice to do operations on something
| that actually reflects the structure of your code?
| mitchellh wrote:
| I use agents for that, and it does a shockingly good job.
| LSPs constantly take up resources, most are poorly
| written, and I have to worry about version compatibility,
| editor compatibility, etc. It's just a very annoying
| ecosystem to me.
|
| 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.
| underdeserver wrote:
| Hmm, most LSPs don't give you a very strong guarantee
| either (when you e.g. rename a variable).
|
| 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.
| jebarker wrote:
| Are you still using the NixOS setup you showed in that
| interview or do you now use the MacOS native ghostty?
| mitchellh wrote:
| I do. I use both!
| moderation wrote:
| The CEO of Sourcegraph Quinn was pretty negative on
| coding agents and agentic development only about 10
| months ago [0]. He had 'agentic stuff' in the Deader
| category (Used rarely, Reviewing it aint worth it). In
| fairness, he did say it was the future but 'is not there
| yet'. Since then, Sourcregraph's code assistant plugin
| Cody has been deprecated an they are all in on agents and
| agentic with Amp.
|
| 0.https://youtu.be/Up6WVA07QdE?si=xU_iu2rQAWoHXPpO&t=898
| sqs wrote:
| Yeah, I said about coding agents, "it's obviously the
| future, but it's not there yet". That talk was from the
| AI Engineer conference in June 2024 (16 months ago).
| Coding agents have come a long way since then!
| matwood wrote:
| > 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!
|
| 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.
| chrisweekly wrote:
| 100% agreed.
|
| > "Put a weight on that bacon!" ?
| simonw wrote:
| Mitchell included a photograph of his breakfast preparation,
| and the bacon was curling up on the frying pan.
| tptacek wrote:
| These are great and everybody should own a bunch of them.
|
| https://www.thechefspress.com/
| chrisweekly wrote:
| Thanks for the tip! (I just ordered a single 13oz one)
| mitchellh wrote:
| I ordered one. Thank you!
| tptacek wrote:
| Order several! They do a cool stacking thing where you
| can stack them at offsets and they lock together! :)
| mitchellh wrote:
| I ordered 3, thank you! lol
| chrisweekly wrote:
| Ah, I see it now. Thanks!
| vunderba wrote:
| _> 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_
|
| 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.
|
| https://imgur.com/a/absqqXI
| harrall wrote:
| 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. 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.
| tptacek wrote:
| 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.
| roughly wrote:
| 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.
| tptacek wrote:
| I can't get past the framing that "people who like the
| act and craftsmanship" feel AI is negative, which
| implicitly defines whatever Mitchell Hashimoto is doing
| as _not_ craftsmanship, which: ghostty is _pure_
| craftsmanship (the only reason anyone would spend months
| writing a new terminal).
|
| No, I think my response was fair, if worded sharply. I
| stand by it.
| blibble wrote:
| > I can't get past the framing that "people who like the
| act and craftsmanship" feel AI is negative
|
| self evident truths have a habit of doing that
| lowboy wrote:
| Your response conflates the categories of people and
| ignores that statements like "people..." can mean
| "(some|most|all) people..." in casual writing/speech. It
| is not a fair response.
|
| 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.
| tptacek wrote:
| No, it didn't mean that. It mean what I thought it meant.
| It was a roundabout way of saying that people who use AI
| aren't interested in craft. The meaning was plain.
| rolisz wrote:
| First, I agree with tptacek that Ghostty is a work of
| craftsmanship. Mitchell is a very talented dev and he
| says he greatly benefits from using AI.
|
| 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).
| vidarh wrote:
| I _love_ coding, and I 'm extremely picky, but I also
| agree with you it's not what I'm being paid to do. And
| even in hobby projects there are plenty of rough drafts
| necessary that I can outsource to an LLM, and then I get
| to refine things afterward, when they're working, and I
| can obsess over details...
|
| 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.
| vidarh wrote:
| They're far more than junior interns. I've had a long
| languishing project to build an ahead-of-time Ruby
| compiler. It started as a toy, and a blog series, and I
| then mostly put it on ice about a decade ago, except for
| very occasional little rounds of hacking. It self-hosts,
| but is very limited.
|
| 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.
| signatoremo wrote:
| > - 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.
|
| 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.
| gertop wrote:
| > 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.
|
| 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?
| SatvikBeri wrote:
| Agree - my personal rule is that I throw away any branches
| where I use LLM-generated code, and I still find it very
| helpful because of the speed of prototyping various ideas.
| roughly wrote:
| I was talking about this the other day with someone - broadly I
| agree with this, they're absolutely fantastic for getting a
| prototype so you can play with the interactions and just have
| something to poke at while testing an idea. There's two
| problems I've found with that, though - the first is that it's
| already a nightmare to convince management that something that
| looks and acts like the thing they want isn't actually ready
| for production, and the vibe coded code is even less ready for
| production than my previous prototyping efforts.
|
| 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.
| benhurmarcel wrote:
| > it's already a nightmare to convince management
|
| Then just don't show it to management, no?
| wilsonnb3 wrote:
| > 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.
| ttul wrote:
| I concur here and would like to add that I worry less about
| sprawl when I know I can ask the agent to rework things in
| future. Yes, it will at times implement the same thing twice in
| two different files. Later, I'll ask it to abstract that away
| to a library. This is frankly how a lot of human coding effort
| goes too.
| stavros wrote:
| I'm the opposite, I find getting started easy and rewarding, I
| don't generally get blocked there. Where I get blocked, after
| almost thirty years of development, is writing the code.
|
| 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.
| tptacek wrote:
| It's funny because the part you find challenging is exactly
| the thing LLM skeptics tend to say accounts for almost none
| of the work (writing the code). I personally find that once
| my project is up on its legs and I'm in flow state, writing
| code is easy and pleasant, but one thing clear from this
| thread is everyone experiences programming a little
| differently.
| stavros wrote:
| Yeah, definitely. I do agree with the skeptics to a point,
| as I don't let the LLM write code without reviewing (it
| makes many mistakes that compound), but I'd still rather
| have it write a function, review and steer, have it write
| another, and so on, than write database models myself for
| the millionth time.
|
| 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!
| tptacek wrote:
| I was just talking about this in a chat today, because
| 'simonw had at some point talked about getting to the
| point where he was letting go of reviewing every line of
| LLM code, and I am _nowhere close_ to that point --- I
| 'll take Claude's word on Tailwind classes as long as the
| HTML looks right, but actual code, I review line-by-line,
| token-by-token, and usually rewrite things, even if just
| for cosmetic reasons.
| stavros wrote:
| Yeah, there's a definite continuum for where LLMs are
| most to least expert. They seem to be fairly OK with JS,
| less so with Python, and C is just a crapshoot.
|
| 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.
| tptacek wrote:
| A friend of mine has been doing embedded C stuff (making
| some kind of LCD wall) and has been blown away by how
| well it's been doing with C --- he went in an LLM skeptic
| (I've been trying to sell him for months, it finally
| clicked).
| stavros wrote:
| Huh, interesting. I wanted to turn an old rotary phone
| into a meeting headset, and I tried to get Opus to make
| me a sound card, but $35 in API costs later, I had no
| sound card.
| vidarh wrote:
| I've had Claude write ~50+ commits of compiler code over
| the last week, and I've mostly not even read it yet. I
| will review the _end result_ at some point, and I do spot
| checks, but for the most part I review whether or not the
| number of specs that passes is going the right way, and
| occasionally butt in when I glance over and spot it doing
| something silly.
|
| 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.
| Jenk wrote:
| I explain it to my peers as "exploiting Cunningham's Law[0]
| with thyself"
|
| 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.
| r_lee wrote:
| About that quote, iirc it's also a technique in Intelligence
| for getting information from people. You say something stupid
| and wrong and they will instantly just correct you on the
| spot and explain why etc.
|
| So it works in real life too
| senderista wrote:
| OT but I can't imagine leaving my laptop open next to a pan of
| sizzling bacon
| commandersaki wrote:
| I really respect Mitchell's response to the OpenAI accident, even
| if it is seen in positive light for ghostty. Can't think of any
| software vendor that actively tries to eliminate nag / annoyances
| (thinking specifically of MS Auto Update), so this is welcome.
|
| 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.
| dlvhdr wrote:
| yeah the usage of "vibe coding" here doesn't fit at all. That
| term is so overused.
| wahnfrieden wrote:
| It has simply evolved from its initial meaning, as language
| does.
| simonw wrote:
| 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...
| mitchellh wrote:
| 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!
| afro88 wrote:
| > 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.
|
| Yep. It's vibe engineering, which simonw coined here:
| https://simonwillison.net/2025/Oct/7/vibe-engineering/
| dlvhdr wrote:
| People are really bad at evaluating whether ai speeds them up or
| slows them down. The main question is, do you enjoy this kind of
| process of working with ai. I personally don't, so I don't use
| it. It's hard for me to believe any claims about productivity
| gains.
| CurleighBraces wrote:
| This is the crux of the discussion. For me the output is a
| greater reward than the input. The faster I can reach the
| output the better.
|
| 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"
| jebarker wrote:
| I like it when it works but I literally had to take a break
| yesterday due to the rage I was feeling from Claude repeatedly
| declaring "I found it!" or "Perfect - found the issue!" before
| totally breaking the code.
| WD-42 wrote:
| This post demonstrates one area where ai agents are a huge win:
| ui frameworks. I have a very similar workflow on an app I'm
| currently developing in Rust and GTK.
|
| 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!
| hoppp wrote:
| I think as long as a human audit passes its good I also generated
| some pretty great code before, but I went in to review every
| single line to make sure
| nextworddev wrote:
| Haven't used Ghostty but why is HN putting it on front page every
| other week? What's the main attraction to it
| wahnfrieden wrote:
| Product merits aside... Its developer is a celebrity figure and
| people here are captivated by the story of a billionaire who
| writes open source without a business model, like we regular
| folks do when we don't have a hustle to focus on
| chrsig wrote:
| > You can see in chats 11 to 14 that we're entering the slop
| zone. The code the agent created has a critical bug, and it's
| absolutely failing to fix it. And I have no idea how to fix it,
| either.
|
| This definitely relaxes my ai-hype anxiety
| dismalaf wrote:
| > 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 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.
| intended wrote:
| This is exactly what I hoped for when someone talks about their
| LLM Enabled coding experience.
|
| - language - product - level of experience / seniority
| chrisweekly wrote:
| > _" You can see in chats 11 to 14 that we're entering the slop
| zone. The code the agent created has a critical bug, and it's
| absolutely failing to fix it. And I have no idea how to fix it,
| either.
|
| 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.
| piazz wrote:
| Such a useful walkthrough.
|
| 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.
| simonw wrote:
| I haven't yet spent any time with it myself, but the impression
| I have been getting is that it is the most credible of the
| vendor-independent terminal coding agents right now.
|
| Claude Code, Codex CLI and Gemini CLI are all (loosely) locked
| to their own models.
| piazz wrote:
| This is good to know. I'll probably play around with it
| sometime in the future.
|
| BTW, appreciate your many great write-ups - they've been
| invaluable for keeping up to date in this space.
| qudat wrote:
| As far as I know it only uses sonnet 4.5
| simonw wrote:
| It's currently Sonnet 4.5 by default but uses GPT-5 for the
| "oracle" second opinion, according to
| https://ampcode.com/manual#oracle
| qudat wrote:
| I'm using it. It's expensive but it's awesome
| d4rkp4ttern wrote:
| Reason to stick with Claude Code or Codex CLI is that they use
| the respective platforms' subscriptions, like Claude Max or
| ChatGPT-Pro. Unless I'm mistaken, with the other cli apps like
| Amp you get charged by token usage which can add up to a lot
| more than the $200/mo that Claude Max 20x or ChatGPT Pro cost.
| xlii wrote:
| Today, for the first time ever, I had to kill a terminal with all
| the tabs because it became unresponsive.
|
| Welp, that explains it. I haven't changed terminal in a while
| anyway...
| osigurdson wrote:
| >> AI is very good at fill-in-the-blank or draw-the-rest-of-the-
| owl.
|
| 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.
| thaumasiotes wrote:
| By the time you've done that, why not repeat it yourself?
|
| 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?
| osigurdson wrote:
| Concretely, I was creating a cli application. I had
| implemented a few commands end-to-end and established some
| solid patterns. I used Codex (i.e. the PR creating flavor) to
| provide instructions and get it to review the existing
| patterns before continuing as asked it to rigorously follow
| them. I had to do about ~10 more things and it worked really
| well. It was easy for me to review and understand because I
| already knew the pattern and it seemed easy for it to get
| right.
|
| 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.
| thaumasiotes wrote:
| > It was easy for me to review and understand because I
| already knew the pattern and it seemed easy for it to get
| right.
|
| 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.
| abstractspoon wrote:
| And the very bit that you admit not being good at - the zero to
| one stage - will remain forever out of reach because you get the
| AI to do the heavy lifting. You have to practise that bit
| yourself, unless of course you never want to be able to do it
| yourself...
| scuff3d wrote:
| > I'm not shipping code I don't understand.
|
| So not vibe coded, but AI assisted.
| zem wrote:
| > Let's set the stage for what lead to this feature (pun
| intended, as you'll see shortly). During a high-profile OpenAI
| keynote, a demo was rudely interrupted by a Ghostty update prompt
|
| 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?
| Too wrote:
| Tangential question. Why does every app still need its own auto-
| update framework? Shouldn't we all rely on app-stores and package
| managers for this?
| ozgrakkurt wrote:
| It is nice to have it on ubuntu for example. So you can install
| latest version by downloading it manually and keep getting
| updates after.
| Too wrote:
| Ubuntu has both Snap and custom APT repositories.
| saagarjha wrote:
| Because the macOS ecosystem is miserable for this.
| _aavaa_ wrote:
| No we shouldn't rely on app stores. That would mean giving up a
| lot of control and putting your app at the whim of the store.
| JCM9 wrote:
| Despite people yelling, vibe coding isn't going away.
|
| 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.
| 113 wrote:
| > Despite people yelling
|
| The "people yelling" are overwhelmingly pro-AI. I find the
| other side to be relatively quiet.
| fainpul wrote:
| > Human receptionists were far better than IVRs and "press 3
| for" automation, but it was cheaper and good enough.
|
| 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.
| logicallee wrote:
| In the first coding session:
|
| 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.
| pawelduda wrote:
| LLMs have brought back my excitement with coding.
|
| 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.
| didibus wrote:
| > I have a toddler at home so my "computer time" is very
| scheduled and very limited
|
| 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.
___________________________________________________________________
(page generated 2025-10-12 23:02 UTC)