Live data from Hacker News

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

arxiv.org

11–20 of 230 posts

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

#11
post #3

Reminds me of the recent paper about delegating document editing tasks to LLMs across different disciplines [1]. That paper found that programming was the only discipline most LLMs can perform long horizon tasks on without accumulating errors & corrupting the document. I've only read the abstract of this one so far but it seems like this paper has zoomed in on programming with greater fidelity and shown a similar phe…

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

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

#13

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

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

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

#14

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.

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

#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 agent will often make over 100 tool calls to sql and git before it finally decides to apply a patch. If I was greenfield, there would be nothing to query or constrain against.

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

#16
post #14

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.

The python type hints are useful for static analysis (and yes, should be the default) but it’s a joke compared to the utility of types in a language like Haskell.

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

#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 directories - and make this change" - but keeping everything in mind already fills it's context window which makes it lose it's ability to follow the constraints (or guardrails).

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

#18
post #3

Reminds me of the recent paper about delegating document editing tasks to LLMs across different disciplines [1]. That paper found that programming was the only discipline most LLMs can perform long horizon tasks on without accumulating errors & corrupting the document. I've only read the abstract of this one so far but it seems like this paper has zoomed in on programming with greater fidelity and shown a similar phe…

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.

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

#19
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…

I find the same. We have abstractions with multiple concrete implementations, examples of patterns and examples of anti patterns.

I usually find I can achieve 90% of the outcome I'm trying to achieve. I use sonnet for planning, qwen for coding, sonnet for review.

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

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