You can usually tell when someone’s actually spent time building a complex system with an AI coding agent.
I don’t mean generating a quick app, getting it to work, and walking away. I mean building over time—across multiple stacks, long sessions, repeated changes, and hundreds of back-and-forth turns between one developer and an agent.
Once you’ve done that, you start noticing where drift begins.
Drift is central to the theory behind the Scarab diagnostic suite.
Scarab looks for drift inside codebases: places where a repository is no longer coherent with itself. That drift can exist in code written by developers, generated by AI, or built through some combination of both.
But while developing Scarab with an AI coding agent, I started noticing a separate kind of drift.
Because I was already looking at software through the lens of drift, I could see where the agent itself was likely to lose the thread—where its interpretation of a workflow, responsibility, or architectural boundary could start moving away from what I actually meant.
These are AI-specific drift surfaces.
They’re separate from the repository drift Scarab diagnoses, although one can eventually create the other.
The agent encounters something ambiguous. It interprets it one way. It carries that interpretation into the code. What begins as drift in the agent’s understanding can later become drift inside the repository.
Naming is one of the simplest examples.
Naming has always mattered in software, but it matters differently when the thing reading and modifying your code is a language model.
An AI coding agent reconstructs the system through language.
Function names, filenames, workflow names, comments, schemas, tests, documentation, and folder structures all shape how it understands the codebase.
The repository becomes a persistent prompt.
Imagine a system with two document-search workflows.
The first searches for ownership and boundaries: where a responsibility lives, which part of the system controls it, and what rules govern it.
The second searches for implementation examples: the actual code, syntax, or scripts showing how that responsibility has been expressed.
They’re related, but they’re not doing the same job.
One finds the boundary.
The other finds the implementation.
Now imagine both workflows are described as some version of “guidance search.”
The developer may understand the difference because they remember why each workflow exists.
But the names don’t preserve that distinction.
That’s a drift surface for the agent.
Later, when the agent is asked to extend one of those workflows, the language may lead it toward the wrong abstraction. It may combine responsibilities that were meant to stay separate or create new code based on a blurred interpretation of the architecture.
The code may still work.
But the agent’s understanding of the system has shifted.
And once that shifted understanding begins shaping new code, the repository can start drifting too.
This is the kind of thing you don’t necessarily see when you’re only building quick wrappers or short-lived prototypes.
In a small build, the developer can still act as the system’s external memory. They remember what everything means and redirect the agent when it gets confused.
That doesn’t scale.
In a larger system, the codebase has to carry its own meaning. Important boundaries can’t exist only in the developer’s head. They have to be expressed clearly enough for the agent to reconstruct them later.
That’s why ambiguous naming isn’t just messy code.
It’s a point where AI drift can begin.
A weak name gives the agent a weak map. And a weak map affects how it searches, retrieves context, chooses abstractions, and decides where new code belongs.
Building a product that detects drift in codebases taught me how to see drift in the process of building with AI.
And I think we’re going to need a much better understanding of those drift surfaces as AI becomes more involved in maintaining and extending real software systems.
Because sometimes the code still works.
The architecture has already drifted.
Top comments (0)