Roll Out Autonomy in Stages

A team should widen rights only after the previous level is measured stably. The move from questions to an unattended patch is not one setting: it adds instructions, skills, environment, gates, and an incident process.

The rollout ladder goes bottom-up: read (the agent answers questions and builds a repository map), plan (proposes scope and verification but doesn't write), supervised patch (changes the workspace, every risky action confirmed), repeatable skill (one class of tasks goes through a verified workflow), isolated automation (a non-interactive run creates a patch artifact in a disposable environment), and controlled publication (a separate trusted step opens a PR after deterministic and independent gates).

To assemble a production gate step by step and see which conditions aren't closed yet, use the lab.

Before the first unattended run it's worth choosing a reversible task with no production side effects, limiting to one repository and one patch type, saving the failing baseline and the expected result, banning new dependencies and external writes, setting a timeout and budget, and running a game day: test failure, network denial, tool crash, and scope violation.

Don't automate uncertainty. If the acceptance criteria can't be observed or the owners disagree on the architecture, an unattended agent will only produce a disputed patch faster. Clarify the contract first.

The book's practical takeaway is short: the right prompt sets the task, project instructions keep local knowledge, a skill reproduces the workflow, hook and CI provide events and gates, sandbox and permissions limit power, independent review checks the result. Only the whole chain turns a coding agent into an engineering tool. All technical claims are verified against primary sources; their full list is in the next chapter.