Why More Rules for AI Means Worse Code: Understanding 'Constraint Decay' in LLMs

Forum topic · QianXun · 2026-05-09

Summary

This post explains the phenomenon of "Constraint Decay" in large language models, based on a May 2026 paper titled "Constraint Decay: The Fragility of LLM Agents in Backend Code Generation." The author illustrates with a chef analogy: just as a Michelin chef may burn fried rice when forced to follow absurd rules, AI coding agents perform dramatically worse as engineering constraints pile up. Experiments show that even the strongest model (GPT-5.2) loses an average of 30 points in assertion pass rate when moving from simple tasks to fully constrained ones, while weaker models can drop to zero. Key causes include attention/context being consumed by non-functional requirements, frequent hallucinations in the data persistence layer (ORM session management, associations, layer boundaries), and difficulty with convention-over-configuration frameworks like Django and FastAPI compared to simpler ones like Flask. The takeaway: current AI is a good tactical executor, not an architect—developers should audit their own excessive constraints before blaming the model for poor output.

Imagine you've invited a Michelin-starred chef to cook at your home.

You say, "Chef, I'd like some egg fried rice." Within minutes, a golden, beautifully separated plate of fried rice arrives. Delicious!

The next day, you want fried rice again—but this time you add some "rules":

1. "Chef, you must use this cast-iron wok, no non-stick pans." 2. "The rice must be stir-fried left to right—no random tossing." 3. "Salt must be exactly 3.2 grams, added precisely 5 seconds before turning off the heat." 4. "Your left hand must stay in your pocket the entire time."

What happens? The chef may get so distracted by these bizarre, fussy restrictions that he forgets to turn off the stove—and serves you a burnt, unevenly seasoned dish.

In the world of large language models (LLMs), this is called "Constraint Decay."

In May 2026, a paper titled 《Constraint Decay: The Fragility of LLM Agents in Backend Code Generation》 revealed a painful truth for developers: as you add engineering constraints to AI (architecture patterns, specific libraries, database constraints), the AI's success rate at solving the core business problem drops off a cliff.

What Is "Constraint Decay"?

Paper author Francesco Dente found that today's AI agents excel at "bare" problems. Ask one to write a simple registration endpoint, and it flies.

But once you put "engineering shackles" on it—such as:

"Use the Clean Architecture pattern."
"The database must be PostgreSQL, accessed via the SQLAlchemy 2.0 async driver."
"All entities must pass through a DTO layer."

The AI performs like a dancer with bound hands and feet.

The experimental data shows that even on the strongest model, GPT-5.2, moving from "simple tasks" to "fully constrained tasks" causes the code correctness rate (Assertion Pass Rate) to plunge by an average of 30 points. Weaker models can drop straight to zero.

Why Does AI Fear "Rules"?

Let's break down the underlying reasoning the Feynman way:

1. The "Brain Capacity" (Context Window) Gets Filled with Non-Functional Requirements

Writing code consumes "attention." When you demand that the AI both get the logic right and follow complex architectural styles, its attention is heavily diverted toward these "formalities." It's like solving a hard calculus problem while also having to render the answer as a regulated sonnet—your mathematical logic will likely fall apart.

2. The "Data Layer" Is the AI's Nightmare

The paper found that the AI stumbles hardest in the Data Persistence Layer.

It often writes logically coherent code, but when handling ORM subtleties (session management, association queries, boundary isolation between layers), it frequently "hallucinates." It can produce beautiful-looking code that throws database errors the moment it runs.

3. "Conventions" Are Harder Than "Explicit Logic"

Interestingly, AI performs better in simple frameworks (like Flask) and worse in "convention-over-configuration" frameworks (like Django or FastAPI). These frameworks carry lots of "magic" and implicit rules—the AI must hold too much context in mind, and the slightest slip triggers a violation.

Why This Paper Matters

Previously, we judged AI-generated code by one criterion: "does it run?"

This paper reminds us that in real industry settings, "running" is only the minimum bar—whether the code meets the team's engineering standards and architecture conventions matters just as much.

If AI writes functionally correct code but stuffs database queries straight into the presentation layer, that code is "debt" for engineering.

To summarize:

Current AI is an excellent "tactical executor," but not yet a qualified "architect."

Every constraint you impose adds a brick to the AI's mental balance scale. Once enough bricks pile up, the whole thing tips over.

So the next time you ask AI to write code and it produces a mess, don't rush to call it dumb. First check whether you're like that eccentric diner—loading your chef with unnecessary "left-hand-in-pocket" rules.

True intelligence isn't just solving problems—it's solving them gracefully under heavy constraints. AI clearly still has a long way to go.