Why your AI coding agent goes off track
You gave it a clear instruction. Forty minutes later it has built something adjacent - competently, with passing tests. Here is the actual mechanism, and the check that catches it.
1. The goal is in the scrollback, not in the working set
Your instruction lives in a conversation history the agent does not reread. What it rereads is the current plan and the files it just touched. Every message you add pushes the original goal further from the point of attention - it is still present, just no longer dominant.
This is why the failure feels sudden. Nothing was lost; the weighting simply shifted.
2. Every step looks locally correct
Agents optimize the task in front of them. If a helper function is slow, fixing it is a good local decision - even when your goal was memory, not speed. Each individual edit survives review. It is the sequence that diverged.
So nothing trips. Tests pass, because the code does what it says. Linters pass, because the style is clean. The build passes. Your original constraint was never part of any of those checkers.
3. Nothing in the pipeline compares work to intent
This is the structural gap. CI verifies that code works. Review verifies that code is good. Nothing verifies that the change serves the goal you started the session with - because until recently, nothing tried to represent that goal as data.
The check that catches it
Drift is a comparison between two things you can write down: the original goal, and the current plan plus execution activity. Make both explicit, score them against each other, and drift stops being a feeling and becomes a number with evidence attached.
intent-drift \
--original-goal "Reduce memory usage" \
--current-plan "Improve startup"Returns an alignment percentage, a drift level, and a recommendation - for example: pause and confirm the new plan is authorized.
What to do about it
- Write the goal down as data. Not a chat message - a field with text, constraints, and success criteria, so it can be compared rather than remembered.
- Re-check at boundaries. Before a commit, before a large refactor, on a schedule. Drift is cheapest to fix in the step where it starts.
- Keep the check explainable. A score you cannot trace to specific text gets ignored. Every provider should cite what it saw.