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

131–140 of 230 posts

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

#131

Post by luodaint »

Not those carefully designed constraints that I set up from the beginning, but short-term ones that I came up with after an agent failed in some way: "Validate JWT at the route level, not the component." "Call workspace provisioning on each user creation." Both because of things the agent had done incorrectly.

Aspiration vs. consequence, in other words. An aspiration constraint describes a desired outcome for the system; a consequence constraint maps to a problem already encountered. And the agent ignores the former when faced with the path of least resistance while obeying the latter because it is brief, unambiguous, and precise about preventing that particular failure mode. Which is key rather than the harness in determining survival through session rotation.

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

#132

Post by gib444 »

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…

> ... This is also why adding to the prompt examples of the style of code you want ...

You could take it a step further and put the example code into source code files...and be like, super comprehensive with your examples ... ;)

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

#133

Post by [deleted] »

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?

[deleted]

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

#134

Post by p0w3n3d »

bob1029 wrote: post #34
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).

I've recently vibecoded pure html+css+js frontend for WWTBM-alike game: https://github.com/pawel-jaworski-loftyworks/mili-game - it consists of one file and is blazingly fast. Previous attempts to vibecode something with a vite-framework something were more harsh and clumsy.

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

#136

Post by bob1029 »

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,…

I'm not having much trouble with very large (>50mb raw source) and complex codebases. The fact that it's all strongly typed probably helps a lot, but I don't think that's the whole story.

I think the harness and code patching technique starts to matter a lot more once you get outside the trivial range of codebases that fit within the first ~20% of the context window and can otherwise be iterated completely in a single inference pass.

The apply_patch technique that OAI has polished their models on seems to be the best approach for monster scale codebases. Anything based on line ranges and simple find-replace will disintegrate at the edges. You need multiple spatial anchors to deal with nasty things like cshtml files. The prepare/commit behavior is ideal for iterating through ambiguous contexts across many large files and refining anchors.

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

#137

Post by TeMPOraL »

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,…

> yet the trade off seems to be clear and a lot of people are just ignoring it.

There's plenty of focus on the negative side of the tradeoff. Less so on why we're making it anyway, or why it somehow works out even if "this starts to look like we're all just moving complexity from the more formal and deterministic world of programming languages to the informal and non-deterministic world of natural language".

And the answer to that can be condensed to a one-liner, which I quote after[0]:

  sizeof(docs)
--

[0] - https://drensin.medium.com/elephants-goldfish-and-the-new-go... - article may be a bit fluffy here and there, but that one line was a big insight for me.

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

#138

Post by sdevonoes »

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,…

> At some point this starts to look like we're all just moving complexity from the more formal and deterministic world of programming languages to the informal and non-deterministic world of natural language.

This is the problem nobody is talking about. I see codebases growing in MD files with instructions and guidelines and requests that are also LLM generated… and it’s all piling up. No one is reviewing it 100% , and even when we do, it’s all very subjective. What’s the difference between “Follow a RESTful approach”, “We use REST, not graphql”, “90% of our endpoints are resource oriented, but we have a couple of endpoints that look rpc-ish; please ignore the latter”… It’s all very stupid.

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

#139

Post by sdevonoes »

TeMPOraL wrote: post #137
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,…

> yet the trade off seems to be clear and a lot of people are just ignoring it. There's plenty of focus on the negative side of the tradeoff. Less so on why we're making it anyway, or why it somehow works out even if "this starts to look like we're all just moving complexity from the more formal and deterministic world of programming languages to the informal and non-deterministic world of natural language". And the…

I don’t think that’s true based on experience. Maybe “<“ instead of “<<“, yeah. But even in that case, it’s an awful trade off for any serious codebase that needs to be maintained over the years (and you don’t know what LLMs are gonna look like next year, so there are zero guarantees all your MD is gonna work as good as it’s “working” right now)

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

#140

Post by tcoff91 »

sdevonoes wrote: post #138
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,…

> At some point this starts to look like we're all just moving complexity from the more formal and deterministic world of programming languages to the informal and non-deterministic world of natural language. This is the problem nobody is talking about. I see codebases growing in MD files with instructions and guidelines and requests that are also LLM generated… and it’s all piling up. No one is reviewing it 100% , a…

This is why you need to be generating more linter rules instead of just having things be in markdown files.

I had never written an eslint rule until i started having agents pump them out for me and now I've encoded a bunch of important rules as lint rules that will fail CI if violated.

Post reply on HN