Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agentic Coding Is a Trap

larsfaye.com

Post reply on HN
Print view View original

381–390 of 403 posts

Re: Agentic Coding Is a Trap

#381

Post by abalashov »

DauntingPear7 wrote: post #200
bigthymer wrote: post #189

Earlier quoted context omitted.

While prescription drug marketing to consumers is an issue in the US, I think the actual problem in this situation is people Googling their issue then coming to the doctor with the conclusion of their investigation instead of letting the doctor do the investigation themselves.

i think this is large part due to the horrific healthcare system we have here in the US. I have personally witnessed family struggle to get help from doctors because they don't interact with a patient's health outside of immediate action items like filling a prescription, writing a summary, charting, writing a referral, etc. They spend 0 time looking into what could actually be wrong with them outside of their immedi…

You stole what I was about to write out from under me. This is exactly it.

Re: Agentic Coding Is a Trap

#382

Post by abalashov »

lgrapenthin wrote: post #144
enigmoid wrote: post #83

> only a skilled developer who's thinking critically, and comfortable operating at the architectural level, can spot issues in the thousands of lines of generated code, before they become a problem. An additional factor: to find issues in generated code, the developer has to care . Many developers (especially at big firms) are already profoundly checked out from their work and are just looking for a way to close thei…

Indeed. Generated code is also harder to read because it violates all semantic expectations that rely on the mental model of a human author. A generated piece of code is linguistically plausible but often unknowingly imitates common idioms so incoherently that the actual bug may be accidentally disguised in a way no sane human (even a bad programmer) could have come up with. Since LLMs have no internal evaluation, as…

> A generated piece of code is linguistically plausible but often unknowingly imitates common idioms so incoherently that the actual bug may be accidentally disguised in a way no sane human (even a bad programmer) could have come up with.

Came here to say this, but you said it for me. When you are an infinite code generator and your only parlour trick, your only hammer, is generation, and every nail is a problem of as-yet-insufficient generation, then generate you shall.

But the cognitive burden of metabolising this ultra-verbose, circuitous, often brute-force excreta is quite a bit higher than thumbing through a (competent) human's relatively terse approach.

Re: Agentic Coding Is a Trap

#383

Post by abalashov »

djmips wrote: post #337
WorldMaker wrote: post #180

Earlier quoted context omitted.

I tried to capture some of my feelings on this on a recent personal blog post/rant. The easiest phrase is that LLMs are "legacy code as a service". They are trained on other people's legacy code. (No one is intentionally feeding LLMs their best proprietary code.) They produce output that is "Day 1 Legacy Code" in the sense that there's no human code owner to take responsibility and you might be able to ask the LLM th…

"legacy code as a service" - that's apt. But would they be better if they trained exclusively on 'good code'? I know I don't know the answer to that question and I get the feeling that few people actually understand how they work enough to feel comfortable with asserting that to be true.

The problem there is the _large_ language model part, the density and the reinforcement of the weights. There's far less good code in the world. ;) These things emit code as well as I do, such as they do, only because they've inhaled essentially the totality of "code in general", not artisanal code.

Re: Agentic Coding Is a Trap

#384

Post by danenania »

FridgeSeal wrote: post #375
danenania wrote: post #366

Earlier quoted context omitted.

It takes very little time to polish now.

Again, provided you either had the skills. Or you’re getting the model to do the polishing, thereby developing no skills of your own, and we’re back to the start.

Getting the model to do it is the skill.

Re: Agentic Coding Is a Trap

#385

Post by danenania »

abalashov wrote: post #376
danenania wrote: post #358

Earlier quoted context omitted.

That sounds pretty much the same as it’s always been? It used to be: “Does the happy path work? Then ship it! There’s no time to make it robust or clean up tech debt.” Now there actually is time to make things robust if you learn how to do it.

That's an adorable idea, but requires willfully ignoring the existence of the Jevons Paradox.

You’re assuming that building something robustly is significantly more time consuming than the “quick and dirty” version. But that’s not really true anymore. You might need to spend another hour or two thinking through the task up front, but the implementation takes roughly the same amount of time either way.

Re: Agentic Coding Is a Trap

#386

Post by abalashov »

danenania wrote: post #385
abalashov wrote: post #376

Earlier quoted context omitted.

That's an adorable idea, but requires willfully ignoring the existence of the Jevons Paradox.

You’re assuming that building something robustly is significantly more time consuming than the “quick and dirty” version. But that’s not really true anymore. You might need to spend another hour or two thinking through the task up front, but the implementation takes roughly the same amount of time either way.

One cannot build something robust just by thinking about it _a priori_, and while this was somewhat at the periphery of the author's argument, it is important.

Re: Agentic Coding Is a Trap

#387

Post by throwaway041207 »

lelanthran wrote: post #365
munksbeer wrote: post #348

Earlier quoted context omitted.

I don't believe those figures. Perhaps we could discuss more if you linked the reports. In any case, I know how these arguments go. It doesn't really matter.

> I don't believe those figures. Perhaps we could discuss more if you linked the reports. No report is going to help because there are no actual figures for token providers at the moment. We'll have to wait for them to IPO before we'll know for sure.

And yet you are citing some concrete report you aren't sharing. The problem with your original comment is you scoped it to subscribers (which I assume is how this unshared report was framed). API billing for enterprises will far surpass that number in individual users. Claude Code is available at my org to every person employed here and that's just shy of 2k people, and I can say with confidence we are not 3% of Anthropics customer base alone.

Re: Agentic Coding Is a Trap

#388

Post by throwaway041207 »

bulbar wrote: post #361
throwaway041207 wrote: post #224

Earlier quoted context omitted.

> 2. AI doesn't need to be perfect, just "good enough", whatever that means for a specific project. More failures while saving hundreds of thousands dollars each year might be acceptable, for example. This I think is the unexplored aspect of what's happening right now. Guardrails around "good enough" systems is where the future value lies. In the future code will never be as good as when the artisans were writing it,…

Validating / Verifying mediocre code is pretty hard as nobody was able to agree what that even means.

If you are working with AI to define the purpose and goal of the change -- which is to say planning how the changes to the code should result in some sort of feature/bugfix/whatever, then planning phase should ask you to define clear success conditions for the code that it writes. These could be otel/datadog metrics, or some kind of funnel metric or some cessation of errors in your APM, whatern. In any case the outcome of the change is what I mean by validate/verify. Mediocre code can solve issues and we can tolerate mediocre code in that sense. The guardrails kick back failing "mediocre" code, it accepts working mediocre code.

And this could easily apply to every change we made by hand before AI, it was just a tedious process to layer these things into code when we were just fixing bugs and whatnot. In an AI writes all the code world adding this kind of stuff as table stakes for a changeset is zero cost, effort wise.

Re: Agentic Coding Is a Trap

#389

Post by danenania »

abalashov wrote: post #386
danenania wrote: post #385

Earlier quoted context omitted.

You’re assuming that building something robustly is significantly more time consuming than the “quick and dirty” version. But that’s not really true anymore. You might need to spend another hour or two thinking through the task up front, but the implementation takes roughly the same amount of time either way.

One cannot build something robust just by thinking about it _a priori_, and while this was somewhat at the periphery of the author's argument, it is important.

You can’t get every detail right up front, but you can build a robust foundation from the beginning.

The argument seems to be that AI is causing managers to demand faster results, and so everything has to be a one-shotted mess of slop that just barely works. My point is that it doesn’t take much longer to build something solid instead. Implementation time and quality/robustness are not tightly coupled in the way they used to be.

Re: Agentic Coding Is a Trap

#390

Post by abalashov »

sandos wrote: post #247
monksy wrote: post #20

I kind of think this article misses the mark a little. There is skill loss from heavy AI use. But I want to acknowledge the awkward elephant in the room. AI Is making people too fast. I don't mean that a faster output is bad. It's a faster output and code rather than a full understanding and experience in producing the code. It's rewarding people who try to talk about business value rather than the people that are bu…

Skill loss is real. BUT, I have been complaining about skill loss to my bosses for literally a decade. So AI is just one problem for me. I was coding less and less every year for some reason. I'm not sure skill loss is such a huge issue, in other words. It might just be a sign that the nature of our work if shifting. Being able to recite the C++ standard and using all the 100s of features correctly will just not be a…

There is an inescapable connection between the two. Knowing that stuff is not _equivalent_ to knowing good architecture, but it's hard to imagine what knowing good architecture would look like without being able to "think in code" through quite a few relatively narrow implementation details. Without that, you won't know the shape of the problem and how to architect around it.
Post reply on HN