Main idea

When an agent like Claude Code implements a feature, it explores the existing code, modifies several classes, adds functions, writes tests, and hands back work that compiles and whose tests pass. Those two signals say the implementation is technically correct. They say nothing about how faithful it is to the business.

Three kinds of drift slip under those two checks. The agent can use a second name for a concept that already had one — "purchase order" alongside "order" in an ERP. It can bring back a notion the team had abandoned. It can create a rule that contradicts another one elsewhere in the code: a confirmed invoice that becomes editable again through a new path.

None of this drift breaks a test, because the tests cover the behaviour the agent has just written, not the domain model it should have respected.

Why it matters

The risk changes scale as agents take on a growing share of the changes: every task is a chance for the agent to rebuild its own interpretation of the business, and the gaps add up without any existing check seeing them. What is missing is a shared business reference, outside the code the agent is modifying, to hold its work up against.

Nuances and limits

The phenomenon is not specific to agents: a human developer introduces the same drift. What changes is the volume and the speed, and the fact that an agent has no memory of the discussions that settled the vocabulary and the rules.

Open questions

• What proportion of the business drift introduced by an agent does a human reviewer actually spot in code review?