I’ve written about why AI coding rollouts die: tooling decisions wearing transformation costumes, ten private workflows, trust that ends at the first incident, review left unrestructured, a harness nobody owns. The follow-up question arrives in my inbox weekly, and it deserves its own post: fine, what’s the sequence that works?
Here’s the sequence I give them. It’s derived from the harness I operate daily, from moving that setup between products, and from watching the failure patterns up close, so read it as a playbook with strong opinions rather than a log of a hundred rollouts. It assumes a Rails team, an existing codebase, a leadership that wants delivery instead of a demo reel, and an agent that can load files from your repo (we run Claude Code; the sequence doesn’t care, the harness does). One prerequisite before anything: settle what code is allowed to leave the building, in writing, before the champion sends a prompt. Phase two dying in a compliance meeting is a fully preventable death.
Phase one: a champion and a repo, not a mandate
Start with one senior engineer who actually wants this, and give them explicit permission to spend real time on it. That means real tickets done through agents, slower at first, with the failures treated as findings, rather than twenty percent of attention after hours. The champion’s deliverable is the beginning of a harness that lives in the repo, where the next person can inherit it; their own productivity is a side effect.
That distinction decides everything downstream. A champion who gets fast personally has built a private workflow, and private workflows die with their owner’s job change. A champion who turns every lesson into a committed artifact (a conventions file the agent loads, a check that fails the build, a spec template) is building the thing the rollout actually needs. Enforceable conventions come first, because they’re the difference between the agent following your codebase’s rules and following its training data’s habits.
The exit criterion for phase one is concrete: a stranger to the experiment can clone the repo, run an agent on a small ticket, and get output that passes the gates and looks like your codebase wrote it. Until that’s true, there’s nothing yet for a second person to inherit.
Phase two: one team, real tickets, restructured review
Expand to one team, never the whole org, and put them on the normal backlog. Pilot tickets invented to be AI-friendly prove nothing; what you want is the Tuesday-grade migration with the weird edge case.
Two structural changes have to land in the same phase, and skipping the second is the usual way phase two dies. First, the team works from the shared harness and feeds it: every “the agent did something dumb” moment ends with a rule, a check, or a template fix committed, not with a shrug. The harness has a named owner who treats it as a product. Second, review gets restructured before the volume arrives, because the bottleneck moves to review immediately: machines settle hygiene and conventions before human eyes, humans review intent against the spec, and a short written list of blast-radius code keeps line-by-line treatment.
Expect a dip. Phase two starts slower than the old way and stays slower until the harness gets dense enough to trust. Say that out loud before it starts, because a dip nobody predicted reads as failure, and a dip everybody predicted reads as the plan.
What to measure, and what to ignore
Ignore usage metrics, because seats active and prompts sent measure compliance, and compliance was never the problem. The numbers that tell the truth are the delivery ones you already track plus the two queue numbers from the review gap: time from PR opened to first human action, and revert rate while throughput climbs. Capture both before phase two starts, or the dip and the recovery will be invisible. The exit criterion for phase two follows from them: the queue number back at or under its baseline with throughput above it, for a few consecutive weeks, on the normal backlog. If throughput climbs and trust falls instead, you’ve built a faster way to make work for your reviewers, and the answer lives in the gates rather than in more enthusiasm.
The qualitative signal worth tracking deliberately: who asks to join. A rollout that’s working recruits its own phase three, because engineers talk, and “their tickets close and their Fridays are calm” is the most persuasive demo that exists.
The two revolts, and what they’re telling you
Senior skeptics revolt first, and they’re usually right about something. The skeptic who says “the agent writes garbage in our codebase” is reporting a missing convention; the one who says “I can’t trust green” is reporting a missing gate. Recruit them to write the rules they keep citing, because a skeptic’s convention file is twice as strict and twice as trusted. The revolt you should actually worry about is quiet: people nodding in the standup and working the old way. That one means the harness isn’t yet better than their habits, and the fix is making it better, since mandating harder only deepens the quiet.
Juniors are the second, quieter issue: the rollout shrinks the learning channel that code-writing used to be. Be honest that this is a real cost, and rebuild the channel deliberately: juniors review specs with seniors, own the harness backlog, and ship their own agent-built tickets with tighter blast radius. What you can’t do is pretend the old apprenticeship survives unchanged.
Phase three: expansion is earned, not scheduled
The results from one team argue for the next team; a calendar doesn’t. When the second team joins, they inherit a harness that already encodes months of lessons, which is why their dip is shorter, and why this whole sequence beats the all-at-once rollout that spends its political capital before anything works. We’ve watched the same structure transfer between codebases on stacks we don’t even usually touch, and what moved was the repo.