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

61–70 of 230 posts

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

#61

Post by usrusr »

dwa3592 wrote: post #17

This sounds like another version of "As a chat becomes longer, the guardrails seem to become fuzzy". You can't use all of the context window bc at the end, the output would not respect the constraints (or guardrails) but to reliably produce production grade code you want the model to have expansive awareness which fills up the context window pretty quickly. It's like saying "Keep everything in mind from these 6 direc…

So give harder guiderails? Sonarcube and the like. But I guess then the failure mode would be appeasing the linter while slowly forgetting the requirements... (or not so slowly, because the try/fail loop won't be nice to context at all..)

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

#62

Post by zdragnar »

jdlshore wrote: post #4

“Our systematic study exposes a phenomenon of constraint decay in LLM-based coding agents. While current models excel at unconstrained generation, their performance drops when forced to navigate explicit architectural rules. For end-users, this dichotomy implies that agents are reliable for rapid prototyping but remain unreliable for production-grade backend development.” One major weakness of this study is that they…

I've noticed something similar with AI assist authored books as well. Early on it does alright, but after some chapters the beginning of each chapter repeats the end of the previous, and obvious LLM tells become more frequent.

The more it has to go on, the more it relies on repetition of what came before. It's also possible that authors start paying much less attention and put less effort into editing later chapters.

Despite the sheer volume on Amazon, LLMs are not at the point of writing well.

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

#63

Post by brandensilva »

withinboredom wrote: post #56
brandensilva wrote: post #39

Earlier quoted context omitted.

Right more simply put it's great at being a copy cat, exploring similar data points that match your token needs. It is not great at decision making or judgment calls that don't have a well defined spec or plan in place yet; like unofficial or unapproved tokens if you will. A lot of this stuff simply never has had specs as it has been internal to how companies work and their secret sauce. The closest thing we have are…

Doesn't that make sense? Its text prediction. If you give it examples, it can predict. Synthesizing "put semi-colons on new lines" requires it to generate its own examples 'in its head' (so to speak) and remember that. It won't. It's like when I see people feeding it a whole bunch of "best practices" and expect it to follow them. It won't. But you could ask it questions about the best practices all day long.

Yes, exactly. Any engineer deep on this stuff right now understands that grounded predictive engine sprinkled with RL training and are discovering what that means in terms of its strengths and weaknesses for company use.

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

#64

Post by piker »

zdragnar wrote: post #62
jdlshore wrote: post #4

“Our systematic study exposes a phenomenon of constraint decay in LLM-based coding agents. While current models excel at unconstrained generation, their performance drops when forced to navigate explicit architectural rules. For end-users, this dichotomy implies that agents are reliable for rapid prototyping but remain unreliable for production-grade backend development.” One major weakness of this study is that they…

I've noticed something similar with AI assist authored books as well. Early on it does alright, but after some chapters the beginning of each chapter repeats the end of the previous, and obvious LLM tells become more frequent. The more it has to go on, the more it relies on repetition of what came before. It's also possible that authors start paying much less attention and put less effort into editing later chapters.…

Holy crap are you reading books that advertised somehow they were written with LLM assistance? Hard no here in 2026.

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

#65

Post by Npovview »

UncleEntity wrote: post #60
Npovview wrote: post #33

Earlier quoted context omitted.

Do you also happen to remember what you ate last thrusday?

"If you have a question look in the specification for the answer and don't just guess" seems a fairly important thing to remember for more than a couple of minutes...

I had a coding session where I was doing stuff across two repositories. And CC forgot in exactly which repository a particular file was so it was grepping the parent directory. I just asked it to write all important key-value pairs which it thinks are important to a file and it never did parent directory grepping.

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

#66

Post by [deleted] »

jdlshore wrote: post #4

“Our systematic study exposes a phenomenon of constraint decay in LLM-based coding agents. While current models excel at unconstrained generation, their performance drops when forced to navigate explicit architectural rules. For end-users, this dichotomy implies that agents are reliable for rapid prototyping but remain unreliable for production-grade backend development.” One major weakness of this study is that they…

[deleted]

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

#67

Post by siliconc0w »

I recommend spending some time getting a few parts of the codebase idiomatic and then @-ing those files as exemplars. This works a lot better than trying to steer it with markdown. This works reasonably well for like FastAPI but JavaScript seems to be the worst, even with guidance and exemplars it'll prefer in-lining a bunch of garbage rather than use the APIs as directed.

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

#68

Post by beering »

maleldil wrote: post #46
gkfasdfasdf wrote: post #5

Odd they used GPT-5.2 and not GPT-5.2-codex. i.e. the one optimized for coding agent tasks.

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?

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

#69

Post by KronisLV »

> For end-users, this dichotomy implies that agents are reliable for rapid prototyping but remain unreliable for production-grade backend development.

Time to start writing linting tools that check the architecture and spoon feed the LLM what exactly it's doing wrong.

I reckon something like this would be good for every project out there: https://www.archunit.org/getting-started

They expand a bit more on the reasoning behind it: https://www.archunit.org/motivation

(I also wrote a simple linter for architecture/code checks that aren't well encapsulated by ones that just focus on individual files, that uses Go + goja to write rules in ECMAScript and parallelize the read only ones and also allow ones that change files as necessary, in addition to something like Ruff / Oxlint / Oxfmt / whatever is present in each stack; though it's is still in development and not as good of a focused example as ArchUnit is)

If we write software specification docs, bother describing how it evolves with ADRs, enforce code style automatically and require certain test coverage automatically (or at least should), why couldn't we go a step further, formalize those specs and ensure that any new code is also up to snuff? I don't think that's any more of a job for an LLM, than telling it how it should format code is. Also, I'm in the camp that believes that at least many of your ORM mappings and similar stuff should be the output of codegen, since you've already gone through the trouble of describing the schema/migrations to get there.

I don't think this would be only good for LLMs, though - I've seen projects that have like 3 different audit systems built in, not because of some fancy business requirement, but rather cause the devs either didn't know about the previous one(s) or just didn't feel like following what should have been the pre-established conventions, even when there were docs in place (nobody read those).

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

#70

Post by abujazar »

spacedoutman wrote: post #37

This research is useless and nearly all other LLM research is too. gpt 5.2 is the strongest model they tested, a nearly 6 month old model. Traditional research can not keep up.

Agreed. As Simon Willison points out, November 2025 was a a critical months because that's pretty much when coding agents became «good enough», eliminating most of the problems pointed out in this study.
Post reply on HN