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

Constraint Decay & Architectural Rules

• Many commenters recognize the paper’s core finding: LLM agents handle unconstrained code generation well but degrade as structural/architectural constraints accumulate.
• People report agents “anchoring” on initial architectures and struggling to adapt when requirements change, or silently ignoring parts of CLAUDE.md / guidelines as sessions grow.
• There’s concern that agents can follow local, concrete constraints (“validate JWT here”) better than high-level architectural aspirations.

Model Quality, Harnesses, and Planning

• Some dismiss results because GPT‑5.2 and non‑Codex variants were used; others argue qualitative findings likely generalize.
• Multiple practitioners say the harness (tools, loops, checks) matters more than the specific model once it’s decent.
• Recursive planning modes, multi-step plans, and separate “planning vs execution” agents are reported to significantly improve adherence to constraints.
• Long-horizon, multi-tool agents that query codebases, SQL, git, etc., before patching are seen as more robust.

Verification, Guardrails, and Context Limits

• A recurring theme: LLMs excel at tasks with clear, cheap verification (tests, builds, linters). Unverifiable goals (taste, maintainability) remain weak.
• Guardrails and strong constraints often reduce performance by shrinking the reachable solution space.
• “Constraint decay” is linked by some to “context rot”: as conversations and contexts lengthen, models forget or override earlier instructions.

Language Choices, Typing, and Frameworks

• Several note better behavior in statically typed ecosystems and when compilers/type-checkers are in the loop.
• Others criticize using dynamic Python/JS without enforced typing; suggest always running type checkers in the harness.
• Some find LLMs do better with simple stacks (raw HTML/CSS/JS, raw SQL/SQLite) than with heavy frameworks and ORMs.

Docs, Specs, and Shifting Complexity

• Practitioners increasingly write extensive markdown specs, rules, and skills to steer agents.
• Concern: complexity is moving from formal code to informal natural language, which is ambiguous, non-deterministic, and hard to maintain.
• Counterpoint: much of this is just finally documenting long-held tribal knowledge that was previously implicit.

Productivity, Novelty, and Maintenance

• Several engineers say 80%+ of their professional code is now LLM-generated and that shipping speed is dramatically higher.
• Skeptics argue this is mostly remixing “slop” and that LLMs can’t produce truly novel work; others counter with examples of novel math results and note that most enterprise code isn’t meant to be novel anyway.
• Long-term maintainability and dependence on future, non-backward-compatible models are seen as unresolved risks.

Tools, Linters, and Orchestrators

• Many propose architectural linters, ArchUnit-style tooling, and custom ESLint rules to encode structural rules mechanically instead of relying on prose.
• Several projects are mentioned that orchestrate multi-phase, test-heavy agent workflows, suggesting a trend toward more structured, external control layers around LLMs.