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

21–30 of 230 posts

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

#21

Post by lanstin »

whatever1 wrote: post #20
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…

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.

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

#22

Post by qsort »

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 think it's downstream of "you can't optimize for two different objectives".

If you only have functional requirements, then in effect you're doing some form of program synthesis, and RL can optimize that very hard.

If you have a mixture of functional and non-functional requirements, you are basically giving the model an incomplete specification, and it must in some way guess at the user's intent to fill in the blanks. This is also why adding to the prompt examples of the style of code you want (hats off to antirez for this particular tip ;)) is phenomenally powerful.

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

#23

Post by apsurd »

qsort wrote: post #22
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 think it's downstream of "you can't optimize for two different objectives". If you only have functional requirements, then in effect you're doing some form of program synthesis, and RL can optimize that very hard. If you have a mixture of functional and non-functional requirements, you are basically giving the model an incomplete specification, and it must in some way guess at the user's intent to fill in the blank…

Would you mind sharing antirez' suggestion?

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

#24

Post by jeremyjh »

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 criteria are added the failure rate increases.

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

#25

Post by xcjsam »

bob1029 wrote: post #15

> Our findings reveal a phenomenon of constraint decay: as structural requirements accumulate, agent performance exhibits a substantial decline. I have exactly the inverse findings on my end. The bigger and more legacy the codebase, the more accurate the patches become. The harness itself seems to be the most important part. I use a recursive loop that primes the root context based on the user prompt each time. My ag…

The harness mattering more than the model lines up with my experience too. What this paper measures is within-turn constraint decay. The version that bites in multi-agent setups is across-session — the architectural rules an agent wrote down on Monday don't reach the agent making the next change on Tuesday.

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

#26

Post by qsort »

apsurd wrote: post #23
qsort wrote: post #22

Earlier quoted context omitted.

I think it's downstream of "you can't optimize for two different objectives". If you only have functional requirements, then in effect you're doing some form of program synthesis, and RL can optimize that very hard. If you have a mixture of functional and non-functional requirements, you are basically giving the model an incomplete specification, and it must in some way guess at the user's intent to fill in the blank…

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 probably work, but you can usually get better results by saying "do it in the style of this file, it was done well there".

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

#28

Post by mjburgess »

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.

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

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

#29

Post by nijave »

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.
Post reply on HN