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