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

Two things LLM coding agents are still bad at

kix.dev

Post reply on HN
Print view View original

41–50 of 382 posts

Re: Two things LLM coding agents are still bad at

#41

Post by habibur »

AllegedAlec wrote: post #13

On a more important level, I found that they still do really badly at even a minorly complex task without extreme babysitting. I wanted it to refactor a parser in a small project (2.5K lines total) because it'd gotten a bit too interconnected. It made a plan, which looked reasonable, so I told it to do this in stages, with checkpoints. It said it'd done so. I asked it "so is the old architecture also removed?" "No, i…

Might be related with what the article was talking. AI can't cut-paste. It deletes the code and then regenerates it at another location instead of cut-paste.

Obviously generated code drift a little from deleted ones.

Re: Two things LLM coding agents are still bad at

#42

Post by quietbritishjim »

freetonik wrote: post #34

I see a pattern in these discussions all the time: some people say how very, very good LLMs are, and others say how LLMs fail miserably; almost always the first group presents examples of simple CRUD apps, frontend "represent data using some JS-framework" kind of tasks, while the second group presents examples of non-trivial refactoring, stuff like parsers (in this thread), algorithms that can't be found in leetcode,…

Yesterday, I got Claude Code to make a script that tried out different point clustering algorithms and visualise them. It made the odd mistake, which it then corrected with help, but broadly speaking it was amazing. It would've taken me at least a week to write by hsnd, maybe longer. It was writing the algorithms itself, definitely not just simple CRUD stuff.

Re: Two things LLM coding agents are still bad at

#43

Post by athrowaway3z »

rconti wrote: post #9

Doing hard things that aren't greenfield? Basically any difficult and slightly obscure question I get stuck with and hope the collective wisdom of the internet can solve?

You don't learn new languages/paradigms/frameworks by inserting it into an existing project.

LLMs are especially tricky because they do appear to work magic on a small greenfield, and the majority of people are doing clown-engineering.

But I think some people are underestimating what can be done in larger projects if you do everything right (eg docs, tests, comments, tools) and take time to plan.

Re: Two things LLM coding agents are still bad at

#44

Post by throw-10-8 »

pimeys wrote: post #40
throw-10-8 wrote: post #23

3. Saying no LLMs will gladly go along with bad ideas that any reasonable dev would shoot down.

I've found codex to be better here than Claude. It has stopped many times and said hey you might be wrong. Of course this changes with a larger context. Claude is just chirping away "You're absolutely right" and making me to turn on caps lock when I talk to it and it's not even noon yet.

i find the chirpy affirmative tone of claude to be rage inducing

Re: Two things LLM coding agents are still bad at

#45

Post by cat-whisperer »

The copy-paste thing is interesting because it hints at a deeper issue: LLMs don't have a concept of "identity" for code blocks—they just regenerate from learned patterns. I've noticed similar vibes when agents refactor—they'll confidently rewrite a chunk and introduce subtle bugs (formatting, whitespace, comments) that copy-paste would've preserved. The "no questions" problem feels more solvable with better prompting/tooling though, like explicitly rewarding clarification in RLHF.

Re: Two things LLM coding agents are still bad at

#46

Post by nxpnsv »

Codex has got me a few times lately, doing what I asked but certainly not what I intended:

- Get rid of these warnings "...": captures and silences warnings instead of fixing them - Update this unit test to relfect the changes "...": changes the code so the outdated test works - The argument passed is now wrong: catches the exception instead of fixing the argument

My advice is to prefer small changes and read everything it does before accepting anything, often this means using the agent actually is slower than just coding...

Re: Two things LLM coding agents are still bad at

#47

Post by brianpan »

the_mitsuhiko wrote: post #27

> LLMs don’t copy-paste (or cut and paste) code. For instance, when you ask them to refactor a big file into smaller ones, they’ll "remember" a block or slice of code, use a delete tool on the old file, and then a write tool to spit out the extracted code from memory. There are no real cut or paste tools. Every tweak is just them emitting write commands from memory. This feels weird because, as humans, we lean on cop…

How is it not clear that it would be beneficial?

To use another example, with my IDE I can change a signature or rename something across multiple files basically instantly. But an LLM agent will take multiple minutes to do the same thing and doesn't get it right.

Re: Two things LLM coding agents are still bad at

#48

Post by freetonik »

quietbritishjim wrote: post #42
freetonik wrote: post #34

I see a pattern in these discussions all the time: some people say how very, very good LLMs are, and others say how LLMs fail miserably; almost always the first group presents examples of simple CRUD apps, frontend "represent data using some JS-framework" kind of tasks, while the second group presents examples of non-trivial refactoring, stuff like parsers (in this thread), algorithms that can't be found in leetcode,…

Yesterday, I got Claude Code to make a script that tried out different point clustering algorithms and visualise them. It made the odd mistake, which it then corrected with help, but broadly speaking it was amazing. It would've taken me at least a week to write by hsnd, maybe longer. It was writing the algorithms itself, definitely not just simple CRUD stuff.

I also got good results for “above CRUD” stuff occasionally. Sorry if I wasn’t clear, I meant to primarily share an observation about vastly different responses in discussions related to LLMs. I don’t believe LLMs are completely useless for non-trivial stuff, nor I believe that they won’t get better. Even those two problems in the linked article: sure, those actions are inherently alien to the LLM’s structure itself, but can be solved with augmentation.

Re: Two things LLM coding agents are still bad at

#49

Post by cheema33 »

nikanj wrote: post #8

4/5 times when Claude is looking for a file, it starts by running bash(dir c:\test /b) First it gets an error because bash doesn’t understand \ Then it gets an error because /b doesn’t work And as LLMs don’t learn from their mistakes, it always spends at least half a dozen tries (e.g. bash(cmd.exe /c dir c:\test /b )) before it figures out how to list files If it was an actual coworker, we’d send it off to HR

Most models struggle in a Windows environment. They are trained on a lot of Unixy commands and not as much on Windows and PowerShell commands. It was frustrating enough that I started using WSL for development when using Windows. That helped me significantly.

I am guessing this because:

1. Most of the training material online references Unix commands. 2. Most Windows devs are used to GUIs for development using Visual Studio etc. GUIs are not as easy to train on.

Side note: Interesting thing I have noticed in my own org is that devs with Windows background strictly use GUIs for git. The rest are comfortable with using git from the command line.

Re: Two things LLM coding agents are still bad at

#50

Post by Certhas »

darkwater wrote: post #17
rkomorn wrote: post #12

Earlier quoted context omitted.

But, just like lots of people expect/want self-driving to outperform humans even on edge cases in order to trust them, they also want "AI" to outperform humans in order to trust it. So: "humans are bad at this too" doesn't have much weight (for people with that mindset). It makes sense to me, at least.

If we had a knife that most of the time cuts a slice of bread like the bottom p50 of humans cutting a slice of bread with their hands, we wouldn't call the knife useful. Ok, this example is probably too extreme, replace the knife with an industrial machine that cut bread vs a human with a knife. Nobody would buy that machine either if it worked like that.

I think this is still too extreme. A machine that cuts and preps food at the same level as a 25th percentile person _being paid to do so_, while also being significantly cheaper would presumably be highly relevant.
Post reply on HN