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

The AI coding trap

chrisloy.dev

Post reply on HN
Print view View original

281–290 of 424 posts

Re: The AI coding trap

#281

Post by noosphr »

PessimalDecimal wrote: post #34
reb wrote: post #7

I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…

> I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. A software engineer's primary job isn't producing code, but producing a functional software system. Most…

>The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding.

You can describe what the code should do with natural language.

I've found that using literate programming with agent calls to write the tests first, then code, then the human refining the description of the code, and going back to 1 is surprisingly good at this. One of these days I'll get around to writing an emacs mode to automate it because right now it's yanking and killing between nearly a dozen windows.

Of course this is much slower than regular development but you end up with world class documentation and understanding of the code base.

Re: The AI coding trap

#282

Post by Sleaker »

Article seems to cherry pick Microsoft marketing to claim 10% gains, when the Harvard ran study from earlier this year showed a 10% slowdown. Id rather articles point first at the research being done that's agnostic of any corporation trying to push its propaganda if possible.

Re: The AI coding trap

#283

Post by jalopy »

Every time I read stuff like this I honestly wonder if the author is using the same tools I am.

I can have Claude Code bang out everything from boilerplate to a working prototype to a complex algorithm embedded in a very complex and confusing code base. It’s not correct 100% of the time but it’s pretty damn close. And often times it comes up with algorithms I would have never thought of initially.

These things are at least a 10x multiple of my time.

Re: The AI coding trap

#284

Post by jay_kyburz »

PessimalDecimal wrote: post #34
reb wrote: post #7

I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…

> I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The article sort of goes sideways with this idea but pointing out that AI coding robs you a deep understanding of the code it produces is a valid and important criticism of AI coding. A software engineer's primary job isn't producing code, but producing a functional software system. Most…

I can imagine an industry where we describe business rules to apply to data in natural language, and the AI simply provides an executable without source at all.

The role of the programmer would then be to test if the rules are being applied correctly. If not, there are no bugs to fix, you simply clarify the business rules and ask for a new program.

I like to imagine what it must be like for a non technical business owner who employees programmers today. There is a meeting where a process or outcome is described, and a few weeks / months / years a program is delivered. The only way to know if it does what was requested is to poke it a bit and see if it works. The business owner has no metal modal of the code and can't go in and fix bugs.

update: I'm not suggesting I believe AI is anywhere near being this capable.

Re: The AI coding trap

#285

Post by rgarcia »

The article assumes that AI coding is thoughtless, but prompting is writing, and writing is thinking. If you approach AI coding the same way as regular programming, your thinking phase involves crafting a prompt that describes your thoughts.

Re: The AI coding trap

#286

Post by godelski »

johnisgood wrote: post #217
godelski wrote: post #198

Earlier quoted context omitted.

(Adding to your comment, not disagreeing) > The argument is that this technology leads people to be careless. And this will always be a result of human preference optimization. There's a simple fact: humans prefer lies that they don't know are lies over lies that they do know are lies. We can't optimize for an objective truth when that objective truth doesn't exist. So while doing our best to align our models they mu…

I use LLMs for coding and I like it the way I am using it. I do not outsource thinking, and I do not expect it to know what I want without giving it context to my thoughts with regarding to the project. I have written a 1000 LOC program in C using an LLM. It was a success. I have reviewed it "line by line" though, I do not know why I would not do this. Of course it did not spit out 1000 LOC from the get go, we starte…

  > I have written a 1000 LOC program in C using an LLM. 
  > I have reviewed it "line by line" though, I do not know why I would not do this.
1k LOC is not that much. I can easily do this in a day's project.

But it's pretty rare you're going to be able to review every line in a mature project, even if you're developing that project. Those can contain hundreds or even thousands of files with hundreds (hopefully not thousands) of LOC. While it's possible to review every line it's pretty costly in time and it's harder since the code is changing as you're doing this...

Think of it this way, did you also review all the lines of code in all the libraries you used? Why not? The reasoning will be pretty similar. This isn't to say we shouldn't spend more time exploring the code we work with nor that we likely wouldn't benefit from this, but that time is a scarce resource. So the problem is when the LLM is churning out code faster than you can review.

While coding you are hopefully also debugging and thinking. By handing coding over to the LLM you decouple this. So you reduce your time writing lines of code but increase time spent debugging and analyzing. There will be times where this provides gains but IME this doesn't happen in serious code. But yeah, my quick and dirty scripts can be churned out a lot faster. That saves time, but not 10x. At least not for me

Re: The AI coding trap

#287

Post by stein1946 »

reb wrote: post #7

I would love to see an anti-AI take that doesn't hinge on the idea that technology forces people to be lazy/careless/thoughtless. The plan-build-test-reflect loop is equally important when using an LLM to generate code, as anyone who's seriously used the tech knows: if you yolo your way through a build without thought, it will collapse in on itself quickly. But if you DO apply that loop, you get to spend much more ti…

> in every industry where AI has achieved any level of mastery.

Which industries are those? What does that mastery look like?

> There's a divide between people ...

No, there is not. If one is not willing to figure out a couple of ffmpeg flags, comb through k8s controller code to see what is possible and fix that booting error in their VMs then failure in "mental experiences" is certain.

The most successful people I have met in this profession are the ones who absolutely do not tolerate magic and need to know what happens from the moment they press the ON on their machine, till the moment they turn is OFF again.

Re: The AI coding trap

#288

Post by godelski »

Jensson wrote: post #256
johnisgood wrote: post #230

Earlier quoted context omitted.

I do not see how this is always necessarily implied. And should I seriously always assume this is the case? Where are you getting this from? None of these projects people claim to successfully (or not) written with the help from LLM have 10k LOC, let alone >100k. Should they just be ignored because LOC is not >100k? Additionally, why is it that whenever I mention success stories accomplished with the help of LLMs, pe…

> Why? Because small programs are really quick and easy to write, there was never a bottleneck making them and the demand for people to write small programs is very small. The difficulty of writing a program scales super linearly with size, an experienced programmer in his current environment easily writes a 500 line program in a day, but writing 500 meaningful lines to an existing 100k line codebase in a day is not…

  > but writing 500 meaningful lines to an existing 100k line codebase in a day is not easy at all.
I've had plenty of instances where it's taken more than a day to write /one line/ of code! I suspect most experienced devs have also had these types of experiences.

Not because the single line was hard to write but because the context in which it needed to be written.

Typing was never the bottleneck and I'm not sure why this is the main argument for LLMs (e.g. "LLMs save me from the boilerplate). When typing is a bottleneck it seems like it's more likely that the procedure is wrong. Things like libraries, scripts, and skeletons tend to be far better solutions for those problems. In tough cases abstraction can be extremely powerful, but abstraction is a difficult tool to wield.

The bottleneck is the thinking and analyzing.

Re: The AI coding trap

#289

Post by strogonoff »

treyd wrote: post #171
chamomeal wrote: post #136

Earlier quoted context omitted.

Yeah but it’s the same issue. Open source licenses (just like other laws) weren’t designed for the age of LLMs. I’m sure most people don’t care, but I bet a lot of maintainers don’t want their code fed to LLMs!

Intellectual property as a concept wasn't designed for the age of LLM. You have to add a bunch of exceptions to copyright (fair use, first sale) to get it to not immediately lead to scenarios that don't make any intuitive sense. LLMs explode these issues because now you can mechanically manipulate ideas, and this forces to light new contradictions that intellectual property causes.

I agree that commercially operated LLMs undermine the entire idea of IP, but it is one of the problems with them, not with the concept of intellectual property, which is an approximation of what has been organically part of human society motivating innovation since forever: benefits of being an author and degree of ownership over intangible ideas. When societies were smaller and local, it just worked out and you would earn respect and status if you came up with something cool, whereas in a bigger and more global society that relies on the rule of law rather than informal enforcement legal protections are needed to keep things working sort of the same way.

I doubt anyone would consider it a problem if large-scale commercial LLM operators were required to respect licenses and negotiate appropriate usage terms. Okay, maybe with one exception: their investors and shareholders.

Re: The AI coding trap

#290

Post by godelski »

wild_egg wrote: post #273
Jensson wrote: post #256

Earlier quoted context omitted.

> Why? Because small programs are really quick and easy to write, there was never a bottleneck making them and the demand for people to write small programs is very small. The difficulty of writing a program scales super linearly with size, an experienced programmer in his current environment easily writes a 500 line program in a day, but writing 500 meaningful lines to an existing 100k line codebase in a day is not…

There's an argument to be made that this gap is actually highlighting design issues rather than AI limitations. It's entirely possible to have a 100k LOC system be made up of effective a couple hundred 500 line programs that are composed together to great effect. That's incredibly rare but I did once work for a company who had such a system and it was a dream to work in. I have to think AIs are making a massive impac…

  > It's entirely possible to have a 100k LOC system be made up of effective a couple hundred 500 line programs that are composed together to great effect.
I'm confused. Are you imagining a program with 100k LoC is contained in a single file? Because you'd be insane to do such a thing. It's normally a lot of files with not LoC each, which de facto meets this criteria.

You may also wish to look at UNIX Philosophy. The idea that programs should be small and focused. A program should do one thing and do it well. But there's a generalization to this philosophy when you realize a function is a program.

I do agree there's a lot of issues with design these days but I think you've vastly oversimplified the problem.

Post reply on HN