Preface: How to Read This Book

Who this book is for

The book has two kinds of reader, who need different things from the same evidence. Engineering leaders decide where money, headcount and risk go. Tech leads and staff engineers decide how one phase of delivery actually changes on Monday. The book is written in three parts so that each can take the path it needs.

• Engineering leaders: read Part I in order. It makes the case, defines the maturity model every later chapter uses, and shows what other organisations measured.
• Tech leads and staff engineers: read the maturity model, then jump to the Part II chapter for the phase you own. Each one has the same shape, from the ladder to the migration steps.
• Running a migration: Part III is the plan. Assess where you are, run a 90-day pilot, scale it, and decide in advance what would make you roll back.

Part I, The Case and the Map, argues that the bottleneck moves from writing code to verifying it, defines the ladder, grades the public cases, and shows how to read the economics behind them. Part II, Phase by Phase, takes the eight phases in delivery order, from requirements to maintenance, and ends with security, permissions and blast radius, because that is where every destructive incident on record sits. Part III, The Migration, turns the map into a sequence: assess, pilot, scale, staff, measure and, when the numbers say so, roll back.

The map in one picture

The book's map is a grid: eight phases down the side, five levels across the top. Each cell holds an observable criterion and the best public evidence that anyone works that way. The picture below compresses the grid to one question per cell: has anyone published evidence of an LLM-based tool working at this level in this phase?

Public evidence for LLM-based AI, by phase and level (to October 2026)

               L0   L1   L2   L3   L4
Requirements   -    ●    ●    ○    ·
Design         -    ●    ●    ·    ·
Coding         -    ●    ●    ○    ·
Review         -    ●    ●    ○    ·
Testing        -    ●    ●    ●    ·
CI/CD          -    ●    ●    ○    ·
Operations     -    ●    ○    ○    ·
Maintenance    -    ·    ●    ●    ·

●  a published, measured result (any evidence tier)
○  partial: mechanism only, volume only, or self-reported
·  none found
-  L0 means no AI in the phase; not scored

Read it by column. L1 and L2 are crowded. At L3, measured results exist only in maintenance and testing. Coding has L3 volume without an outcome measure, operations has one narrow class of incidents (self-reported), and requirements, review and CI/CD show only a mechanism or a partial signal. Design has no L3 evidence at all. The L4 column is empty for LLMs in every phase. Each cell, with its sources, is in the grid of the maturity model.

The grid itself is the book's contribution. No published model scores each phase separately. Almost every model is a single scale for coding, usually borrowed from the SAE J3016 driving levels, as in Sourcegraph's levels of code AI and Hassan et al.'s levels for software engineering. A single scale cannot say that a team runs coding at L2 while operations sits at L1, or that one task type in a phase is further along than another.

What a level means here. A phase's level is what a human reviews, and when, read against the authority the AI actually holds. At L2 a human reviews every artefact the AI produces. At L3 a human reviews an evidence bundle, a sample or only the items routed to them. If the AI's credentials reach further than the review mode suggests, the higher reading wins: an agent holding a production-capable token is at L4 for whatever that token reaches, whatever the team calls it. Levels are scored per named task type, not per phase or per tool. The rules are set out in full in the maturity model. If you know this site's autonomy levels page, note that it counts from L0 = "Suggest", so its numbers sit one step below the book's.

Three ideas to carry through the book

1. The bottleneck moves. When generation gets cheap, the work that remains is deciding what to build and checking what was built. The 2025 DORA report, explaining why it found no overall change in friction, puts it this way: for an individual, friction "shifts from manual grind to deciding and verifying, possibly in the form of prompt iteration, result vetting, and assessing code that looks remarkably similar to correct code" (p. 40). An organisation that speeds up only coding buys a longer queue in front of review and testing. When Code Gets Cheap, the Bottleneck Moves lays out the evidence.

2. Levels are choices, not targets. No chapter tells you to reach L4. Morris et al. at Google DeepMind write that "the choice of appropriate autonomy level need not be the maximum achievable given the capabilities of the underlying model" (ICML 2024). Feng, McDonald and Zhang argue that "an agent's level of autonomy can be treated as a deliberate design decision" (2025). The right level for a phase is the highest one your verification and your risk ceiling can support, which for many task types today is L2.

3. AI amplifies what you already are. DORA's headline finding for 2025 is that "AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses." Weak tests, large batches and unclear ownership do not get fixed by a faster generator; they get louder. That is why each chapter spends as much time on preconditions as on tools. The AI-native SDLC artifact chain shows the same idea from the side of the documents each phase hands to the next.

How the evidence is graded

Corporate AI claims are often marketing, so every case and every number that carries an argument is graded. A source's tier is the lower of who measured and how they measured.

Two flags can ride alongside a tier. Secondary means the figure was read only in press coverage of a primary source the book could not read. Disputed means the parties' accounts conflict, and the book prints both.

The grade shows up on the page in four ways.

• A "Measured by" line sits directly under every case and every number that carries an argument, naming who measured, the method, the sample or window, and the tier. It looks like this:

• A vendor-reported box holds any figure whose only source is the vendor of the product measured. It says who measured, what "success" means in their metric and what is missing. Main text may say that vendor telemetry agrees on direction; it never rests an argument on the box.
• Dates. Product capabilities, defaults, prices and adoption figures carry "(as of Month Year)". Studies and incidents carry their own dates.
• The book's proposals, such as the permission envelope for each level and the rollback triggers, are labelled as such. They are synthesised from vendor defaults and incident fixes, and no organisation has published outcome-validated versions of them.

What this book is not

Not a tool guide. Products are named as examples of a pattern, with dates, because they change faster than any book. The patterns (a verifier first, a sandbox, a small toolset, review capacity planned in advance) outlast them.

Not a prescription for an end state. There is no L5 in this book, and L4 is always written with its scope, as in "L4 for flaky-test quarantine", never as "the phase runs itself". The serious sources agree: Hassan et al. say general-domain autonomy "does not yet exist", and the Cloud Security Alliance says the control mechanisms for its top level "don't exist yet".

Not legal advice. Regulatory and licensing status changes month to month. It is collected, dated, in Appendix B, Regulatory and Licensing Status (as of October 2026), and the chapters point there instead of repeating it.

A note on sources. Several of the most candid primary sources are vendors measuring their own tools: Google, Meta, Microsoft and Anthropic among them. They are cited where they are the primary source and held to the same rules as everyone else, including the tier, the "Measured by" line and the vendor-reported box. No vendor gets a pass for being candid, and none is excluded for selling something.