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

371–380 of 382 posts

Re: Two things LLM coding agents are still bad at

#371

Post by hansmayer »

laterium wrote: post #306
jsjshxnsbs wrote: post #103

Earlier quoted context omitted.

I'll take the L when llms can actually do my job to the level I expect. Llms can do some of my work but they are tiring they make mistakes and they absolutely get confused by a sufficiently complex and large codebase. Quite frankly, not being able to discuss the pros and the cons of a technology with other engineers absolutely hinders innovation. A lot of discoveries come out of mistakes. Stop being so small minded.

Why is the bar for it to do your job or completely replace you? It's a tool. If it makes you 5% better at your job, then great. There's a recent study showing it has 15-20% productivity benefits: not completely useless, not 10x. I hope we can have nuance in the conversation.

...and then there was also a recent MIT study showing it was making everyone less productive. The bar is there because this is how all the AI grifters have been selling this technology - no less than end of work itself. Why should we not hold them accountable for over-promising and under-delivering? Or is that reserved just for the serfs?

Re: Two things LLM coding agents are still bad at

#372

Post by mbesto »

IanCal wrote: post #263
mbesto wrote: post #254

Earlier quoted context omitted.

> This is in response to someone who saw a bunch of URLs coming out of it and was surprised at a bunch of them being wrong. That's using the tool wrong. It's like being surprised that the top results in google/app store/play store aren't necessarily the best match for your query but actually adverts! The CEO of Anthropic said I can fire all of my developers soon. How could one possibly be using the tool wrong? /s

If you base all your tech workings on the promises of CEOs you'll fail badly, you should not be surprised by this.

Thanks for the advice...

Re: Two things LLM coding agents are still bad at

#374

Post by NumberCruncher »

tossandthrow wrote: post #369
NumberCruncher wrote: post #150

Earlier quoted context omitted.

> Often I find myself cursing at the LLM for not understanding what I mean... Me too. But in all these cases, sooner or later, I realized I made a mistake not giving enough context and not building up the discussion carefully enough. And I was just rushing to the solution. In the agile world, one could say I gave the LLM not a well-defined story, but a one-liner. Who is to blame here? I still remember training a juni…

> ... Who is to blame here? That is not really relevant, is it? The LLM is not a human. The question is whether it is still af efficient to use LLMs after spending huge amounts of time giving the context - or if it is just as efficient to write the code yourself. > I still remember training a junior hire who started off with Working with LLMs is not training junior developers - treating it as such is yet another reso…

I think we have to agree that we disagree. What works for you doesn't have to work for me and vice-versa.

Re: Two things LLM coding agents are still bad at

#375

Post by tinodb »

rossant wrote: post #79
coldtea wrote: post #76

Earlier quoted context omitted.

> A few days later, just before deployment to production, I wanted to double check all 40 links. This was allowed to go to master without "git diff" after Codex was done?

It was a fairly big refactoring basically converting a working static HTML landing page into a Hugo website, splitting the HTML into multiple Hugo templates. I admit I was quite in a hurry and had to take shortcuts. I didn't have time to write automated tests and had to rely on manual tests for this single webpage. The diff was fairly big. It just didn't occur to me that the URLs would go through the LLMs and could b…

I have piped diffs into an(other) LLM and asked: is this a pure refactor or did things actually change? It usually gives quite good analysis…

Re: Two things LLM coding agents are still bad at

#376

Post by jononor »

colonCapitalDee wrote: post #297
stuartjohnson12 wrote: post #230

Earlier quoted context omitted.

"hey claude, please remove the fake data and use the real data" "sure thing, I'll add logic to check if the real data exists and only use the fake data as a fallback in case the real data doesn't exist"

Claude (possible all LLMs, but I mostly use Claude) LOVES this pattern for some reason. "If fails/does not exist I'll just silently return a placeholder, that way things break silently and you'll tear your hair out debugging it later!" Thanks Claude

Optimizing for engagement? You will use Claude again for the debugging...

Re: Two things LLM coding agents are still bad at

#377

Post by grey-area »

laterium wrote: post #321
grey-area wrote: post #313

Earlier quoted context omitted.

So questioning the utility of LLMs for knowledge work is now akin to a conspiracy theory?

Not what I said at all. Question it all what you want. But disproving outrageous CEO claims doesn't get you there. Whether LLMs are AGI/ASI that will replace everyone is seperate from whether they are useful today as tools. Attacking the first claim doesn't mean much for the second claim, which is the more interesting one.

I'm questioning the basic utility. They are text generation machines. This makes them unsuitable for any work that requires accuracy or understanding, which is the vast majority of knowledge work.

Re: Two things LLM coding agents are still bad at

#378

Post by cyanydeez »

consumer451 wrote: post #351
bckmn wrote: post #294

Earlier quoted context omitted.

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

Unfortunately, the sociopath MBAs are still generating a bubble based on instant feedback regardless of underlying value.

Re: Two things LLM coding agents are still bad at

#379

Post by egberts1 »

Grok/ChatGPT cannot navigate semantic pathways of large syntax files (nftables, ISC Bind9) in LL(1) fashion.

I've worked with both and finished my Vim syntax highlighters down to the keywords.

And getting them to find 'stmt', 'expr_stmt', and 'primary_stmt_expr' semantic production rules (one is Bison-generated .y file, other is hand-rolled). Both makes too much assumptions despite explicitly instructing them to do "verification & validation" of a pathway given a sample statement.

Only Google Gemini barely cut the mustard.

Another case is making assumptions (upon grilling about its assumption, I've since learned that it was looking at old websites, archiac info). Asking to stick with latest nftables v1.1.4 (or even v1.1.5 head) does not help because old webpages gave obsoleted nftables syntax.)

Don't expect LLM to navigate any time soon the S-expression, RECREATE abstract syntax tree of 4-layer or deeper, transition a state machine beyond 8 states, or interpret Bison parsers reliably.

My only regret is that none of them will take the LLM learning from me, the expert so that others may benefit.

- https://github.com/egberts/vim-syntax-bind-named

- https://github.com/egberts/vim-syntax-nftables

Re: Two things LLM coding agents are still bad at

#380

Post by tossandthrow »

NumberCruncher wrote: post #374
tossandthrow wrote: post #369

Earlier quoted context omitted.

> ... Who is to blame here? That is not really relevant, is it? The LLM is not a human. The question is whether it is still af efficient to use LLMs after spending huge amounts of time giving the context - or if it is just as efficient to write the code yourself. > I still remember training a junior hire who started off with Working with LLMs is not training junior developers - treating it as such is yet another reso…

I think we have to agree that we disagree. What works for you doesn't have to work for me and vice-versa.

If you want to sit and throw tokens after thinking you are treating an LLM like a junior developer, all power to you.

Meanwhile, I think I will stick to get tangible performance benefits out if its usage.

Post reply on HN