Summary

Constraint drift is the pattern where an AI coding agent honours an architectural constraint at the start of a session and quietly violates it later. It happens as the context window fills, as sessions reset, and as the same rule has to be restated across many prompts. The cause is not the model’s intelligence; it is memory and enforcement. Longer context windows and more re-prompting raise the threshold at which drift starts, but they do not remove it — the fix is repo-native, version-controlled decisions injected at prompt time and checked against generated output before review.

Most teams who adopt AI coding agents at scale meet the same surprise. The agent starts a session conformant. You state the constraint — use the repository pattern, route everything through the versioned API, never instantiate the database client directly — and for the first hour the generated code respects it. Then, somewhere in the third or fourth feature of the day, a direct database call appears. Nobody told the agent to stop following the rule. The rule simply stopped being applied.

This is constraint drift, and it is worth naming precisely because it is so easily mistaken for something else. It looks like the model getting the architecture wrong. It is not. The model got the architecture right at the start and lost the instruction along the way. The distinction matters, because the two failures have entirely different fixes.

Constraint drift is the gradual violation of an architectural rule that an AI coding agent honoured correctly earlier in the same body of work.

The Failure Is Memory, Not Intelligence

It is tempting to attribute drift to model capability. If the agent violated the constraint, the reasoning goes, it must not have understood it well enough, and a stronger model would do better. This is the wrong diagnosis, and acting on it wastes money on model upgrades that do not address the actual problem.

The problem with AI coding agents isn’t intelligence. It’s memory. An instruction given at the top of a session lives in the context window. As the session continues — as files are read, as output accumulates, as the conversation lengthens — that early instruction competes with everything that came after it for the model’s attention. It does not vanish at a clean boundary. It loses salience gradually, which is exactly why drift is so hard to catch: there is no error, no refusal, no moment where the agent announces that it has stopped honouring the rule.

There are three mechanisms by which a constraint leaves effective memory. The context window fills, and earlier tokens carry less weight than recent ones. The session resets — a new chat, a new day, a different developer — and the window starts empty. And the same constraint has to be restated across many separate prompts, so its presence depends entirely on whether a human remembered to include it that time.

An AI coding agent does not reject an architectural constraint when it drifts. It forgets the constraint while believing it is still being followed.

A Worked Example of Drift

Consider a payments feature built over three sessions. The constraint is firm: all monetary values are handled as integer minor units, never floating-point, and all currency conversion goes through a single CurrencyService.

Session one, morning. The developer states the constraint. The agent scaffolds the order model, stores amounts as integer pence, and routes a conversion through CurrencyService exactly as instructed. The code is conformant. The developer, reasonably, concludes the agent understands the rule.

Session two, afternoon, same developer, fresh chat after a context reset. The task is a refund calculation. The developer describes the refund logic but does not restate the money-handling rule — it was covered this morning, after all. The agent, working from an empty window, writes a refund amount as a floating-point multiplication and performs an inline conversion with a hard-coded rate. It is plausible code. It passes the unit test the agent also wrote, because the test encodes the same mistaken assumption. The constraint was not violated in defiance. It was never in the room.

Session three, next day, a different developer extends the feature. They paste the morning’s constraint back in, so new code is conformant again — but the floating-point refund from session two is now committed, merged, and quietly accruing rounding errors. The drift surfaced as a one-pence discrepancy in a reconciliation report six weeks later. The cost of catching it then was not one line of review. It was a forensic trace through three sessions of history to find where the rule fell out of context.

Why Re-Prompting and Bigger Windows Do Not Fix It

The two reflexive responses to drift both fail for the same underlying reason.

The first is re-prompting: restate the constraint at the top of every session, paste the architecture guide into each new chat, build a habit of reminding the agent. This works exactly as well as the human driving it is disciplined, which is to say it works until the afternoon, until a deadline, until a new joiner who does not yet know the ritual. A constraint that has to be repeated to be honoured is a constraint that can be forgotten the moment someone forgets to repeat it. Enforcement that depends on memory — human memory this time — is not enforcement. It is a suggestion with good intentions.

The second response is the larger context window. If drift happens because instructions fall out of the window, surely a window ten times larger fixes it? It does not. A bigger window raises the threshold at which salience decay begins, but it does not remove the decay, and it does nothing about the reset problem: every new session still starts empty, and every new developer still starts without the constraint. As prompt engineering is not governance argues, instructions held in a prompt are ephemeral by construction — they are not version-controlled, not enforced, and not consistent across a team.

A constraint that survives only while it remains inside the context window is a constraint that can be evicted from it.

Both responses share a hidden assumption: that the right place for an architectural rule is inside the conversation with the model. That assumption is the problem. As long as the constraint lives only in the prompt, its persistence is at the mercy of whatever the window holds and whoever is typing.

Where the Constraint Should Actually Live

The durable fix is to stop treating architectural decisions as things you say to a model and start treating them as artefacts that live in the repository. This is the case I made in why AI governance must shift left: enforcement belongs before review, not after it. Applied to drift specifically, that means three things.

First, decisions are stored as version-controlled records in the codebase — structured, machine-readable, sitting next to the code they govern rather than in a wiki nobody opens. A decision recorded this way does not depreciate when a developer leaves or a chat resets. It is part of the repository’s state.

Second, the relevant rules are injected into the agent’s context automatically at prompt time. The developer does not have to remember to paste the money-handling rule into the refund session, because the rules governing the files being touched are supplied to the agent as a matter of course. The constraint is in the room whether or not anyone thought to mention it.

Third, generated output is checked against those decisions before it reaches review. A pre-commit check or pre-review pass compares what the agent produced against the recorded constraints and flags the floating-point refund the moment it appears — not six weeks later in a reconciliation report. This is the mechanism behind how Mneme HQ decision enforcement works: store decisions as YAML in version control, inject the relevant ones at prompt time, and flag violations before they reach a human reviewer.

Repo-native architectural decisions persist across sessions because they live in version control, not in the context window of a single conversation.

What This Changes for Teams Generating Code at Scale

For an engineering lead running Claude Code or Cursor across a team, the value is not that the agent becomes smarter. It is that conformance stops depending on who is driving and how long the session has run. The constraint is enforced the same way on the first prompt and the fortieth, in the morning session and the afternoon one, for the senior engineer and the new joiner.

This does not eliminate human review — it focuses it. Reviewers stop spending attention catching drift a machine could have flagged and spend it instead on the decisions that genuinely require judgement: the novel trade-offs, the cases no rule anticipated. The mechanical violations are gone before review begins.

Constraint drift is not a defect to be patched in the next model release. It is a structural property of holding rules in memory that decays and resets. The teams that treat it as an architecture problem — deciding where their constraints should live — will spend far less time tracing one-pence discrepancies than the teams still waiting for a context window large enough to remember everything.

Key Takeaways

FAQ

What is constraint drift in AI coding agents?
Constraint drift is the pattern where an AI coding agent honours an architectural constraint early in a session and quietly violates it later. It occurs as the context window fills, as sessions reset, or as the same constraint must be re-stated across many prompts. The constraint is not rejected; it is forgotten.
Do longer context windows fix constraint drift?
No. A larger context window raises the threshold at which drift begins but does not remove it. Earlier instructions still lose salience as context fills, and every new session starts empty. A constraint that depends on remaining in the window is a constraint that can be evicted from it.
Why does re-prompting not solve constraint drift?
Re-prompting treats a constraint as something a human must remember to restate. That makes enforcement depend on the discipline of whoever is driving the agent that day. A constraint that has to be repeated to be honoured is a constraint that can be forgotten the moment someone forgets to repeat it.
How do repo-native architectural decisions prevent constraint drift?
Repo-native decisions are stored as version-controlled records in the codebase rather than in a session prompt. The relevant rules are injected into the agent’s context automatically at prompt time, and generated output is checked against them before review. Enforcement no longer depends on what the model happens to remember.