Assess Your Starting Point

What not to count

The common starting questions are how many engineers have a licence, which tools are installed, and whether people feel faster. None of them tells you a level, and each one errs upward.

Usage no longer separates teams. In DORA's 2025 survey of nearly 5,000 respondents, 90% used AI at work, and over 80% said it had enhanced their productivity. When nearly everyone answers yes, "do you use AI?" can't tell a team at L1 from a team at L3.

Licences are not usage either. Three randomised field experiments at Microsoft, Accenture and a Fortune 100 firm, covering 4,867 developers, gave a random subset of them access to an in-IDE code-completion assistant. Adoption was "significantly below 100% in all three experiments, with around 30-40% of the engineers not even trying the product" (Cui et al.). A seat count measures procurement, not practice.

Self-report is not evidence. The maturity model's Rule 7 sets out why: developers who were measurably slower with AI believed they had been faster, and the share of sessions run on full auto-approve rises as people gain experience. A team's sense of its own level rises with comfort. An assessment built on a survey of how people feel records that comfort, not the level.

A whole-organisation score hides the variation. Willingness to use AI differs sharply by phase. In the Stack Overflow 2025 developer survey, 28.9% of those who answered did not plan to use AI for writing code. For committing and reviewing code the figure was 58.7%, for project planning 69.2%, and for deployment and monitoring 75.8%. Capability is uneven across tasks too, which is the wiki's jagged frontier. So the unit of assessment is the phase and the named task type within it, never the organisation.

The four readings

For each phase, and each recurring task type in it, take four readings over a trailing window of 30 or 90 days. Each reading points to something a sceptic can open and check. The grid is the book's proposal, assembled from the maturity model's rules. No published study validates this procedure against outcomes.

Combine the readings with two rules from the maturity model. First, the level is the higher of the review reading and the credentials reading. An agent whose token can deploy is at L4 for whatever that token reaches, whatever the team calls it. Second, a claimed L3 or L4 with no verifier beyond the agent's reach is recorded as L2. The ceiling doesn't change the level. It marks how far the level may go, and flags rows that are already over it.

The credentials reading is where scores most often rise, and it is the one teams know least about. Step 1 of the migration steps in Security, Permissions & Blast Radius gives the inventory procedure. The wiki's page on agent inventory explains why a self-declared list misses the agents you most need to find: an inventory that works is derived from the credential, the route and the budget line each agent needs.

Record the results in the self-assessment template, one row per phase and task type, with the evidence cited in the row. A row that cites opinion instead of an artefact is scored at the highest level its artefacts support.

What to look for, phase by phase

Each Part II chapter defines its own ladder and the entry criterion for the next rung. Use its grid row for the criteria; the line below is the reading that most often changes a score.

• Requirements and design (Requirements, Specs & Design; requirements grid, design grid). Is there a named approval for every spec of a delegated task type, and are its acceptance criteria frozen so the implementing agent can't edit them? The public record has no L3 outcome evidence for either half of this phase.
• Coding (Coding; grid). Are agent PRs attributed and tracked by task type, and are bypass and auto-approve modes disabled through managed settings? A developer machine in a skip-permissions mode is an unrecorded grant.
• Review (Code Review; grid). Can any bot approve, and is routing enforced in the merge system where no agent can edit it? Record wait time, active time and no-review merges now; they are the baseline for every later climb.
• Testing (Testing & Verification; grid). For each testing task type, who can edit the oracle? Count agent diffs that delete, skip or weaken tests. A repository with no tests has no verifier to climb on.
• CI/CD (CI/CD & Release; grid). Which pipeline jobs run an agent, which secrets they hold, and whether auto-merge is forced off when an agent contributed. A CI agent that reads issue text while holding a publish token is a red row.
• Operations (Operations & Incidents; grid). Does ops tooling read or act? List its credentials, including tokens in files, and check whether any mitigation it can take lacks an undo path.
• Maintenance (Maintenance & Migrations; grid). Which recurring change classes already have a build and test suite that runs outside the agent's reach? Score deterministic codemods and update bots as L0 for AI, however autonomous they are.
• Security, across all phases (Security, Permissions & Blast Radius). Can any agent write its own permission, MCP, rules or instruction files? Can any reach production? Each yes is scored before anything else in the grid.

Find the constraint

The four readings tell you where each phase stands. They don't tell you where to climb, because a climb pays off only if it relieves the phase where work waits. When Code Gets Cheap, the Bottleneck Moves quotes DORA's value-stream example: a team that discovers through mapping that review is the bottleneck should point AI at review, "rather than using AI to simply generate more code that will only exacerbate the bottleneck". DORA's follow-up guidance (December 2025) calls AI adoption "an organizational transformation" and recommends value stream mapping so that gains "aren't just creating local optimizations that pile up work downstream".

Run the map with numbers you already have, not a workshop's impressions. For each step from ticket to production, record how long work waits and how long it is actively worked, separately, over the same trailing window as the readings. The phase where waiting dominates is the constraint. The evidence in that chapter points first at review, then at testing and release, but your own map decides. Then check Rule 6, a heuristic and the book's proposal: if Coding scores two or more levels above the lower of Review and Testing, expect the map to show a queue in front of them, and raise those phases first.

Knowing the constraint changes the pilot in one of two ways. A candidate that relieves the constraint, such as precision-tuned review at L2 where review is the queue, can go ahead on its own merits. A candidate that feeds the constraint, such as an agent that opens more PRs into that same review queue, can still go ahead, but its output must be capped at what the constraint can absorb. Google's JUnit migration team did exactly that: it limited the changelists sent each week so as not to overwhelm reviewers (see the phase-level evidence in the same chapter).

Read the team behind the scores

The same scores mean different things on different teams, because, in DORA's words, "AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses" (DORA 2025 report). The report gives a way to see which strengths and weaknesses a team brings. A cluster analysis over eight factors (team and product performance, delivery throughput and instability, individual effectiveness, valuable work, friction and burnout) produced seven team archetypes (pp. 15–18):

• Foundational challenges, 10%: indicators "consistently low", with high burnout, friction and instability.
• The legacy bottleneck, 11%: "in a constant state of reaction, where unstable systems dictate their work and undermine their morale."
• Constrained by process, 17%: "Despite working on stable systems, their effort is consumed by inefficient processes, leading to high burnout and low impact."
• High impact, low cadence, 7%: strong product performance with "low software delivery throughput and high instability."
• Stable and methodical, 15%: "delivering high-quality, valuable work at a deliberate and sustainable pace."
• Pragmatic performers, 20%: "impressive speed and stability", short of peak engagement.
• Harmonious high-achiever, 20%: "a stable, low-friction environment" that delivers "without burnout."

Use the archetypes as a diagnostic, not a ladder. They describe how a team works, not how much authority its AI holds. Two of them change what the assessment should recommend. On a legacy bottleneck team, unstable systems set the agenda, and an amplifier amplifies the instability; making the systems stable and rollback reliable comes before any climb. On a team constrained by process, the systems are stable but the process isn't. Generating more work into an inefficient process feeds the treadmill, so the value-stream map in the previous section is the first deliverable.

Two further checks sharpen the reading. First, the codebase. The Stanford productivity group's "orientative" matrix puts the gain for brownfield, high-complexity work at +0–10%, the lowest cell in that matrix, though a title on the same slide gives 5–10% (T3; Economics, Risk and Measurement gives the full range and its caveats). A team working mostly in such code should expect less from any climb. Second, the enablers. DORA's seven AI capabilities, listed in the maturity model, are the preconditions to check beside the scores. A team with large batches, weak version-control practice or no stated AI policy should fix those before raising a level. Two of the seven carry named costs, so record them as trade-offs, not boxes to tick.

From scores to a starting point

The assessment produces one page per team, not a maturity number. The order below is the book's proposal.

1. Fix the red rows first. Every row where credentials reach further than review is a level nobody chose. Remove the credential or raise the review before you discuss any climb. The fix may lower a phase's level; record that as a correction, not a setback.
2. Mark the rows over their ceiling. Bring them down to it, or write down who accepted the risk and why.
3. Find the eligible candidates. A task type is eligible to climb if it already has a verifier outside the agent's reach, its actions can be undone, and the next level is within its ceiling. Most rows fail at least one test, and the failures become the work list.
4. Rank the candidates against the constraint. Prefer one that relieves it. If the best candidate feeds it, size the cap before the pilot starts.
5. Pick one. One phase, one task type, one team. Recurring maintenance work usually comes out on top, because the compiler and the test suite are a verifier that already exists. That is why Maintenance & Migrations is the book's recommended first rung.

The sheet below is illustrative and names no organisation. It shows the shape of the output, including the case where the best candidate feeds the constraint.

ASSESSMENT SUMMARY (illustrative)                 window: trailing 90 days

PHASE        TASK TYPE            REVIEW  VERIFIER (AI can edit?)   CREDENTIALS     CEILING  LEVEL
-----------  -------------------  ------  ------------------------  --------------  -------  -----
Coding       feature work         L2      tests (yes, same branch)  dev token       L3       L2
Review       PR comments          L2      none                      comment only    L3       L2
Testing      unit tests           L1      none                      IDE only        L3       L1
CI/CD        release pipeline     L1      n/a                       prod deploy !!  L2       L4 !!
Maintenance  dependency upgrades  L2      build + tests in CI (no)  own branch      L3       L2

CONSTRAINT  review: wait time far exceeds active time
FIX FIRST   CI/CD agent token can deploy to prod -> remove; rescore at L1
HOLD        Coding stays at L2 until Testing rises (Rule 6)
CANDIDATE   Maintenance / dependency upgrades: verifier out of reach, reversible,
            within ceiling; feeds review -> cap open agent PRs per team
ALSO        Review at L2, precision-tuned, to relieve the constraint

The candidate row is the input to The 90-Day Pilot. The baselines recorded here (review wait, reverts, escaped defects for the human-made version of the same task) become its comparison. They also become the reference for the rollback triggers in Measuring Success and When to Roll Back. Run the assessment again every quarter. Scores drift upward with comfort, so ask for the evidence again each time. If a governance group owns the re-scoring, the wiki's governance in practice page shows how to keep it proportionate to risk rather than uniform. Templates carries a blank copy of the self-assessment.