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

101–110 of 122 posts

Re: Some uncomfortable truths about AI coding agents

#101

Post by stavros »

tpetrina wrote: post #95
dybber wrote: post #38

Earlier quoted context omitted.

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…

One way of framing this is that people that prefer to solve problems are actually bad at tinkering and writing good code. Hence the existence of terrible codebases written by devs thet “liked to solve problems for the customers”. It is not that clear cut that problem-solvers have that in addition to the tinkering part nor it is guaranteed that tinkerers don’t like to solve problems. Two independent axis!

This is a false dichotomy. There are people who prefer solving problems and are very good at coding, because they've been solving problems with code.

Re: Some uncomfortable truths about AI coding agents

#102

Post by frizlab »

stavros wrote: post #100
maplethorpe wrote: post #65

Earlier quoted context omitted.

The best way to have a big picture view of a project is to build a mental model of that project in your head. Coding with LLMs removes that ability, and replaces it with an illusion.

Does the thing work like I want it in the end? Is it fast, reliable, enjoyable to use, maintainable, cheap, efficient, resilient, etc? If so, I don't care if I wrote it by hand or with an LLM. People who think that building something with an LLM somehow dooms the something to mediocrity are engaging in magical thinking. I can simply use as much or as little LLM as will allow me to meet my quality criteria.

You forgot maintainable.

Re: Some uncomfortable truths about AI coding agents

#103

Post by stavros »

frizlab wrote: post #102
stavros wrote: post #100

Earlier quoted context omitted.

Does the thing work like I want it in the end? Is it fast, reliable, enjoyable to use, maintainable, cheap, efficient, resilient, etc? If so, I don't care if I wrote it by hand or with an LLM. People who think that building something with an LLM somehow dooms the something to mediocrity are engaging in magical thinking. I can simply use as much or as little LLM as will allow me to meet my quality criteria.

You forgot maintainable.

Added a few more adjectives and an "etc", to cover all pedantic bases that don't matter to my argument.

Re: Some uncomfortable truths about AI coding agents

#104

Post by raw_anon_1111 »

dijksterhuis wrote: post #84
raw_anon_1111 wrote: post #83

Earlier quoted context omitted.

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 a…

20K lines of code is well within the context window of any modern LLM. But just like no person tries to understand everything and keep the entire context in their brain, neither do modern LLMs.

Also documentation in the form of MD files becomes important to explain the why and the methodology.

Re: Some uncomfortable truths about AI coding agents

#105

Post by catgary »

raw_anon_1111 wrote: post #60
catgary wrote: post #54

Earlier quoted context omitted.

And even then - I still read the code it generates, and if I see a better way of doing something I just step in, write a partial solution, and then sketch out how the complete solution should work.

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”?

Generally speaking, I try to ensure that the LLM is using core abstractions throughout the codebase in a consistent manner. This makes it easier for me to review any changes it makes.

Re: Some uncomfortable truths about AI coding agents

#106

Post by raw_anon_1111 »

catgary wrote: post #105
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”?

Generally speaking, I try to ensure that the LLM is using core abstractions throughout the codebase in a consistent manner. This makes it easier for me to review any changes it makes.

Sort of a devils advocate question. If you write and review your tests and the functional and non functional requirements and the human tests for usability pass, why does the code matter?

Non functional requirements: performance, security, reliability, logging etc?

Re: Some uncomfortable truths about AI coding agents

#107

Post by viktorianer »

catgary wrote: post #105
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”?

Generally speaking, I try to ensure that the LLM is using core abstractions throughout the codebase in a consistent manner. This makes it easier for me to review any changes it makes.

[flagged]

Re: Some uncomfortable truths about AI coding agents

#108

Post by maplethorpe »

stavros wrote: post #100
maplethorpe wrote: post #65

Earlier quoted context omitted.

The best way to have a big picture view of a project is to build a mental model of that project in your head. Coding with LLMs removes that ability, and replaces it with an illusion.

Does the thing work like I want it in the end? Is it fast, reliable, enjoyable to use, maintainable, cheap, efficient, resilient, etc? If so, I don't care if I wrote it by hand or with an LLM. People who think that building something with an LLM somehow dooms the something to mediocrity are engaging in magical thinking. I can simply use as much or as little LLM as will allow me to meet my quality criteria.

You listed "maintainable", but how do you know your project is maintainable, if you yourself have no understanding of the code base? Presumably the reason is that the AI has managed to maintain the project so far, so it follows that it will be able to do so in the future. But that's not a given. It's more of a prayer.

Re: Some uncomfortable truths about AI coding agents

#109

Post by joquarky »

piker wrote: post #43
rbalicki wrote: post #30

The skill atrophy point strikes me as tenuous at best. Obviously, the plural of anecdote is not data, but I find myself able to work on projects of greater complexity than I would have been able to otherwise. 90% of my time is spent going back and forth on Markdown files, discussing the architecture, trade-offs, etc. I don't think it's necessarily impossible to use all this newfound power to ship more sloppier code.…

> I find myself able to work on projects of greater complexity than I would have been able to otherwise Yes. Now turn off the LLM and make an improvement to that code.

No problem. 30+ years of experience isn't going to disappear any time soon.

Re: Some uncomfortable truths about AI coding agents

#110

Post by dwohnitmok »

piker wrote: post #77
dwohnitmok wrote: post #73

Earlier quoted context omitted.

No it's not. Otherwise this part doesn't make sense > in fact, they actually compound the problem by encouraging significantly more usage because if eliminating training costs makes running the model above cost, the problem is helped by significantly more usage not compounded. More usage compounds the problem only if inference is unprofitable. (the article briefly mentions training but that's later).

It made sense to me understanding that you can have a unit-profitable API but lose money on loss-leading campaigns like Code subscriptions. Those losses are amplified by encouraging usage. Perhaps I'm mistaken.

Again, that is a statement about inference time costs, not training costs.
Post reply on HN