How AI Code Review Went From Distrusted to Mandatory in a Year

For the first few months, most of the team ignored it.

We had added an AI reviewer to our pull requests, and early on it was mostly noise — fewer than 40% of its comments got accepted. People skimmed past it.

A year later it was a mandatory step. Not because anyone ordered it — because it had earned the job.

The reframe: demonstrate, don’t mandate

Most AI rollouts I’ve seen die in a training session. The licences get bought, a memo goes out, and three weeks later everyone is back to their old habits. Engineers don’t trust a tool they’ve been told to use.

So we didn’t announce anything. We took the single most painful part of our process — code review — and pointed AI at that one thing.

Why review? Because it was the biggest bottleneck we had. A growing pipeline of work meant reviewers wading through long lists of code changes, and the fatigue was real: the more you review in a day, the worse you review. Fix the worst pain first, and the win is obvious to everyone watching.

How the trust curve bent

We started small — a hackathon experiment on one slice of the workflow, not an all-at-once change. It worked well enough to roll out properly.

Then came the part most teams skip. We treated the AI reviewer as something to train, not just install: engineers learned to prompt it, correct it, and feed back what a good comment looked like on our codebase. Over months it learned our conventions and our design philosophy.

MONTH 0    Installed. Comments are generic. <40% accepted. Mostly skimmed past.
MONTH 6    Trusted for the first pass — catches the line-by-line issues humans miss.
MONTH 12   ~90% accepted. Knows the codebase. Flags new changes that contradict
           old decisions the team had forgotten. Now a mandatory review step.
NOW        Testing multiple agents; human review optional on trivial changes.

The surprise was that last row. The reviewer’s most valuable habit was not catching minor issues — it was institutional memory: spotting when a new change quietly contradicted an architectural decision made a year ago that everyone had forgotten.

What it actually changed

The numbers followed the trust. Average review time fell from around two days to a few hours. The number of pull requests we merged more than doubled. And the fatigue that had been our worst bottleneck mostly went away, because the AI took the first, dullest pass and the humans spent their attention where it mattered.

Where it didn’t help

AI-forward is not uniform, and pretending otherwise is how you lose the trust you built.

Implementation is where it shone. The formal, cross-functional work — PRDs, getting several departments to agree on the right problem — barely moved. That is not a tooling gap; it is a human-alignment problem, and it only speeds up when every department shares the same AI discipline. QA is improving, but slowly: letting AI near it means handing over access to production logs and metrics, and that needs guardrails built before speed. Post-release monitoring, on the other hand, has already improved a lot.

That pattern — implementation races ahead while the rest of the process lags — is Amdahl’s law applied to AI adoption: speed up one part and the parts you leave untouched set the ceiling.

The takeaway

You don’t get an organisation to adopt AI by mandate. You find the part of the work that hurts most and point AI at just that — then let a visible win recruit the next team. Trust builds from there.

And keep the discipline. AI-forward is not vibe-coding; it is the same engineering rigour as before, applied faster. The fastest way to make AI stick is to let it earn the job, one bottleneck at a time.