Why Codegen Agents Drift as Constraints Quietly Erode

We’ve all seen the demo. You give a codegen agent a backend task, it scaffolds routes, models, tests, maybe even a migration, and everyone in the room starts acting like junior engineers are now optional.

Then you add six real constraints — keep the existing auth middleware, follow the repo’s service pattern, don’t touch the billing schema, emit OpenAPI docs, preserve idempotency, and make tests pass in CI — and the whole thing starts wobbling like a shopping cart with one bad wheel.

That wobble has a name now: constraint decay. And if you’re building production agents, it’s not an academic curiosity. It’s the thing quietly turning “pretty good in evals” into “why did this rewrite our retry logic on a Friday?”

The recent paper Constraint Decay: The Fragility of LLM Agents in Back End Code Generation makes the problem painfully clear: as structural requirements pile up, agent performance drops sharply across models and setups arXiv.

That tracks with what we’ve seen in real delivery work. The first 70% of a coding task is often easy. The last 30% — the part with architecture boundaries, weird legacy assumptions, compliance rules, and “don’t break this one cursed integration” — is where agents start freelancing.

And freelancing is cute in copywriting. It’s terrible in backend systems.

Key Takeaways

• Constraint decay is what happens when codegen agents handle each new requirement worse than the last one, especially structural constraints.
• The failure mode isn’t just “bad code.” It’s drift: the agent satisfies the visible task while quietly violating system rules.
• If your evals only score final correctness, you’ll miss the exact behavior that burns teams in production.
• The fix isn’t “better prompting.” It’s layered guardrails: task decomposition, machine-checkable constraints, repo-aware evals, and human checkpoints.
• For production teams, “constraint decay: the fragility” should be treated like latency regression or test flakiness — measurable, expected, and engineered around.

What the paper gets right — and why it matters in production

The paper’s core claim is simple: LLM agents can perform well on unconstrained backend generation, but as structural constraints accumulate, performance degrades substantially arXiv.

That sounds obvious until you realize how many teams still evaluate agents like this:

1. Give task
2. Check if code runs
3. Declare victory

That’s not an eval. That’s a vibes-based smoke test.

Production backend work is constraint-heavy by design. You’re not just asking for “an endpoint.” You’re asking for an endpoint that respects authorization boundaries, logging policy, naming conventions, transaction semantics, retry behavior, data contracts, observability hooks, and deployment assumptions. The agent isn’t coding in a vacuum. It’s doing surgery in a moving bus.

Here’s where it gets weird.

A lot of agents don’t fail loudly under constraint load. They fail politely. They produce code that looks reasonable, compiles, maybe even passes a few tests, while quietly violating the exact rules that matter most.

That’s why this paper matters. It gives language to a pattern teams have been hand-waving away as “model inconsistency” or “agent drift.”

No. This is a specific fragility.

Why backend codegen is the perfect place for agents to embarrass themselves

Frontend mistakes are visible. Backend mistakes are patient.

A generated React component that breaks layout gets spotted in ten minutes. A generated idempotency bug in a payment retry path might sit there until traffic spikes, a worker retries twice, and your finance team starts asking why one customer got charged three times.

Backend systems are constraint jungles. The code is only half the job. The real work is preserving invariants.

We’ve found that codegen agents usually do fine when constraints are:

• local
• explicit
• easy to verify
• close to the edited file

They start struggling when constraints are:

• cross-cutting
• implicit
• buried in existing patterns
• enforced socially instead of mechanically

That last one is brutal. If your “architecture” lives mostly in senior engineers’ heads and a stale Notion page, the agent has no chance. Frankly, neither does your next hire.

Here’s a simple mental model: unconstrained generation is like asking a cook to make pasta. Constrained backend generation is like asking them to make pasta in a kosher kitchen, with one broken burner, no garlic, a customer allergy list, and a head chef who’ll scream if the sauce touches the wrong pan.

Same dish. Totally different game.

Before we talk fixes, it helps to see where the drift actually starts.

Here’s how constraint erosion usually creeps into a production codegen workflow:

flowchart TD
  A[Product request] --> B[Agent plans task]
  B --> C[Generates code changes]
  C --> D[Passes basic tests]
  D --> E[Misses hidden structural constraint]
  E --> F[Reviewer patches obvious issue]
  F --> G[Subtle drift ships anyway]
  G --> H[Incident or slow-burn maintenance cost]

The ugly part is step D. Passing basic tests creates false confidence. Teams stop looking where the real damage is happening.

Why your current evals probably miss constraint decay

Hot take: most codegen eval suites are vanity metrics wearing a lab coat.

If your benchmark rewards “task completed” without penalizing architecture violations, hidden side effects, or non-local breakage, you’re not measuring production readiness. You’re measuring how good the agent is at making a plausible demo.

The arXiv paper focuses attention on structural requirements in backend generation arXiv. That’s exactly where many internal evals are weakest. Teams often check:

• did the code compile?
• did the happy-path test pass?
• did the endpoint return the expected response?

Fine. Useful. Not enough.

What they don’t check:

• Did the agent preserve transaction boundaries?
• Did it route through the approved service layer instead of talking directly to persistence?
• Did it duplicate business logic that was supposed to stay centralized?
• Did it violate naming, schema, or auth conventions in a way that won’t explode until the next feature lands?

We’ve seen agents “solve” a task by bypassing abstractions that existed for a reason. It’s the software equivalent of fixing a leaky pipe with duct tape and then painting over it.

Looks great in screenshots.

Here’s a visual we use to explain the problem to teams:

The lesson is blunt: if your evals don’t model accumulating constraints, they won’t catch constraint decay: the fragility that shows up in real repos.

The four kinds of constraints agents forget first

Not all constraints decay at the same speed.

In practice, these are the first to go:

1. Architectural constraints

“Use the domain service, not the controller.”
“Don’t query the database from this layer.”
“Events must be emitted through the outbox.”

Agents violate these constantly because architectural rules are distributed across files, conventions, and tribal knowledge. They’re not always obvious from the prompt.

This is why teams looking into AI agents should care less about raw generation speed and more about repository grounding plus enforcement.

2. Behavioral constraints

These are the nasty ones: idempotency, retries, ordering guarantees, timeout handling, concurrency rules.

An endpoint can look correct and still be operationally wrong. We’ve found this is where human review still pays for itself fast, especially in payment, healthcare, logistics, and anything else where “almost right” is just expensive wrong.

3. Interface constraints

Schema compatibility, API contracts, event payload formats, backward compatibility.

Agents love “cleaning up” interfaces. Sometimes that means they refactor your public contract into a breaking change with excellent formatting.

Very thoughtful of them.

4. Process constraints

Tests, linting, commit hygiene, migration sequencing, rollout safety.

These sound boring until a generated migration runs before the app code is ready. Then suddenly process is very exciting.

But that’s only half the problem.

Why prompt engineering won’t save you

We’ve tried the giant master prompt. The lovingly crafted system prompt. The “IMPORTANT: DO NOT MODIFY EXISTING AUTH FLOW” prompt in all caps.

It helps a bit.

It does not solve the problem.

Prompting is a soft control. Production backend constraints need hard controls.

That means machine-checkable rules wherever possible:

• AST-based checks for forbidden imports or layer violations
• contract tests for APIs and events
• schema diff gates
• policy checks in CI
• sandboxed execution with scoped file permissions
• mandatory plan approval for high-risk changes

If the agent can violate a rule and still get merged, that’s not an agent problem. That’s a pipeline design problem.

For teams building custom workflows, this is usually where AI consulting or custom models work becomes worth it. Not because you need a magical model, but because you need your delivery system to reflect how your repo actually behaves under pressure.

The guardrails we’d put around production codegen agents

If we were setting up a serious codegen pipeline for backend work today, we’d do this.

1. Break tasks into constraint-sized chunks

Don’t ask the agent to “implement user deletion across the platform.”

Ask it to:

• add service method
• update repository layer
• write migration
• add contract tests
• update OpenAPI spec
• prepare rollout notes

Smaller tasks reduce the number of simultaneous constraints the agent has to juggle. This sounds unglamorous because it is. It also works.

Monolithic agent tasks are overrated. They’re the buffet plate of software automation: everything touches everything, and by the end it’s all a mess.

2. Turn hidden rules into executable checks

Every time a reviewer says “we always do it this way,” ask whether that rule can be encoded.

If yes, encode it.

That might mean static analysis, custom lint rules, test templates, codeowners, or CI gates. If no, at least surface it in task templates so the agent has a fighting chance.

3. Score intermediate behavior, not just final output

This is the big one.

Your evals should measure:

• planning quality
• file selection accuracy
• constraint adherence
• number of forbidden edits
• test delta
• rollback risk
• human correction load

An agent that reaches the right answer by smashing through three architecture boundaries is not “successful.” It’s a future incident with good PR.

4. Add human checkpoints where the blast radius is asymmetric

Not every task needs a human in the loop. But some absolutely do.

Require review when the agent touches:

• auth
• billing
• migrations
• concurrency primitives
• infra config
• public contracts

We use the same logic in other AI systems too. In voice AI and on-device AI, the question isn’t “can the model act autonomously?” It’s “where does autonomy become more expensive than supervision?” Same principle here.

5. Measure cost per accepted change, not cost per generated token

A cheap agent that produces high-review, high-rework diffs is not cheap.

Use a real operational metric:

cost per accepted production-safe change

That includes model calls, CI time, reviewer time, rollback risk, and defect cleanup. If you want to sanity-check economics before building, tools like an AI cost estimator are useful — but only if you include human correction overhead, not just inference cost.

That’s the part vendors love to forget.

A practical human-in-the-loop workflow that doesn’t feel like babysitting

The best human-in-the-loop setups aren’t “watch the robot type.”

They’re stage gates.

Here’s a workflow we’d recommend for production backend codegen:

1. Agent proposes plan
   Files to change, constraints detected, risks flagged.

2. Human approves or edits plan
   This is fast and catches dumb direction early.

3. Agent generates scoped diff
   Limited file access. No repo-wide “helpfulness.”

4. Automated policy checks run
   Tests, architecture rules, contract validation, migration safety.

5. Human reviews only high-risk deltas
   Not every line. Just the parts with real blast radius.

6. Agent handles low-risk fixes
   Formatting, test repairs, docs, minor refactors.

Here’s what that looks like in practice:

sequenceDiagram
  participant PM as Product/Engineer
  participant A as Codegen Agent
  participant CI as Policy + CI
  participant R as Human Reviewer

  PM->>A: Scoped backend task + constraints
  A->>R: Plan, files, risk summary
  R->>A: Approve or refine
  A->>CI: Submit constrained diff
  CI-->>A: Tests/policy results
  A->>R: Final diff with flagged risks
  R->>PM: Merge or request changes

This is slower than “YOLO autonomous engineer mode.”

Good.

If your backend touches money, identity, or customer data, slower and correct beats fast and theatrical.

Where this gets especially relevant for agent product teams

If you’re building your own agent product, the paper should change how you market, test, and scope it.

Don’t claim “full-stack autonomous coding” if your system falls apart under layered constraints. Say what it’s actually good at. Scoped edits. Test generation. Refactors in bounded contexts. Boilerplate under supervision.

That honesty is underrated.

We’ve seen this same pattern in product work around RunHotel: users don’t reward AI for sounding magical. They reward it for being dependable in a narrow, high-value workflow. Reliability beats swagger.

If you’re productizing codegen, start narrow:

• one framework
• one repo shape
• one deployment model
• one risk profile

Then earn your way outward.

And if you need help designing those boundaries instead of shipping another “works in demo, melts in prod” agent, talk to us through Cropsly’s contact page.

The real lesson from constraint decay

The paper isn’t telling us agents are useless. It’s telling us our expectations have been sloppy.

Backend engineering is a constraint satisfaction problem wearing a coding costume. The code is visible, so everyone obsesses over code quality. The constraints are invisible, so that’s where the failures hide.

That’s why constraint decay: the fragility matters. It names the exact moment an agent stops acting like a helpful assistant and starts acting like an overconfident contractor who didn’t read the spec.

You don’t fix that with a better slogan.

You fix it with narrower scopes, harder guardrails, better evals, and humans reviewing the parts that can hurt you.

If you’re deploying codegen agents now, your next step is simple: pick three recent agent-generated backend diffs and audit them for hidden constraint violations, not just correctness. You’ll learn more in an afternoon than in a month of prompt tweaking.

And if that audit feels uncomfortable, good. That’s usually where the real engineering starts.

Sources

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