There's a failure mode in AI-assisted development that nobody wants to talk about.

Not hallucinations. Not wrong architecture suggestions. Not the model confidently generating code that doesn't compile. Those failures are visible. You catch them in the first five minutes.

The failure mode worth worrying about is the one that looks correct.

A developer on one of our client projects was resolving merge conflicts on a pull request. Standard work. They used Claude to help untangle the conflict — reasonable, it's one of those tasks where AI genuinely helps. The output looked clean. The logic held together. It passed the review.

What nobody noticed: Claude had quietly removed authorization checks in the process.

Not because it was wrong about the logic. Because when you're resolving conflicts across multiple changed files, the model is optimising for coherence. It makes the code consistent. Authorization lines that appeared to be in tension with the merged state got smoothed over. The code was cleaner. It was also missing a security boundary.

A lead architect on the project caught it — but only because he was doing a deep read of the implementation. Not as part of any systematic review process. Just thoroughness.

That's a fragile safety net. And it doesn't scale.

Fast AI development without a governance layer isn't faster. It's just more expensive to clean up.

The Problem Isn't the AI. It's the Rate.

AI-assisted development doesn't just change how code is written. It changes how much code is written, and how fast.

When a developer working manually produces output, the rate of change is bounded by human speed. Review processes were designed for that rate. A PR with fifty changed lines gets a real look. The reviewer has enough cognitive bandwidth to notice what's missing.

When that same developer is AI-assisted, the rate changes. Fifty lines becomes two hundred. Two hundred becomes five hundred. Review processes designed for the old rate get applied to the new volume — which means they don't actually review anything. They skim and approve.

The merge conflict incident isn't a story about a developer being careless. It's a story about a review process that wasn't designed for the volume AI produces.

Manual review as the answer to this is not a strategy. It's hoping the problem doesn't compound.

The teams that find this failure mode in production are not the teams that were careless. They're the teams that applied careful, well-intentioned review processes to a development rate those processes were never designed for. The result looks the same either way.

What a Governance Layer Actually Looks Like

The response to this problem can't be "review more carefully." It has to be a system that runs whether you're being careful or not.

The merge conflict incident is one category of failure — a code correctness problem that slipped through review. Ungoverned spec drift is another: code that diverges from its spec without anyone noticing. Both point to the same root cause: AI-assisted development needs systematic oversight, not just careful reviewers. One of our engineers has been developing a background classification layer that addresses the latter — and together, both failure modes make the case for the same structural response.

The system runs as a pre-commit hook (a check that executes automatically before code is committed to the repository) — not a checklist you remember to trigger, but something that fires every time a file is written or edited in a Claude session.

The system classifies every change into one of four categories:

Internal — only comments or formatting changed. No functional impact. Ignored.

DI Extension (Dependency Injection) — dependency injection or interface extensions. Logged, lower urgency.

Options Change — configuration or behaviour parameters modified. Flagged for review.

Public API — changes to the external contract of a module. Immediate warning.

If the changed capability has an OpenSpec (the open-source spec framework) entry, the system references it. If the code has drifted from what the spec defines — or if the capability exists in the code but has no spec at all — it outputs a warning: Spec drift detected. Capability present, OpenSpec missing.

That warning surfaces immediately, in the session. Not in a code review three days later. Not when QA finds the breakage in the next sprint. Now, before the commit moves anywhere.

At that point, the developer either creates the missing spec entry or flags the change for review — the warning makes the decision visible rather than invisible.

The system is also designed to auto-archive: reading the logged changes and generating a spec entry for capabilities that exist in the code but don't yet have one. The goal is that ungoverned code generates its own governance record rather than existing outside the framework entirely.

The Phase That Closes the Loop

The current implementation catches drift and surfaces it. What it doesn't yet do is block.

The next phase is a push-blocking hook — a hard stop that prevents a commit from reaching the branch if no spec is detected. Not a warning. Not a flag for later review. A commit with no corresponding spec cannot move forward until that's resolved.

That's the logical endpoint of this approach: shifting from "we should review this" to "ungoverned code cannot ship." The warning system is a step toward it. The blocker is where it becomes structural.

Most teams are operating somewhere between "we should probably review AI output more carefully" and "we have a checklist." Neither is a system. Both depend on someone having the time, the attention, and the thoroughness of the architect who caught the missing authorization lines.

The question is what happens when that person is busy.

The Spec Is What Makes This Possible

None of this works without a spec as the reference layer.

Drift is only detectable if there's something to drift from. The classification system isn't looking for generic code quality issues — it's comparing what was built against what was specified. The spec is the ground truth. Without it, you're running diffs against nothing.

This is the less-obvious payoff of spec-first development. The obvious payoff is that AI generates better, more consistent code when it has a spec to work from. The less-obvious payoff is that the spec gives you something to audit against — a permanent record of what was intended, against which every change can be measured.

Most teams adopting AI tools focus on the generation side: how do I get better output, faster? The spec is what makes the governance side possible. You don't get to audit against intent if you never documented intent.

The Question Your Team Hasn't Asked Yet

If your team is using AI-assisted development today, the instinct is to focus on quality: is the code good? Is the output correct? Are we reviewing it carefully?

Those are the right questions for the rate of change manual development produces.

At AI-assisted development rates, there's a different question: do we have a system that catches what we don't know to look for?

Authorization lines removed in a merge conflict. A configuration option quietly changed. A public API boundary shifted in a way that's technically coherent but architecturally wrong. These are the changes that look fine on first read. They surface as incidents later — in QA if you're fortunate, in production if you're not.

The teams that find this failure mode in production aren't unlucky. They're operating with review processes calibrated for a development speed that no longer exists.

CIQ builds and operates AI-assisted development practices for enterprise engineering teams. If your team is scaling AI development and thinking about governance, get in touch.