alt Hacker News> Good developers’ caution about agentic development comes from knowing that built isn’t the same as working in production...I always felt there was something else, another fear hiding behind those obvious ones.
It's not fear. It's experience. I've seen the kind of code agents write. And it's too often crap even when it "works". This isn't about beautiful code. It's about what we've built actually making sense to a, hopefully talented, software engineer.
Maybe more important than that, it's about taking the time to build the mental models that facilitate product development and the next iterations of coding. When agents write all the software, the majority of engineers I've seen, including myself, lose almost all context to what is actually going on at anything but a very high almost laughable level. And they then become almost completely dependent on the agent for the next iteration of development b/c they don't really understand what is there currently.
Does this matter? From a software perspective, it depends on what you are building and for whom.
From a human perspective, it depends on the human. I've seen good developers that I trust historically churn out crap code with agents because it was just too much to review. And there is some kind of weird addiction like thing happening in our brains when using AI that makes it incredibly difficult for us to slow down and review all the code it writes. In part b/c agents are great at crapping out 3K line PRs like it's nobody's business. But it needs to be someone's business to understand what we are shipping for anything but non-trivial projects. And truly understanding 3K line PRs hour after hour is just not sustainable for most of us. Our eyes glaze over and we just ship it because that's what we do now as an industry.
I think wary is the wrong term. I've learned agentic development's strengths and weaknesses. And the tools, as they work currently, churn out code at a rocket's pace that any good software engineer would immediately reject in years past. I don't like their code, I don't like how their code development process interacts with my brain. It's not waryness, it's dislike and mistrust.
So, yes, they can be assistants. And they can even write code. But I think in much smaller chunks than most people are using them these days.
The idea that we should build software factories and/or otherwise just turn agents loose and isolate humans to the product/QA level is insane to me. But I understand why we are here and I realize that a large portion of the business and dev community likes this new model.
I'm hoping that not doing it that way will end up be a competitive advantage in the long run. Both for the software we are producing and for the devs that are creating it.
Replies
Do you review and understand every byte of machine code being generated by your compiler? Do you understand all the implications of how it could interact with the underlying hardware, pipelining and prediction, etc?
Maybe you do, but most of our industry doesn't and hasn't for decades. Isn't this just the next step up the ladder of abstraction?
> Maybe more important than that, it's about taking the time to build the mental models that facilitate product development and the next iterations of coding.
For me this is the big one. When you code by hand something (especially at the start of a project / feature), it gives you times and opportunity to evaluate different approach, like data-structure or overall architecture. When you're given agentic-generated code to review, those choices are already been made implicitly by Claude, and while it give you the impression that you understand the codebase, you actually haven't been able to process the tradeoff.
Of course, not 'hand-generated' code has the same ROI, and when you're about to do something derivative of something you already understand, agentic development is truly a huge productivity gain.
For me this is the difference between 'vibe coding' and 'coding with AI': Am I able to predict in advance the code that Claude is going to generate, and more importantly, am I able to be surprised when Claude doesn't generate the code I thought it would have (sometime for good technical reasons), or am I just looking at plausible-looking code diffs, and accepting thing without being able to understand the impact on the rest of the codebase. This for me is way more important than what percentage of code lines have been generated by AI.
I've had the opportunity to try both approach: one where I was given a vibecoded project and told to maintain it with Claude: I knew the details of some features, but haven't worked with the codebase enough to really understand the architecture, or be able to mentally reason about the codebase when I'm asked a question during a meeting.
On the another re-implementation of the same product, I've been given more leeway to develop how I wanted, so I've handcrafted the first few features in a transversal way (handling the file architecture, the routing, the way data and components are splitted, and how the API calls are handled), and then I've used Claude to generate the other feature (most of them I knew to be derivative of the first one). In the end something like 90% of the code is generated by Claude, but the end result is both much simpler because I knew where things should be simple and where edge case where, and most importantly I trust what I've put in production.