The problem

An AI coding tool has read most of the public internet. It has never read your codebase the way your team understands it. So when you ask it for a new endpoint, it gives you the most statistically plausible endpoint — the average of ten thousand other people's repositories. Fluent, confident, and subtly wrong for you.

The code compiles. It passes a quick read. It uses a pattern that is perfectly reasonable somewhere. It just isn't the pattern your team agreed on six months ago, in a decision the model has no way of knowing about. This is the core failure mode: not bugs you can spot, but plausibility you can't. The output looks like it belongs. It doesn't.

One developer can absorb this. A team can't.

A single engineer using a single tool can catch the drift. They know the house style; they fix the import, swap the pattern, move on. The cost is small and it stays local.

Now multiply. A team of thirty, each running a different assistant — one on Copilot, one on Cursor, agents firing off their own requests. Same repo, same sprint, and every tool is independently guessing at your conventions. None of them are guessing the same way.

The damage isn't loud. It accumulates:

• Architecture drift. Decisions that took weeks to reach get quietly overridden in seconds. A service ships with non-standard auth middleware. REST endpoints appear in a repo mid-migration to GraphQL. Nobody decided this — the model just didn't know.
• Convention fragmentation. Three pagination patterns land in one module. Redux shows up in a codebase standardized on Zustand. Each choice is defensible in isolation; together they turn one codebase into several.
• Invisible policy violations. A JWT gets stored in localStorage. CORS is set to * on an admin route. A dependency with a known CVE gets pulled back in. These don't fail tests. They wait.
• Review burden explosion. Generation got faster; review didn't. Every AI-assisted PR adds surface area no one fully reads, and the reviewers who could catch the drift are the bottleneck the tools were supposed to remove.

Six months in, the codebase reflects the averaged instincts of a dozen models instead of the decisions of your engineering org. It still works. It just no longer looks like anything you'd choose to build.

Review is the wrong place to catch this

The instinct is to fix it downstream: tighten code review, add a linter rule, buy another scanner. And those help — at the margin, after the fact, expensively.

By the time generated code reaches review, the cost is already sunk. Tokens were spent. The developer has moved on and has to context-switch back. A reviewer has to reconstruct intent the model never had, decide whether a plausible-looking diff actually fits, and — if it doesn't — send it back to be regenerated. The loop is slow, it's manual, and it scales with output, which is exactly the thing AI made cheap.

Reactive tooling can only ever tell you what already went wrong. It can't tell the model what "right" means here — because by the time it runs, the model is done.

The gap

Stand back and the shape of it is clear. There's a moment — generation time, the few hundred milliseconds between a request and a response — when the model decides what your code will look like. Nothing sits in that moment carrying the knowledge of how this codebase actually works. Your conventions live in people's heads, in old PRs, in an ADR three folders deep. The model never sees any of it.

Everything downstream is cleanup. The leverage is upstream, at the point of generation, before the plausible-but-wrong code is ever written.

That's the slot Unyform fills. Instead of catching drift after review, it gives the model your organization's context and rules while it generates — so the code comes out aligned the first time.

See governance vs. review for why the point of generation beats the point of merge, and what is Unyform for how the pieces fit together.