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

Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

arxiv.org

Post reply on HN
Print view View original

221–230 of 230 posts

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#221

Post by hansmayer »

tcoff91 wrote: post #214
hansmayer wrote: post #208

Earlier quoted context omitted.

A linter won't prevent your idiot LLM from going bonkers and suddenly switching to GQL instead of REST just for that one endpoint, because it confabulated something or putting your stripe secret into your react frontend - all cases of slop I've seen happen.

That's why we still do code review. The linter rules is just about lowering the amount of mistakes you have to catch at code review time.

> The linter rules is just about lowering the amount of mistakes you have to catch at code review time.

Aren't they, in the modern context, mostly used for code formatting and such? I don't recall anyone using them today for "catching errors". Unless you count code formatting style violations as 'errors'.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#222

Post by ucekmez »

The paper frames it as a model thing but I believe a lot of it is the interface. HTML, undocumented JSON, APIs move frequently. that's why the agent is re-guessing constraints every call and that sure compounds. Static typing works because the constraint is in the compiler (not in the model). Same for schemas, manifests, signed stuff. Often the 'agent forgot the rule' just means nothing in the stack ever carried the rule.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#223

Post by HappMacDonald »

hansmayer wrote: post #220
bitexploder wrote: post #217

Earlier quoted context omitted.

That was my point. Validating actual behavioral tests. Not letting them cheat. They still will at times, but like, resd their code, fix it or send a reviewer agent to find and make todo list. If you give them a behavioral test skill it will do a much better job. Sometimes I have to hint to them. I rarely ship anything I have not reviewed at least once.

> Not letting them cheat. They still will at times, but like, resd their code, Well then, if they "still will", your effort kind of misses the point. Sure maybe, you'll catch it every time and maybe that one time you did not catch it, it was no critical mistake...But it only needs to make that critical mistake once, and all of this effort was in vain.

(as an outsider) what this sounds a lot like to me is trying to manage a very large team of human personnel that have a high turnover rate which is not directly in your control.

Some of them will make mistakes, some of them will cheat, some of them will do things you don't like, and "punishing" them will be less helpful to you due to the high turnover than building a system which instead disincentivizes things from a high level. Which catches bad actions and starts them over.

Classically I think we are more accustomed to "building a team of humans, and being able to chastize or fire a bad employee helps the team grow more cohesive and build accountability".

But it is possible to get the same (less than ideal) situation with teams of humans where accountability cannot be easily instilled into the team as we have with teams of agents.

And then obviously the reason one might consider using such an unusual and difficult to manage team as a tool is when the cost is low and the supply is high, which is purportedly the case with AI at least for the moment.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#224

Post by goatlover »

coldtea wrote: post #157
goatlover wrote: post #144

Earlier quoted context omitted.

Everything changes, nothing remains without change.

Nah, most things stay the same withing quite narrow margins. The moon gets hit by a meteor now and then, but it's been essentially the same rock for some billion years.

Life didn't stay mostly the same over that time span. Evolution is a good counter to everything remaining the same under the sun.

Anyway, Buddhists and Heraclitus aren't wrong. It's just a matter of enough time and the moon will no longer be a moon.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#225

Post by tomascantor »

guhcampos wrote: post #93

I'm a convert. I was 100% skeptical about LLM code generation, now over 80% of the professional code I write is generated. That said, the limitations are kind of obvious and are starting to show in some of my projects, and this article seems to confirm my suspicions. If it's just confirmation bias or not, I can't say yet. In my experience, for anything complex enough, I have to start adding more and more constraints,…

[flagged]

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#226

Post by lanstin »

skydhash wrote: post #84
lanstin wrote: post #82

Earlier quoted context omitted.

Yeah and that design and insight is the tiring part and while fun a bit less satisfying in the way that writing a nice bit of boiler plate or populating the struct members for your data type can be. One thing is you can work on design and insight while taking a good walk around the block, which is nice.

I spend that time mostly on the sofa, or in front of a whiteboard. Or sometimes a live brainstorming. Typing code is actually relaxing. What looks like relaxing is actually hard thinking.

I try to explain this to my family (currently in a pure remote job) but it is difficult to make the case persuasively. Honestly tempted to start recording voice memos to self to capture the ideas for next steps, which I can run five of in tmux if i keep the directories straight.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#227

Post by bitexploder »

HappMacDonald wrote: post #223
hansmayer wrote: post #220

Earlier quoted context omitted.

> Not letting them cheat. They still will at times, but like, resd their code, Well then, if they "still will", your effort kind of misses the point. Sure maybe, you'll catch it every time and maybe that one time you did not catch it, it was no critical mistake...But it only needs to make that critical mistake once, and all of this effort was in vain.

(as an outsider) what this sounds a lot like to me is trying to manage a very large team of human personnel that have a high turnover rate which is not directly in your control. Some of them will make mistakes, some of them will cheat, some of them will do things you don't like, and "punishing" them will be less helpful to you due to the high turnover than building a system which instead disincentivizes things from a…

Right, you design systems resilient to this in traditional software engineering as well. Agents are just... a little more chaotic at times :-D

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#228

Post by maleldil »

beering wrote: post #68
maleldil wrote: post #46

Earlier quoted context omitted.

Considering this is from academia, there's a chance there were limitations on the available models. My research group accesses OpenAI models via Azure, and until recently (last week) the latest model was GPT 5. We just got 5.4.

That’s wild. Are you at a university that bans using the OpenAI APIs directly?

The university doesn't « ban » using the OpenAI APIs directly. It's a question of funding. If you want to use OpenAI, you usually use your own account and ask the university for a refund later, where you justify your usage. It's easier for the university if you use their pre-approved Azure endpoint instead, though you'll still need approval if you're going to spend a significant amount of money.

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#229

Post by Geezus_42 »

dominotw wrote: post #181
Geezus_42 wrote: post #146

Earlier quoted context omitted.

There is a huge difference between "not verifiable" and "not easily verifiable".

No because if op is actually able to verify it ( with difficulty) then ai can do it too.

So you are saying an LLM is just as good as a human?

Re: Constraint Decay: The Fragility of LLM Agents in Back End Code Generation

#230

Post by tcoff91 »

hansmayer wrote: post #221
tcoff91 wrote: post #214

Earlier quoted context omitted.

That's why we still do code review. The linter rules is just about lowering the amount of mistakes you have to catch at code review time.

> The linter rules is just about lowering the amount of mistakes you have to catch at code review time. Aren't they, in the modern context, mostly used for code formatting and such? I don't recall anyone using them today for "catching errors". Unless you count code formatting style violations as 'errors'.

Maybe in whatever language ecosystem you are in, but in the javsacript world most projects have tons of eslint rules that are specifically designed to stop bugs.

Like for instance there are tons of eslint rules to make sure you aren't breaking the rules of react, like having missing dependencies in a useEffect dependencies array, or calling a react hook conditionally.

Post reply on HN