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

Some uncomfortable truths about AI coding agents

standupforme.app

Post reply on HN
Print view View original

81–90 of 122 posts

Re: Some uncomfortable truths about AI coding agents

#81

Post by rbalicki »

dybber wrote: post #38
palmotea wrote: post #2

> The role change has been described by some as becoming a sort of software engineering manager, where one writes little or no code oneself but instead supervises a team of AI coding agents as if they are a team of human junior software engineers.... > In reality, though, the code review load for software engineers will gradually increase as fewer and fewer of them are expected to supervise an ever-growing number of…

I think it depends on what you find enjoyable. I think people who like the tinkering and the actual act of coding, debugging, etc. will find it less and less fun to be in this area, but people who like to look at the big picture, and solve problems, will see that they will now be better at both getting overview of larger and larger codebases and that technical debt that was never attainable to solve before can now be…

I'm as nerdy as they come (my current project is the fourth compiler I've worked on), and I absolutely love this new way of working. There's a lot more time spent in discussion with the agent (an extremely frustrating discussion, to be fair). All of a sudden, there's an extremely high payoff to investing in good fundamentals (namely, clarity of requirements, good tools, etc.), which are the things I want to invest in anyway! If you get these fundamentals right, you can let the agent rip and produce hundreds of PRs that are correct, or create workflows that are actually not slop or ship code that is, while not yet as high quality as if you wrote it manually, quite close, at easily five times the speed.

And throughout this, if I'm ever curious about how the ideas relate to some other topic, I can just ask the agent, "Are we designing XYZ right now? Categorically, is it this?" Lots of really cool discussions to be had.

I might be less enthusiastic if I was just shipping CSS changes and the like.

Re: Some uncomfortable truths about AI coding agents

#82

Post by [deleted] »

HendrikHensen wrote: post #61
chris_money202 wrote: post #13

Earlier quoted context omitted.

Exactly, the fun part is when the code works and does what you wanted it to do. Writing code itself is not fun. People forget this because they get small wins / dopamine hits along the way, a clever function, an elegant few lines of code, a bug fix, but the majority of that time coding is just a grind until the end where you get the big dopamine hit.

Fun is not measured objectively. Different people find different things fun. I enjoy writing code very much (in addition to solving big problems; one can enjoy both).

[deleted]

Re: Some uncomfortable truths about AI coding agents

#83

Post by raw_anon_1111 »

dijksterhuis wrote: post #76
raw_anon_1111 wrote: post #60

Earlier quoted context omitted.

Unless the solution is going to be more secure, faster, more stable etc, why does it matter? Will the end user care? “Does it make the beer taste better”?

in a word, maintainability > maintainability is inversely proportional to the amount of time it takes a developer to make a change and the risk that change will break something https://softwareengineering.stackexchange.com/a/134863 i could be wrong, but i'm pretty sure that end-users get upset when a change takes a long time or it ends up breaking something for them. just because people are finding that agents or wha…

What makes you think that AI couldn’t make the same changes without breaking it whether you modify the code or not? And you do have automated unit tests don’t you?

Right now I have a 5000 line monolithic vibe coded internal website that is at most going to be used by 3 people. It mixes Python, inline CSS and Javasript with the API. I haven’t looked at a line of code. My IAM permissions for the Lambda runtime has limited permissions (meaning the code can’t do anything that the permissions won’t allow it to). I used AWS Cognito for authorization and validated the security of the endpoints and I validated the permissions of the database user.

Neither Claude nor Codex have any issues adding pages, features and API endpoints without breaking changes.

By definition, coding agents are the worse they will be right now.

Re: Some uncomfortable truths about AI coding agents

#84

Post by dijksterhuis »

raw_anon_1111 wrote: post #83
dijksterhuis wrote: post #76

Earlier quoted context omitted.

in a word, maintainability > maintainability is inversely proportional to the amount of time it takes a developer to make a change and the risk that change will break something https://softwareengineering.stackexchange.com/a/134863 i could be wrong, but i'm pretty sure that end-users get upset when a change takes a long time or it ends up breaking something for them. just because people are finding that agents or wha…

What makes you think that AI couldn’t make the same changes without breaking it whether you modify the code or not? And you do have automated unit tests don’t you? Right now I have a 5000 line monolithic vibe coded internal website that is at most going to be used by 3 people. It mixes Python, inline CSS and Javasript with the API. I haven’t looked at a line of code. My IAM permissions for the Lambda runtime has limi…

i have a rule of thumb based on past experience. circa 10k per developer involved, reducing as the codebase size increases.

> 5000 line

so that's currently half a developer according to my rule of thumb.

what happens when that gets to 20,000 lines...? that's over the line in my experience for a human who was the person who wrote it. it takes longer to make changes. change that are made increasingly go out in a more and more broken state. etc. etc. more and more tests have to be written for each change to try and stop it going out in a broken state. more work needs to be done for a feature with equal complexity compared to when we started, because now the rest of the codebase is what adds complexity to us making changes. etc. etc. and that gets worse the more we add.

these agent things have a tendency and propensity to add more code, rather than adding the most maintainable code. it's why people have to review and edit the majority of generated code features beyond CRUD webapp functionality (or similar boilerplate). so, given time and more features, 5k --> 10k --> 20k --> ... too much for a single human being if the agent tools are no longer available.

so let's take it to a bit of a hyperbolic conclusion ... what about agents and a 5,000,000 line codebase...? do you think these agents will take the same amount of time to make a change in a codebase of that size versus 5,000 lines? how much more expensive do you think it could get to run the agents at that size? how about increases in error rate when making changes? how many extra tests need to be added for each feature to ensure zero breakage?

do you see my point?

(fyi: the 5 million LoC is a thought experiment to get you to critically think about the problem technical debt related to agents as codebase size increases, i'm not saying your website's code will get that big)

(also, sorry i basically wrote most of this over the 20 minutes or so since i first posted... my adhd is killing me today)

Re: Some uncomfortable truths about AI coding agents

#85

Post by linsys »

palmotea wrote: post #2

> The role change has been described by some as becoming a sort of software engineering manager, where one writes little or no code oneself but instead supervises a team of AI coding agents as if they are a team of human junior software engineers.... > In reality, though, the code review load for software engineers will gradually increase as fewer and fewer of them are expected to supervise an ever-growing number of…

But isn't that what Linux admins said when Cloud and Platform Engineering became a "thing".

Puppet, Chef, Ansible they are taking the fun out of system administration, Cloud it's going to take away my job. But what happened is roles changed, SRE, Platform Engineering, dare I say DevOps engineers (whatever those are) all emerged.

Software engineering is going through he same transformation with the same knee jerk reactions from both sides of the argument. Either AI run rampant with no guardrails like OpenClaw people burning 1000s in tokens, OpenClaw calling them randomly at 2am, etc.. then on the other side of the argument we have a petition asking the Node.js Technical Steering Committee to ban AI-assisted code from Node.js core.

AI is here, it's here to stay, I believe that those of us that will be successful will find the middle ground.

Re: Some uncomfortable truths about AI coding agents

#87

Post by gitaarik »

dijksterhuis wrote: post #10

As someone who worked on “prompt injection” before it was called “prompt injection” for an (unfinished) phd… yeah there is only one surefire 100% fix for “prompt injection”: use deterministic solutions ie not machine learning. ---- addendum in case someone tries to make this commonly made point -- i don't use deterministic here to mean "i've pinned the ML model weights after training". i use it in reference to the pr…

Yeah there's no solution to prompt injection, but prompt injection in itself is not a security risk. It's about what you give the LLM access to. You can give it access to your complete DB and APIs, or you can only allow it to operate on a very specific piece of data.

Re: Some uncomfortable truths about AI coding agents

#88

Post by gitaarik »

norir wrote: post #63

> I recognize that it is reminiscent of a few decades ago when old timers complained about the proliferation of high level programming languages and insisted they would lead to a generation of programmers lacking a proper understanding of how the system behaves beneath all that syntactic sugar and automatic garbage collection. They won’t have the foundational skills necessary to design and build quality software. And…

Yeah people in the past were always more right. The people that built the first processors were much more aware of low level stuff than those so called low level programmers with their fancy compilers.

And before them, the electrical and mechanical engineers, without them we wouldn't even have these processors. We all ultimately are dependent on them.

And like that you can go on and on

Re: Some uncomfortable truths about AI coding agents

#89

Post by teatro »

gruez wrote: post #66
jonah wrote: post #5

Earlier quoted context omitted.

Sounds a lot like "self-driving" cars - "they are good enough 95%+ of the time, you’re not going to pay as much attention as you should". Same thing happens here, you get complacent and miss critical failures or problems. It's also similar in that it "take[s away] many of the fun parts". When I can focus on simply driving it can be engaging and enjoyable - no matter the road or traffic or whatever.

>Sounds a lot like "self-driving" cars - "they are good enough 95%+ of the time, you’re not going to pay as much attention as you should". That might be an issue for supervised "self-driving" cars (eg. tesla FSD), but not really applicable to self driving cars as a whole. Waymo seems to be doing just fine for instance.

Aren’t Waymo‘s 5% covered by some people in the Philippines? [1] And aren’t they still failing occasionally? [2]

[1](https://www.techspot.com/news/111233-waymo-admits-autopilot-...) [2] (https://www.bloomberg.com/news/articles/2026-01-23/waymo-pro...)

Re: Some uncomfortable truths about AI coding agents

#90

Post by medwards666 »

dybber wrote: post #38
palmotea wrote: post #2

> The role change has been described by some as becoming a sort of software engineering manager, where one writes little or no code oneself but instead supervises a team of AI coding agents as if they are a team of human junior software engineers.... > In reality, though, the code review load for software engineers will gradually increase as fewer and fewer of them are expected to supervise an ever-growing number of…

I think it depends on what you find enjoyable. I think people who like the tinkering and the actual act of coding, debugging, etc. will find it less and less fun to be in this area, but people who like to look at the big picture, and solve problems, will see that they will now be better at both getting overview of larger and larger codebases and that technical debt that was never attainable to solve before can now be…

> "I think it depends on what you find enjoyable"

Exactly this. I use agents every day to either produce tests for code I've written according to the guidelines I set out for it, or to produce the boilerplate code (which is seldom enjoyable) before I get to add the cool stuff.

Furthermore, when I inevitably get stuck on a thornier section of new code, or revisiting a codebase which I've not investigated for some time, I can use the agent to provide ideas and suggestions of where/how to start/get unstuck.

Like any tool - it's how you apply it to the job in hand (and ensuring the job is relevant) that counts.

That, and never 100% trusting the output.

Post reply on HN