# Constraint Decay: LLM Agents in Backend Code Generation

A May 2026 arXiv preprint by Francesco Dente, Dario Satriani, and Paolo Papotti (Papotti is reportedly at EURECOM; the abstract page states no affiliation) measures a failure mode the authors name [[constraint-decay]]: LLM coding agents perform well when a task is loosely specified and degrade sharply as the structural constraints of real production code — architectural patterns, databases, object-relational mappings — accumulate.

The benchmark is 100 tasks: 80 greenfield builds and 20 feature implementations, spanning eight web frameworks. Each task is run from a loosely specified baseline through fully specified versions that layer on production structure, and the metric is assertion pass rate. The headline number is a drop of about 30 points from baseline to fully specified, with the weakest configurations falling near zero. Jointly satisfying the functional requirements (what the code does) and the structural ones (how it must be built) is, in their phrasing, unresolved for coding agents.

Two findings sharpen the picture. Framework sensitivity: agents do much better on minimal frameworks like Flask than on convention-heavy ones like FastAPI and Django, where more of the correct answer is dictated by conventions the agent has to honor rather than invent. And a dominant root cause: data-layer defects — incorrect query composition and ORM runtime violations — are the leading failure category. Not routing, not serialization; the database layer is where agents drift furthest from what the task actually requires.

This is a concrete, measured instance of the broader argument in [[no-silver-bullet-llms]] that LLM output falls off as you leave the well-documented median — here the "median" being a bare framework with no imposed structure. It also matches the operator-side report in [[local-ai-is-not-opus]], where a local model handled bounded reads fine but broke on long-horizon, convention-bound work. The practical takeaway lands on [[reviewing-ai-code]]: the structural constraints are exactly what a human reviewer must verify, since they are where the agent silently fails.

## Cross-references

- [[constraint-decay]] — the concept and its two travelling regularities
- [[no-silver-bullet-llms]] — the median-problem framing this quantifies
- [[reviewing-ai-code]] — why structural constraints are the reviewer's job
- [[twelve-ways-wrong-ai-coding]] — catalog of coding-agent failure modes
- [[local-ai-is-not-opus]] — the same degradation observed in the field