From detection to prevention: the missing feedback loop in AI coding

A year ago the hard part of building software was writing the code, but today, for a growing share of teams, the code mostly writes itself. The agent scaffolds the handler, fills in the test, and wires the route, so what used to take an afternoon now takes a prompt.

That means the bottleneck has moved. It isn't generation anymore, it's coherence, the question of whether the thousandth thing the agent generated still agrees with the first nine hundred and ninety-nine. And coherence is exactly what a stateless agent is worst at, because every fresh session starts with no memory of the conventions your codebase spent months establishing. The agent makes reasonable choices, they just aren't your choices, and over enough sessions the codebase quietly stops agreeing with itself.

We named that gap drift and built a scanner to measure it. This post is about the next move, which is getting the agent to check for drift before it writes a line rather than after it ships.

Two halves of the same problem

Almost everything aimed at AI-coding quality so far falls into one of two buckets.

• +Input systems, like Claude memory, Cursor rules, Copilot context, or your CLAUDE.md, feed the model context so it generates better code and make the agent more likely to do the right thing in the first place.
• +Output systems, like linters, PR review bots, and drift scanners such as VibeDrift, inspect the code that actually shipped and tell you where it went wrong.

Both are necessary, but neither is sufficient, because they share a blind spot, which is timing. An input system can't guarantee the agent followed the rules, since a rule in a config file is only a suggestion and across 200 sessions suggestions erode. An output system only speaks up once the code already exists, which means the drift is already written, already reviewed, and already something you have to pay to find and then pay again to fix.

Detection happens too late

This is the uncomfortable truth about our own first product. Even a good scanner is really a postmortem, because it runs in CI or whenever you remember to run it and then hands you a list of contradictions the agent introduced hours or weeks ago. By then the drifting file already has siblings, other code already imports it, and the "wrong" pattern has started to look like a second house style, so fixing it is no longer a one-line nudge but a refactor.

The cheapest moment to prevent drift is the moment before it's written, while the agent is still deciding how to write orderHandler.tsand hasn't committed to raw SQL yet. At that instant the only question that matters is how the rest of the codebase already does this, and until now the agent simply had no way to ask.

MCP changes when the check happens

The Model Context Protocol is the emerging standard that lets a coding agent call external tools while it works, mid-task and mid-thought, instead of as a separate step you run later. It's the same plumbing that lets an agent read a file or hit an API, except that it's a clean, portable contract spoken natively by any client, including Claude Code, Cursor, and a growing list of others.

VibeDrift now ships as an MCP server, and that single change moves drift control from the output side to the input side without giving up what made the output side trustworthy. The agent can now stop, mid-edit, and ask the codebase about itself:

It's the same drift engine and the same dominance-vote evidence, only applied at a different moment, so instead of grading the code after it's written, VibeDrift now informs it while it's being written.

What the agent can ask

The server exposes five tools. Four of them are pure lookups against your codebase's own established patterns, and because they run entirely on your machine they cost nothing.

• +get_dominant_pattern answers how the codebase handles data access, errors, or auth in this directory, returning the majority convention along with how strong the consensus is.
• +check_file_drift answers whether the file the agent is about to touch already deviates from its peers.
• +find_similar_functionanswers whether the agent has already written something that does this, which kills duplicate logic before it's born.
• +get_intent_hints surfaces the rules you actually declared in CLAUDE.md or .cursorrules so the agent honors them instead of rediscovering them.
• +validate_changeis the gatekeeper, where the agent shows the code it's about to commit and asks whether it conforms.

The last two can opt into a deeper check, a semantic analysis that understands what code does and not just how it looks. A deep check draws only 1/50 of a deep scan from your monthly pool, so an agent can lean on it hundreds of times in a session without burning through your budget, and nothing but the single function being checked ever leaves your machine, which happens only when deep mode is explicitly invoked.

In practice the loop looks like this. You ask the agent for a new endpoint, and before writing it calls get_dominant_pattern and learns the repo uses a repository layer rather than raw SQL. Then it calls find_similar_functionand discovers half the query already exists, so it writes the handler the way the other nine handlers are written, reuses what's there, and runs validate_change before handing it back. The drift never enters the codebase, so you never pay to find it or fix it.

Does it actually change what the agent writes?

That's a fair question, and the one we were most determined not to hand-wave, because it's easy to bolt a tool onto an agent and simply assumeit helps. So we built a controlled eval in which the same model, Opus 4.8, does the same tasks both with and without VibeDrift's signal, and the output of both arms is graded by an independent drift pass rather than by the signal that produced the guidance, so the test can't mark its own homework.

The honest headline is a shaperather than a slogan. When the codebase's convention is something the model would reach for anyway, the signal changes nothing, because the agent conforms for free and the tool is redundant. The signal earns its keep precisely where the agent would notconform on its own, on conventions that go against the model's defaults, are held by only a minority of files, or simply aren't visible in the slice of the repo the agent can see.

You can watch the mechanism flip. Give it a repo whose house style is .then() chains, which is the opposite of what a modern model writes by default, and the difference is stark:

// agent alone: its own default, which is drift in THIS repo
async function getUser(id) {
  const row = await db.query(...)
  return row
}

// agent + VibeDrift signal ("this repo uses .then() chains")
function getUser(id) {
  return db.query(...).then((rows) => ...)
}

The signal pulled the agent off its own prior and onto the repo's convention, which is the one thing a stateless model can't do for itself. We then ran it properly, as a matrix of conditions with ten trials each and 95% confidence intervals. In the hardest case, a non-default convention the agent couldn't see in its context, VibeDrift's signal cut drift by a reproducible margin, with a 95% CI of [0.57, 1.11]that clears zero, so it's signal and not luck. And in every condition where the agent could already infer the convention, whether because it was the model's own default or because the conforming files were sitting right there in context, the effect was a tight zero.

That second half matters as much as the first, because a guardrail that only fires when the model is already right is theater. VibeDrift earns its keep precisely where the convention is hard to see, which is the large, established codebase rather than the toy repo. You can read the full matrix, the methodology, and the cases where it did nothing here.

Why this matters beyond your repo

Step back from the single codebase. If AI is going to write the majority of the world's new code, and it increasingly is, then the scaling limit on software isn't how fast we can generate it but whether the generated code stays internally coherent as the volume explodes. A codebase that disagrees with itself is the new form of technical debt, and it accrues faster than any human review process can pay it down.

That problem doesn't get solved by one vendor's closed integration. It gets solved by a portablesignal, a standard way for any agent in any editor to ask any codebase how it already does things and to be told with evidence. That's why shipping on MCP matters more than shipping yet another IDE plugin, because the drift signal isn't locked to one tool or one model. When you point your agent at the codebase through an open protocol, the convention travels with the repo rather than the vendor, with no marketplace gatekeeper and no lock-in, just one config block that works wherever your agent works.

The optimistic version of the AI-coding era isn't humans rubber- stamping a firehose of plausible code, it's agents that carry the codebase's standards with them and hold themselves to the house rules. Putting the drift check inside the loop, over an open standard, is a small but real step toward that.

Detection, prevention, and what's next

There's a clear progression here, and we're building along all three rungs of it.

1. Detect, with the scanner, which measures the drift that already exists and hands back a Vibe Drift Score with the evidence, and is still the right tool for auditing a repo or gating CI.
2. Prevent in the loop, with the MCP server, which moves the check to the moment before the code is written, inside whatever agent you already use.
3. Prevent at the source, with VibeLang, a language where behavioral intent is a compiler-enforced construct, so the agent can'tdrift because code that contradicts the declared architecture won't compile.

Detection tells you, in-loop prevention nudges you, and language-level prevention makes it impossible, and MCP is the rung that just landed.

Try it in your agent

The MCP server rides on the same package you already run, so you just add one block to your client's MCP config, and the same shape works in Claude Code, Cursor, and any MCP-compatible agent:

{
  "mcpServers": {
    "vibedrift": {
      "command": "npx",
      "args": ["-y", "@vibedrift/cli", "mcp"]
    }
  }
}

The local lookup tools are free, while the opt-in deep checks are a Pro feature and share your deep-scan pool at 1/50 per check. Full setup, including the per-client config paths, is in the guide.

If you'd rather keep using it as a scanner, nothing changed there, and the CLI works exactly as before:

npx @vibedrift/cli .

Website · MCP guide · npm

If the agent conforms to something it shouldn't, or misses something it should have caught, tell me, because the whole point is to put the codebase's standards where the code is actually written, and that only gets sharper with real-world feedback.

Free to scan locally, and the free tier includes 3 deep scans a month. Pro is $15/mo (50 deep scans plus the MCP server), Scale is $30/mo (100 deep scans), and any paid tier overages at $1 per scan.