writings · 10 Apr 2026
The AI code trust problem
AI coding assistants are genuinely useful. They accelerate the boring parts, handle the boilerplate, and produce clean code faster than most engineers can type. The problem they create isn't in the code. It's in the zoom level.
When you brief an AI on a specific problem, it solves that specific problem — inside the architecture you already have, using the patterns already established, without questioning whether either of those are still the right choice. It has no vantage point from which to say "actually, this whole approach is wrong." Every decision looks locally reasonable. The abstractions compound quietly. Six months later the codebase is doing something far more convoluted than the underlying problem ever required.
This isn't a failure of the AI. It's a property of how these tools work in 2026 — they're very good at the next step and structurally blind to the wrong direction. The tooling will improve. But the habit of stepping back and questioning abstractions is worth building regardless.
What drift looks like
It rarely announces itself. There's no moment where the code becomes obviously wrong. Instead there's a gradual accumulation: a workaround that made sense given the existing structure, an abstraction that solved last sprint's problem but is slightly in the way now, a design decision that nobody documented and everyone has quietly routed around.
The AI wasn't wrong to make any of those moves. It was working with what it had. The problem is that nobody zoomed out to ask whether what it had was still fit for purpose.
The habits that prevent it
The fix isn't to use AI less. It's to build a practice around the thing the AI won't do on its own.
Document requirements before you build anything. Not after, not as you go — before. A brief that forces you to articulate what you're building and why is also the zoom-out moment that shapes the AI's context. It catches course corrections early, when they're cheap.
Maintain a /docs folder with a running history of design decisions. Include a mini-projects log — what was tried, what was rejected, what assumptions were made. This is the institutional memory the AI doesn't have. When you come back to a decision six weeks later, you want to know why it was made, not just what it is.
Every few iterations, pause. Ask the AI to review what it built — not to extend it, but to critique it. A useful starting point:
do a thorough code review and look for bloated abstractions
or cross-coupling that could be simplified without changing
behaviour. be direct — I want honest critique, not reassurance.
"What should we build next?" keeps you zoomed in. "What would you do differently?" is the question that finds the drift.
Don't be afraid to break things. A course correction that requires rewriting a module is a good outcome if it simplifies the system. The reason engineers avoid this isn't stubbornness — it's that breaking things without tests is genuinely risky. Get the AI to write tests before you refactor. Tests are what make stepping back safe rather than destructive.
The pattern
before ( feature.build ) {
// zoom out before you zoom in
> document requirements // what are we building and why
> document design decisions // write to /docs before you code
> check prior decisions // does the existing architecture still fit
}
while ( feature.in_progress ) {
> build with AI
> get AI to write tests // before you ship anything
every N iterations {
// pause and zoom out
> review abstractions // are they still serving the problem
> ask AI to critique itself
// prompt: "do a thorough code review and look for bloated
// abstractions or cross-coupling that could be simplified
// without changing behaviour. be direct."
if ( course_correction needed ) {
> break things // tests catch the fallout
> update /docs // record why the decision changed
}
}
}
AI-generated codebases accumulate a different kind of debt than hand-written ones — not poor quality, but shallow understanding and drifted abstractions. The code reviews that matter aren't the ones that happen after each PR. They're the ones that happen every few weeks, where someone asks whether the architecture still fits the problem.
That's what check the vibe is for. If you're not sure whether your codebase has drifted, start at check-the-vibe.app.