Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Not wary really, but I do tend to micro manage the agent.
I'm no longer considering myself a good developer either, the agent is way better at details. Not so much at following a general pattern that makes sense.
by d--b - > How much can we trust a system when nobody has experience of building it this way?
If humans are no longer reading the LLM outputs and internalizing the codebase themselves, there's no longer much point to source code. The coding assistant might as well take a natural language prompt and directly hand you an ELF binary that passes a test suite. Are companies ready for that?
by curt15 - I’ve seen the opposite. The best devs are aggressively embracing agents - producing more, and at higher quality.by agd
- Because LLM's can do amazing things, but they can also make huge blunders. Claude constantly makes incorrect assumptions, or implements the wrong thing, or claims there is a bug when there is not.....
On the other hand its VERY fast at finding and fixing some bugs, and finding problems before they hit production. Very good at checking things like what API changes an upgrade brings or finding the right answer about a badly documented library, etc.
by graemep - A business ending software failure or security breach can occur from a single feature flag variable or 'minor' parsing bug. Usually its a long sequence of these, but it only takes one.
I've personally experienced week long incidents because someone didn't understand how a system worked and a couple of low impact shortcuts and convenient approaches and minor mistakes all came together to internally DDOS important systems. All reasonable individually, resulted in the majority of the ops team pulling a 70+ hour week and doing live prod cleanups in the middle of the night.... Agents do this faster. Also, they're labor competition, maybe.
- I think this blog post is underbaked. I think it misplaces where the tension is, and also the skiing metaphor is attempting to simplify an explanation that's already simple.
The post describes the tension as being between leaders and developers. I don't really think that's where the tension is. I'm on a small team of all senior devs, and I've seen both sides -- skepticism and full embrace, and leadership was not pushing AI on us at all. On our team, no matter where we're each individually at on adoption, we're all pretty clear-eyed about the upsides and downsides. The upside is absurdly fast code production. The downside is losing touch with every line of code in the codebase.
There's no need to introduce the skiing metaphor, because the problem is simple: it's the devs' necks on the line when the system goes down or a customer record goes missing. When you get a call at 4 in the morning from the CEO, "Let me ask someone (AI)" isn't an acceptable answer. It's your job to know the failure modes like the back of your hand and be able to diagnose and rightsize in minutes. We've spent our whole careers guarding against those failures by agonizing over every line of code that goes into the product. With that understanding, it's pretty obvious why senior devs are hesitant to adopt something new without a clear picture of how they can be sure that the program isn't going to go down under load, isn't going to drop or mangle customer records, and when one of those things inevitably does happen, how to recover quickly. In a nutshell, job #1 for a senior dev is to account for every failure, and this becomes much harder when an automated system is pushing through 10x as much code.
I'm one of the devs who has chosen to adopt AI. As I reflect on that, I think the reason I'm willing to do so is because I have a level of certainty that I can work the pipeline to safely introduce more changes, faster. So far, I am getting mixed results, but that's not deterring me from continuing to try to reach an optimal point on the tradeoff curve.
by x3haloed - > They are hesitant to take their hand off the wheel because they don’t have full confidence the agents have the right guardrails in place to run off on their own.
This is not a new problem, I've had this problem every summer when a new batch of interns show up.
As they say, if an intern can bring down production, it is not the intern's fault.
The interns are generally so much better than me at writing code, but they're not the best at "software development" (I call it "software gardening").
My training regime is to push them up the next 4 leadership levels from "writing code" - delegation, negotiation, vision and inspiration.
Agents are barely at delegation, with multi-agent harnesses.
They don't negotiate with you, they say yes.
Their vision is limited to the context you gave and most of their output is uninspiring (you can smell "Claude did this" on a UX design pattern easily).
But the humans, they've been thrust into delegation on day 1 & unless you've been a tech-lead manager, you probably haven't exercised that skill yet. Even if you have done that, the way agents work is not exactly how humans work [1] in terms of incentives or even try something they think won't work.
If you've been a good IC for years, the company could always afford to hire a human who specializes in those skills and suddenly you've been promoted to a new role without a pay bump or even a choice.
Most of the "Let's add agents and go faster" is basically adding more manpower to a project behind schedule and the payback is missing because that causes communication gaps & dropped messages.
by gopalv - For me it breaks the rule of "Network of trust".
Software works because someone is accountable for it. Pair Programming, Test Driven Development, and now Agentic coding all to one degree or another damage the network of trust.
- Pair Programming (There is no one person accountable for the change.) - Test Driven Development (The test pass, so my software is good) - Agentic Coding (My prompt was good, so my software is good)
AI is great for software development... As long as you review and understand each change it makes. Because YOU are going to be held accountable for what the software does.
by treespace8