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

31–40 of 230 posts

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

#31

Post by Silhouette »

lanstin wrote: post #21
whatever1 wrote: post #20

Earlier quoted context omitted.

This is not a new problem though. This is why we started writing modular code, strict interfaces etc

And doing incremental dev, so once a feature is done you can mostly ignore it.

If there is one good thing that the generative AI tools have shown beyond any doubt it's that the classic "good programming" practices are still useful and effective. Self-documenting code. Modular design. Clearly defined architecture. Incremental development. Coding standards. Automated tests. Automated everything.

If there's a second thing the generative AI tools have shown beyond any doubt it's that many of the more modern (relatively speaking) "best practices" that have always been over-hyped and questionably-evidenced really do tend to produce worse results. LLMs take these methods to their logical conclusions and show us the end result much sooner. You can't just iterate your way to a solution when you don't even know what problem you're trying to solve. If you don't have a clear spec then you don't know what a correct product looks like. You need to invest time in reviewing code properly. If you don't keep the big picture in mind then the big picture becomes a mess.

Maybe one day the LLMs will leave me out of a job but at least I'll feel validated first!

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

#32

Post by xienze »

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…

> their performance drops when forced to navigate explicit architectural rules

Even the best models have trouble adhering to stuff as mundane as rules for how to style generated code (indent this much, name things with these patterns, etc.). Even the most die-hard AI-first coder will admit to that kind of stuff being not unheard-of. Yet they still delude themselves into thinking that these models will follow a sufficiently detailed spec to the letter, every time.

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

#33

Post by Npovview »

noosphr wrote: post #13
sheeshkebab wrote: post #10

Earlier quoted context omitted.

…but they reason well enough given enough context (using their matmuls).

To this day frontier models think that A and not B means A and B when the sentence gets pushed far enough back in their context window. The context length that model can reason over without obvious errors is much smaller than the advertised context. Between a 1/4th to a 1/20th what is advertised on the tin.

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

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

#34

Post by bob1029 »

p0w3n3d wrote: post #9

tasks spanning eight web frameworks Does anyone else have this experience that LLM create better pure html+CSS+js than work with existing frameworks?

I think web frameworks have been "in trouble" as of gpt-5.4. I can't imagine using something like React anymore.

The most incredible combo I've seen lately is progressive enhancement of Razor Pages with javascript. With this arrangement the newest models tend to make a really good call on if something should happen server-side (cshtml) or on the client (js).

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

#35

Post by leecommamichael »

Npovview wrote: post #33
noosphr wrote: post #13

Earlier quoted context omitted.

To this day frontier models think that A and not B means A and B when the sentence gets pushed far enough back in their context window. The context length that model can reason over without obvious errors is much smaller than the advertised context. Between a 1/4th to a 1/20th what is advertised on the tin.

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

Is that the same gap as what you’re responding to? To me, it seems his critique is about advertised capability and logical statements, and your rhetorical(?) question is about memory.

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

#36

Post by sigbottle »

jeremyjh wrote: post #24
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…

Even the strongest frontier model they used - GPT 5.2 - I would consider barely usable for agentic programming. I’m not really interested in analysis of the weaknesses of such models because in my experience many weaknesses disappear entirely as models get stronger and reasoning effort is turned up. Especially if you tell them what you want them to do. Also, it’s not surprising to learn that when more acceptance crit…

Wait isn't gpt 5.2 good? Or is it not thinking / not codex? 5.2 was what sparked the late 2025 openai agentic programming revolution.

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

#38

Post by suprfnk »

emp17344 wrote: post #8
leecommamichael wrote: post #7

These things don’t think. We’re going to have to reiterate this for a long time, I fear.

There is now a trillion-dollar industry bent to the task of convincing people these things can think. It’s gonna cause some damage.

I don't think they think. I still use them a lot despite that, because they are very powerful parameterised code generators.

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

#39

Post by brandensilva »

qsort wrote: post #26
apsurd wrote: post #23

Earlier quoted context omitted.

Would you mind sharing antirez' suggestion?

I am obviously paraphrasing, but the general idea is that trying to synthesize style from a codebase into e.g. a markdown guide generally doesn't work very well. What achieves style transfer is providing the model with a lot of examples of the style, conventions, patterns you want. To put it in practice: if you point claude/codex to a repository and you ask it to implement feature X using style guide Y, the code will…

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 governance and compliance policies due to legal/business needs requiring it so it's far more well documented than operational ones in how we work. It is more about the how versus the what here I guess is what I'm saying.

But yeah this is why it does great when there are tests, design systems, evals, and other artifacts to mirror. Far more reckless and unpredictable without these things, but still great for exploration and finding the data output you seek.

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

#40

Post by mikeyouse »

qsort wrote: post #26
apsurd wrote: post #23

Earlier quoted context omitted.

Would you mind sharing antirez' suggestion?

I am obviously paraphrasing, but the general idea is that trying to synthesize style from a codebase into e.g. a markdown guide generally doesn't work very well. What achieves style transfer is providing the model with a lot of examples of the style, conventions, patterns you want. To put it in practice: if you point claude/codex to a repository and you ask it to implement feature X using style guide Y, the code will…

I ran into similar issues as we started to roll out LLM generated financials in our org.. I’m so used to the old SQL workflow of “grab this data from this table, that data from that table, combine it into a final result that looks like xxxx” where the tables were outputs from reports in our ERP but I was having terrible results.

Ended up pointing Claude at a few sample files from our existing reporting, gave it read-only oauth access to the ERP and said “build a new report showing the cash by project as calculated by xxxx - yyyy + zzzz in the style of the existing reports” and it basically one-shot from there.

Kind of crazy and I built a bunch of redundant check-sums because I honestly didn’t think it would be able to replace like 6 workdays of effort for the 2 FTEs who generate that kind of thing manually every month but so far so good..

Post reply on HN