Comment by tptacek
3 days ago
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!
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.
> it's already a nightmare to convince management
Then just don’t show it to management, no?
> 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.
The white page problem hits me every time.
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.
OP is considering output productivity, but your comment is about personal satisfaction of process
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.
1 reply →
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.
> 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.
> 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.
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!
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.
9 replies →
> 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.
Cognitive Dissonance. Still there, even in the best of us.
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.
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
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.
> - 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.
> 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?
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.
7 replies →
> 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.
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.
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.
5 replies →
Not sure what to tell you, if there's a problem you have to speak up.
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.
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.
It's not the same because, with AI, they will likely be called anti-ai or anti-progress if they push back against it.
1 reply →
Maybe it's possible to use AI to help review the PRs and claim it's the AI making the PR's hyperproductive?
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".
7 replies →
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.
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.
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!
5 replies →
> 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
My trouble is that the remaining 20% of work takes 80% of my time. Ai assistance or not. The edge
100% agree and LLM does have many blind spots and high confidence which makes it hard to really trust without checking
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.
100% agreed.
> "Put a weight on that bacon!" ?
Mitchell included a photograph of his breakfast preparation, and the bacon was curling up on the frying pan.
These are great and everybody should own a bunch of them.
https://www.thechefspress.com/
4 replies →
Ah, I see it now. Thanks!
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.
It's invaluable if you don't know how to work with it
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.
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.