Decision drift is the growing mismatch between the engineering decisions a team believes are in force and the behaviour its code, documentation or coding agents actually produce. Agentic development accelerates the problem because each task may begin with incomplete context and still generate a plausible implementation.
Decision drift is not ordinary code drift
Architectural drift usually describes implementation moving away from an intended architecture. Decision drift begins one level earlier: the governing decision itself is absent, ambiguous, stale or undiscoverable. The resulting code may look locally correct while violating a constraint that exists only in an old review, issue or teammate's memory.
For example, a new account-deletion endpoint may pass its tests and match surrounding code. It is still wrong if the accepted product decision requires a 30-day restoration window and the agent was never shown that decision.
Why coding agents amplify it
A coding agent works from the context assembled for the current run. It does not automatically share the accumulated memory of the people who designed the system. When a repository contains several plausible patterns, the agent can confidently choose one that the team previously rejected.
More capable models reduce some implementation mistakes, but capability does not restore missing project authority. If the relevant decision is not present or discoverable, the model is being asked to guess.
The observable symptoms
Teams usually notice decision drift indirectly. The same architectural question returns in several pull requests. Reviewers repeatedly explain why an apparently sensible approach is forbidden. Different agents receive slightly different instruction files. Documentation says one thing while the merge gate checks another.
- Previously rejected alternatives reappear as new proposals.
- Review comments carry critical rules that never reach the next task.
- A decision is documented but cannot be found from the question an agent asks.
- A policy is described as enforced even though no deterministic check exists.
How to reduce decision drift
Keep accepted decisions in the repository, validate their lifecycle and relationships, and give every agent a common read-only retrieval path. Add deterministic enforcement for the subset of constraints that can be checked objectively. The remaining judgement-based decisions should stay visible as recorded guidance rather than being presented as automated guarantees.