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

41–50 of 230 posts

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

#41

Post by vishvananda »

I've been experimenting quite a bit with long-horizion agentic coding[1] and I have also noticed that agents seem to perform worse when forced into certain architectural patterns. I have found that is a bit better when including the constraints along the way instead of adding them after the fact. There seems to be a side-effect I have been calling "calcification", where a pattern starts appearing in the codebase and the agent follows the pattern to the point where it dominates the context and becomes self-reinforcing. This could potentially be a strength or a weakness for existing code bases depending the codebase quality. I will have more insights on this soon as more from-scratch runs conclude that include architectural guidance from the beginning.

[1]: https://medium.com/@vishvananda/i-spent-2-billion-tokens-wri...

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

#42

Post by acgourley »

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.

I disagree, their findings should generalize to the frontier. Even if the latest can deal with the extra complexity, it stands to reason it will take more tokens to do less. This could be a useful insight into the next generation of evals.

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

#43

Post by knollimar »

mjburgess wrote: post #28
jeremyjh wrote: post #18

Earlier quoted context omitted.

I think that’s mostly because they get so much more of that reinforcement learning - since it is so economical. I dont know if there is any evidence of a fundamental reason they can’t be just as good at other tasks, but it might be economically infeasible for awhile yet.

No one is curating vast amounts of data for them in other domains. Programmers send programs with fixes

There's no diff of my excel lambdas being fixed? :(

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

#44

Post by mrob »

acbart wrote: post #14
yomismoaqui wrote: post #6

Also they used languages with dynamic typing like Python & JS. In my experience a statically typed codebase is easier to maintain for humans so maybe it is also for agents. When using Codex/Claude Code with Go code I cannot count the times the agent does some change, runs a build to check for errors, find some and fix them.

It's crazy to me that people think of Python as dynamically typed by default. Strong static typing has been an option in Python for years now, and it should just be the default.

>Strong static typing has been an option in Python for years now, and it should just be the default.

https://docs.python.org/3/library/typing.html

"The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc."

Which third-party enforcement mechanism do you propose become the default?

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

#45

Post by whstl »

nijave wrote: post #29
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…

Hmm, I have some anecdotal evidence this is true. Interactively working out a plan with Opus on multiple occasions it'd come up with an incompatible solution, I'll add additional context/requirements, and it has a tendency to "anchor" on it's original architecture and struggles to adapt. Sometimes it tries to sneak in changes for the original plan anyway.

Opus does this waaaay too much for my taste. It works fine for vibe-coders but for technical work it is infuriating.

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

#46

Post by maleldil »

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.

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

#47

Post by emp17344 »

jeremyjh wrote: post #18
emp17344 wrote: post #11

Earlier quoted context omitted.

If it’s not easily verifiable, LLMs aren’t good at it.

I think that’s mostly because they get so much more of that reinforcement learning - since it is so economical. I dont know if there is any evidence of a fundamental reason they can’t be just as good at other tasks, but it might be economically infeasible for awhile yet.

RLVR doesn’t work for unverifiable tasks, so they won’t be able to effectively use tools to boost reliability for those tasks.

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

#48

Post by akomtu »

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 a movie, Gold (2016), about a fake gold mine. One of its founders is a true believer: he found a few chunks of gold and started digging for more. The other founder is a nihilist: he realised that there is no gold there, but who cares if he makes the investors believe? So he does, and almost sells the company for $300M.

In our story, investors are mining intelligence from GPUs, and they truly believe they are one inch from discovering the biggest goldmine in history. But GPUs, unlike a goldmine, cannot be inspected for traces of gold by independent contractors. To keep the hype up, the nihilists in our story dig up cheap gold-looking metals from time to time and tell investors that with a bit of alchemy - agentic workflows, etc. - those metals can be magically turned into gold.

Investors will keep digging until the end of the age, or until they run out of money.

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

#49

Post by antonvs »

acbart wrote: post #14
yomismoaqui wrote: post #6

Also they used languages with dynamic typing like Python & JS. In my experience a statically typed codebase is easier to maintain for humans so maybe it is also for agents. When using Codex/Claude Code with Go code I cannot count the times the agent does some change, runs a build to check for errors, find some and fix them.

It's crazy to me that people think of Python as dynamically typed by default. Strong static typing has been an option in Python for years now, and it should just be the default.

Typing with tools like Pyright doesn't come close to providing what a good statically typechecked language provides.

There are many reasons for this. A big one is that many libraries are only partially typed at best, and dynamic types tend to propagate, weakening the guarantees you get from type checking.

Dynamic idioms in general, including something as common as string-indexed dictionaries, negate type checking. Runtime metaprogramming is the same. All of these things have equivalents in a good statically checked language, but Python doesn't follow those models.

Fundamentally, in Python static typing is an optional analysis layer over a dynamic language, and the consequences of that can't be fully mitigated. The result is a big difference in what types can guarantee.

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

#50

Post by antonvs »

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.

Critiques like this tend to focus very hard on what models can't do. It's true, they have limitations.

But they're also superhuman in so many other ways. It's valid to point out limitations, but that doesn't support the conclusion that models are not incredibly powerful and capable of the functional equivalent of reasoning at human or superhuman levels in many scenarios.

Post reply on HN