Rolling it out

By the end you can run agents safely in a real repository and start a rollout the way most successful ones start: with one engineer.

TL;DR

• On a real repo, give agent work its own worktree, hook both the agent and git, and keep a human review floor that no review bot replaces.
• Most adoptions start with one engineer, not three roles: use it yourself, write it up, teach a peer, then recruit the lead and the manager. Month one shows almost no gain; it compounds after.
• Name the two engineer archetypes and plan for the vendor's bad week before either finds you.

Guardrails for a real repo

The agent is one more author with write access, so give it the boundaries every author gets.

These repo-level habits sit on top of Chapter 2's five layers and matter most on yellow codebases (Chapter 8). The human review floor that no review bot replaces is Chapter 5's.

Worktrees

Every agent session gets its own git worktree.

A worktree is a separate checked-out copy of the repository on its own branch. The agent can experiment, fail and retry there without touching anyone's working copy. Good work goes through normal PR review; bad work is a deleted directory. Without one, the agent contends with your unfinished local work and you spend an hour finding out what changed.

Two kinds of hooks

Hook the agent, hook the repository, and run the same checks in CI.

• The agent hook (hookify, or your agent's equivalent) reads the proposed action and allows it, prompts you or blocks it. Aim it at areas too dangerous to change without senior review: cryptography, payments, data migrations, anything regulatory. Committed to the repository, five to ten rules is usually enough on a yellow project. AGENTS.md is the polite request; the hook is the firm boundary.
• The git hook runs for whoever is committing - you, a teammate or the agent - so one check covers every author. Fast checks (format, lint, typecheck, secret scan) run at commit, tests and the build at push, and a hook manager with versioned config makes sure the hooks are installed on every clone.
• The escape hatch is --no-verify. Close it with a deny rule in the agent hook.

Local hooks are still fast feedback, not enforcement: skippable, configured in a file the agent can edit, and not guaranteed on every machine. The same checks in CI cannot be skipped from a laptop; with the hook config and the CI workflow behind a deny rule, that is the gate the agent cannot edit.

Keeping it alive

Rules rot, so someone owns pruning them.

The mistake journal and its champion are Chapter 6. For process mistakes, keep a failure watchlist: recurring failures, what triggers them and the team's standard response. Review it every month or so and retire what is fixed.

The outer loop

Run the agent unattended only under a written contract.

The outer loop re-invokes the agent until a condition holds. It adds attempts, not judgment, so it multiplies whatever your inner loop permits (Chapter 4). Use it on GREEN codebases only (Chapter 8), on many similar, verifiable, reversible units, and read the pull requests in the morning.

Before the first unattended run, write five lines: a stop condition a machine can evaluate; a budget; a gate the agent cannot edit; fresh context each iteration with state in the repository; isolation sized for absence (own worktree, sandbox on, no production credentials, network constrained). Appendix B.6 is the form, with the four signs that mean stop before you relaunch.

How do you roll out AI coding agents on a team?¶

Start with one engineer who refuses to give up, not with a program.

The first time I taught the three-role rubric, an engineer in the back row said: "My manager has not heard of agentic AI. My lead does not have time. I am the only person on my team who cares. What do I do?"

The three-role arc would stall for him in month two, when the procurement conversation never happens. The grassroots arc would not, and it is how most successful adoptions in 2025 and 2026 started: one person plays champion, then de facto lead, then manager-advocate, in sequence. I have watched it succeed twice.

• Month 1: use it on your own work. Architecture reviews, AGENTS.md drafts and the six-phase loop on code you own, inside existing policy. No announcement; build evidence quietly.
• Month 2: write it up. A one-page memo: stories shipped, time saved, honest notes where the agent did not help. Share what you did; do not pitch adoption.
• Month 3: teach the peer who asks. Write a bigger case together and invite your tech lead to a walkthrough.
• Months 4-6: the lead recruits the manager with evidence and two engineers asking for the same workflow.

By month six it looks like the ideal arc at month three, in twice the time. The trade-off: the grassroots arc is fast to start and fragile, because if the one engineer leaves before peers and management are recruited, the practice dies with them. The three-role arc starts slower and survives a departure. With a manager who knows agents, an engaged lead and budget, run three roles; with only your own hours, run the grassroots arc.

The 90-day arc

The curve is asymmetric: the first thirty days produce almost no measurable productivity.

Days 31-60 show visible gains on the green project; days 61-90 compound across the team. Companies that measure at thirty days will be disappointed, so tell stakeholders up front. The full calendar is Appendix B.5.

Role commitments

Each commitment is small enough to fit alongside normal work.

The champion learns the workflow first. They need to be the most willing to invest the first sixty hours, not the most senior.

• [ ] Week 1: install the agent, run the architecture review (Chapter 7) on a familiar codebase and commit the artifact.
• [ ] Week 2: write the first AGENTS.md, under fifty lines, and invite additions by pull request.
• [ ] Weeks 3-4: run the six-phase loop (Chapter 4) on three small features; log friction in the mistake journal.
• [ ] Months 2-3: three medium features with others taking single phases, then hand the role off; by day 90 another engineer runs the workflow as fluently.

The lead decides which projects get the agent and keeps the traffic light.

• [ ] Week 1: classify the top five projects against the eight kill signals (Chapter 8) and share the colors.
• [ ] Weeks 2-4: for one project per color, write down what would have to change to move it up.
• [ ] Months 2-3: track cycle time, defect rate and reviewer time (noisy; measure anyway), then present honest results, including where the agent did not deliver.

The manager owns budget, procurement and governance sign-off, and shields the team from premature metrics. Their page is Appendix A, with the 20-engineer engagement where agent-touched PRs (41% of the total) ran 28% below the pre-agent cycle-time baseline, defects within noise.

Two archetypes that kill rollouts

Treat each as a structural problem with a structural fix, not a character flaw.

The principled skeptic is the senior who has seen AI hype cycles before, will not use the agent and reviews agent-led PRs with extra hostility. Either the team works around them and the codebase splits into agent-friendly and agent-hostile territory, or they win the argument and the rollout stalls. Do not try to convert them; give them a boundary: "your modules, your rules, the agent will not touch them; everywhere else the team standard applies." And do not let every agent-led PR queue behind them, or you have granted a veto nobody intended.

The uncalibrated delegator skips the careful read because "the agent always does it right". Defects compound, the team blames the agent instead of the missing review step, and eventually the engineer cannot debug what the agent helped build. Every agent-led PR gets the same human review as a human-led one. For the first month, pair them with a senior who reads the output line by line.

The vendor will have a bad week

Plan for the agent being unavailable.

I watched a team's velocity halve for a week when their primary model was rate-limited. In June 2026 the largest vendor's newest flagship tier was pulled worldwide days after launch and stayed unavailable for nearly three weeks; teams with fallbacks ran them for real; teams without rediscovered their old setup under deadline. Keep a non-agentic fallback for time-sensitive work, a senior who can still ship a hotfix at three in the morning, and a runbook for "the agent is throttled and the customer is waiting".

When it breaks

Do this Monday

• [ ] Set up one git worktree on a project you are about to dispatch the agent on, and do the agent's work there.
• [ ] Pick your role - champion, lead or manager - make the first commitment from its checklist this week, and put it on a calendar.
• [ ] Add one agent-hook rule on your most dangerous directory, a deny rule on --no-verify, and the same checks in CI.
• [ ] Write the fallback for a vendor outage week: who ships the hotfix without the agent.

Go deeper

• Templates: Appendix B.5, the 90-day calendar with the manager track; B.6, the outer-loop contract; B.4, the kill-signal worksheet.
• Deep dive: Appendix D, Chapter 9 - the outer loop's lineage and vendor timeline, and the two kinds of hooks in full.
• For managers: Appendix A.
• Sources: Appendix C.