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

351–360 of 382 posts

Re: Two things LLM coding agents are still bad at

#351

Post by consumer451 »

bckmn wrote: post #294
tzs wrote: post #272

Just the other day I hit something that I hadn't realized could happen. It was not code related in my case, but could happen with code or code-related things (and did to a coworker). In a discussion here on HN about why a regulation passed 15 years ago was not as general as it could have been, I speculated [1] that it could be that the technology at the time was not up to handling the general case and so they regulat…

I think asking your questions in that form is akin to "sorting prompts" that I learned about from https://mikecaulfield.substack.com/p/is-the-llm-response-wro... and I have been using successfully when when writing code (e.g. [as a Claude code slash command]( https://www.joshbeckman.org/notes/936274709 )). Essentially, you're asking the LLM to do research and categorize/evaluate that research instead of just giving y…

Thank you so much for sharing this. Myself, and I’m sure many of others, are thinking about these things a lot these days. It’s great to see how someone else is coming at the problem.

I love the grounding back to ~“well even a human would be bad at this if they did it the current LLM way.”

Bringing things back to ground truth human processes is something that is surprisingly unnatural for me to do. And I know better, and I preach doing this, and I still have a hard time doing it.

I know far better, but apparently it is still hard for me to internalize that LLMs are not magic.

Re: Two things LLM coding agents are still bad at

#352

Post by nobodyandproud »

causal wrote: post #217

Similar to the copy/paste issue I've noticed LLMs are pretty bad at distilling large documents into smaller documents without leaving out a ton of detail. Like maybe you have a super redundant doc. Give it to an LLM and it won't just deduplicate it, it will water the whole thing down.

You’d need the correct theory of mind, in order to distill down into the correct summary and details.

Ask the average high school or college student and I doubt they would fare better.

Re: Two things LLM coding agents are still bad at

#353

Post by jimsmart »

squirrel wrote: post #173

A friendly reminder that "refactor" means "make and commit a tiny change in less than a few minutes" (see links below). The OP and many comments here use "refactor" when they actually mean "rewrite". I hear from my clients (but have not verified myself!) that LLMs perform much better with a series of tiny, atomic changes like Replace Magic Literal, Pull Up Field, and Combine Functions Into Transform. [1] https://mart…

Everywhere I've worked over the years (35+), and in conversation with peers (outside of work), refactor means to change the structure of an existing program, while retaining all of the original functionality. With no specificity regarding how big or small such changes may amount to.

With a rewrite usually implying starting from scratch — whether small or large — replacing existing implementations (of functions/methods/modules/whatever), with newly created ones.

Indeed one can refactor a large codebase, without actually rewriting much- if anything at all- of substance.

Maybe one could claim that this is actually lots of micro-refactors — but that doesn't flow particularly well in communication — and if the sum total of it is not specifically a "rewrite", then what collective / overarching noun should be used for the sum total of the plurality of all of these smaller refactorings? — If one spent time making lots of smaller changes, but not actually re-implementing anything... to me, that's not a rewrite, the code has been refactored, even if it is a large piece of code with a lot of structural changes throughout.

Perhaps part of the issue here in this context, is that LLMs don't particularly refactor code anyhow, they generally rewrite (regenerate) it. Which is where many of the subtle issues that are described in other comments here, creep in. The kinds of issues that a human wouldn't necessarily create when refactoring (e.g. changed regex, changed dates, other changes to functionality, etc)

Re: Two things LLM coding agents are still bad at

#354

Post by raw_anon_1111 »

With a statically typed language like C# or Java, there are dozens of refactors that IDEs could do in a guaranteed [1] correct way better than LLMs as far back as 2012.

The canonical products were from JetBrains. I haven’t used Jetbrains in years. But I would be really surprised with the combination of LLMs + a complete understanding of the codebase through static analysis (like it was doing well over a decade ago) and calling a “refactor tool” that it wouldn’t have better results.

[1] before I get “well actuallied” yes I know if you use reflection all bets are off.

Re: Two things LLM coding agents are still bad at

#355

Post by bryantnyc »

rossant wrote: post #37

Recently, I asked Codex CLI to refactor some HTML files. It didn't literally copy and pasted snippets here and there as I would have done myself, it rewrote them from memory, removing comments in the process. There was a section with 40 successive links with complex URLs. A few days later, just before deployment to production, I wanted to double check all 40 links. First one worked. Second one worked. Third one worke…

"...very subtle and silently introduced mistakes are quite dangerous..."

In my view these perfectly serve the purpose of encouraging you to keep burning tokens for immediate revenue as well as potentially using you to train their next model at your expense.

Re: Two things LLM coding agents are still bad at

#356

Post by api »

raw_anon_1111 wrote: post #354

With a statically typed language like C# or Java, there are dozens of refactors that IDEs could do in a guaranteed [1] correct way better than LLMs as far back as 2012. The canonical products were from JetBrains. I haven’t used Jetbrains in years. But I would be really surprised with the combination of LLMs + a complete understanding of the codebase through static analysis (like it was doing well over a decade ago) a…

I used a Borland Java IDE in the 1990s with auto refactoring like “extract method” and global renaming and such.

Dev tools were not bad at all back then. In a few ways they were better than today, like WYSIWYG GUI design which we have wholly abandoned. Old school Visual Basic was a crummy programming language but the GUI builder was better than anything I’m familiar with for a desktop OS today.

Re: Two things LLM coding agents are still bad at

#357

Post by bryantnyc »

yodsanklai wrote: post #153
rossant wrote: post #37

Recently, I asked Codex CLI to refactor some HTML files. It didn't literally copy and pasted snippets here and there as I would have done myself, it rewrote them from memory, removing comments in the process. There was a section with 40 successive links with complex URLs. A few days later, just before deployment to production, I wanted to double check all 40 links. First one worked. Second one worked. Third one worke…

5 minutes ago, I asked Claude to add some debug statements in my code. It also silently changed a regex in the code. It was easily caught with the diff but can be harder to spot in larger changes.

"...Recently, we did an experiment where we had a “red team” deliberately introduce an alignment issue into a model (say, a tendency for the model to exploit a loophole in a task..." https://www.darioamodei.com/post/the-urgency-of-interpretabi...

Anyone care to wager if anthropic is red teaming in production on paying users?

Re: Two things LLM coding agents are still bad at

#358

Post by godelski »

ngruhn wrote: post #312
AIorNot wrote: post #282

Earlier quoted context omitted.

I think we need better code review tools in the age of LLMs - not just sticking another LLM to do a code review on top of the PR Needs to clearly handle the large diffs they produce - anyone have any ideas

I was about to write my own tool for this but then I discovered: git diff --color-moved=dimmed-zebra That shows a lot of code that was properly moved/copied in gray (even if it's an insertion). So gray stuff exactly matches something that was there before. Can also be enabled by default in the git config.

That's a great solution and I'm adding it to my fallback. But also, people might be interested in diff-so-fancy[0]. I also like using batcat as a pager.

[0] https://github.com/so-fancy/diff-so-fancy

Re: Two things LLM coding agents are still bad at

#359

Post by jeswin »

svieira wrote: post #299
jeswin wrote: post #68

Earlier quoted context omitted.

> I wanted it to refactor a parser in a small project This expression tree parser (typescript to sql query builder - https://tinqerjs.org/ ) has zero lines of hand-written code. It was made with Codex + Claude over two weeks (part-time on the side). Having worked on ORMs previously, it would have taken me 4x-10x the time to get to the same state (which also has 100s of tests, with some repetitions). That's a massive…

Quite impressive, thank you for sharing! Question - this loads a 2 MB JS parser written in Rust to turn `x => x.foo` into `{ op: 'project', field: 'foo', target: 'x' }`. But you don't actually allow any complex expressions (and you certainly don't seem to recursively parse references or allow return uplift, e. g. I can't extract out `isOver18` or `isOver(age: int)(Row: IQueryable): IQueryable`). Why did you choose th…

Parsing code with regex is a minefield. You can get it to work with simpler cases, but even that might get complex very quickly with all sorts of formatting preferences that people have. In fact, I'll be very surprised if it can be done with a few regular expressions; so I never gave it much consideration. Additionally, improved subquery support etc is coming, involving deeper recursion.

I could have allowed (I did consider it) functions external to the expression, like isOver18 in your example. But it would have come at the cost of the parser having to look across the code base, and would have required tinqerjs to attach via build-time plugins. The only other way (without plugins) might be to identify callers via Error.stack, and attempting to find the calling JS file.

Re: Two things LLM coding agents are still bad at

#360

Post by DrSiemer »

scottbez1 wrote: post #247
rossant wrote: post #37

Recently, I asked Codex CLI to refactor some HTML files. It didn't literally copy and pasted snippets here and there as I would have done myself, it rewrote them from memory, removing comments in the process. There was a section with 40 successive links with complex URLs. A few days later, just before deployment to production, I wanted to double check all 40 links. First one worked. Second one worked. Third one worke…

The last point I think is most important: "very subtle and silently introduced mistakes" -- LLMs may be able to complete many tasks as well (or better) than humans, but that doesn't mean they complete them the same way, and that's critically important when considering failure modes. In particular, code review is one layer of the conventional swiss cheese model of preventing bugs, but code review becomes much less eff…

When using a reasonably smart llm, code moves are usually fine, but you have to pay attention whenever uncommon words (like urls or numbers) are involved.

It kind of forces you to always put such data in external files, which is better for code organization anyway.

If it's not necessary for understanding the code, I'll usually even leave this data out entirely when passing the code over.

In Python code I often see Gemini add a second h to a random header file extension. It always feels like the llm is making sure that I'm still paying attention.

Post reply on HN