How do you get an engineering team using AI well rather than just using it?

The two-month problem

A team turns on AI coding tools. Throughput rises immediately and everyone is pleased. Around month three the incident rate climbs, senior engineers spend their days reviewing code they did not write and do not trust, and someone suggests the tools were a mistake.

The tools were not the mistake. Authoring got faster and review did not, so the bottleneck moved to the most expensive people on the team and nobody noticed until it hurt.

What we build

Repository context an agent can read: the architecture, the conventions, and the things that look wrong but are deliberate. An agent with good context produces changes a reviewer approves in a minute. Without it, it produces plausible code that takes twenty minutes to evaluate.

Gates keyed to risk rather than volume. Tests, documentation, and scaffolding merge on green CI. Anything touching authentication, payments, data migration, or infrastructure gets a named human, and that list lives in branch protection rather than in someone’s memory at six on a Friday.

Delivery practice where it is the actual constraint. If your pipeline takes forty minutes and flakes twice a day, faster authoring changes nothing, and we will fix that first.

What we measure

The four DORA metrics, plus two more: the revert rate of AI-authored changes compared with the rest, and reviewer time per change. Team level, never individual. Individual productivity scoring from AI telemetry measures activity rather than outcome, is trivially gamed, and costs you the trust the rollout depends on.