An ADLC Adoption Playbook: From Assistants to Agent-Driven Delivery

Most failed adoptions get diagnosed as vendor failures. A team runs a structured pilot on two candidate tools, the results are inconclusive, and the conclusion drawn is that the market has not converged. That conclusion is almost always downstream of a simpler failure that happened earlier and was never measured: there was no layer in which an agent could act deterministically. Every published account of agent-driven delivery begins with that layer. The AWS AI-DLC methodology decomposes work into small, bounded units — "bolts" — executed by a supervised group of agents and humans under a named driver [1]. Anthropic's eval-first playbook assumes CI can run the coding agent non-interactively and that an API key exists with budget for eval runs [2]. Stripe's agent fleet sits on a verification substrate that predates it entirely [3]. Where that layer is missing, adoption questions get answered in the wrong direction: teams compare tools that were never given the chance to be graded.

One caveat before the argument. Several figures below come from 2025 and early 2026, and some vendor benchmarks are republished quarterly with revised methodologies. They are used here as directional evidence about where the effects fall, not as current measurements of your organisation.

The practical consequence is that an adoption playbook is mostly a construction plan for a deterministic layer, and only secondarily a model-selection guide.

The maturity ladder

Most organisations attempt to skip the first stage and start at the third, because the third is where the published throughput numbers live. The ladder exists to make the skipping visible.

Stage	What it means	Readiness signal for the next stage
Assistant	The human drives; the model completes lines, drafts and explanations. The unit of work is the developer's intent.	The team can state what a correct output looks like as an executable check rather than as an opinion. Without that definition the next stage has no gate [2].
Bounded agent	The agent works inside a named scope with an executable definition of done — one dependency upgrade, one classified issue, one refactor [3]. Every run supervised, every output checked.	An agent can open a pull request that CI verifies with no human in the loop. Stripe's substrate caps CI at two iterations per run, after which the branch returns to a human [3].
Agent-driven change	Planning happens at the queue rather than the feature. The planning artefact is a set of bounded units, dispatched to a supervised group of agents and humans [1].	The majority of accepted changes are small, independently verifiable and revertible rather than feature-sized. Bolt-level planning only works once the unit of delivery is smaller than the unit of planning [1].
Agent-driven delivery	The change queue is supplied by agents across triage, implementation and migration, and human review becomes a sampled, budgeted step rather than the default [3][9].	An economic test rather than a capability test: cost per accepted change is flat or falling while throughput rises. Stage four is a different cost structure, and unit cost is the only honest measure of it [11][13].

The driver is the stage that organisations consistently under-resource. In the bolt model a named human role decomposes intent into bounded units, sequences them and stays accountable for the queue [1]. Treating that as a title rather than as allocated time is the most common reason a bolt protocol quietly reverts to feature-level planning: if the driver is a responsibility added on top of an existing full-time role, decomposition is the first step abandoned under load, and the system degrades into an untracked agent swarm.

Two notes on the ladder itself. First, the terminology in circulation is unstable: the open-source methodology most often cited under the acronym ADLC is published as AI-DLC, with five phases and 33 stages [1]. Teams that have read one name while evaluating the other will misjudge the scope of what they are adopting. Second, the transitions are asymmetric in cost. Moving from assistant to bounded agent is mostly a tooling and definition exercise. Moving from bounded agent to agent-driven change is where the fixed process overhead of a bolt-level protocol lands on the organisation, and it is the transition most often abandoned halfway.

Two opposing adoption models

The first model is the bolt model — where a bolt is a planned delivery slice over one or more units, distinct from a unit itself, and its canonical expression is AWS AI-DLC. Under it, the artefact of planning is not a feature but a queue of bounded units, and a named driver dispatches supervised groups of agents and humans against that queue [1]. Nothing in the model is autonomous by design; the supervision is the architecture.

The second model is phase-by-phase augmentation of a process you already run. Anthropic's playbook states explicitly that its steps are modular, and that organisations may prioritise transforming different stages at different times [2]. MentorCruise makes the same case from the other direction: keep the existing process and add AI one phase at a time [8]. That is a practising engineer's report rather than a study — the value is in the formulation, not in the evidence.

The choice follows from two conditions rather than from preference. Take the bolt model when the verification substrate already exists — more than three million tests (Stripe’s own figure, in the Part 2 release of 19 February 2026), isolated pre-warmed environments, roughly 500 centrally served internal tools [3] — and a large share of the work is bounded, meaning configuration adjustments, dependency upgrades and minor refactoring [3]. When either condition fails, take phase-by-phase. Bolt-model adoption without the substrate produces volume without acceptance, and acceptance rate is where that shows up first: across 8.1 million pull requests and more than 4,800 teams, AI-assisted PRs were accepted within 30 days 32.7% of the time versus 84.4% for unassisted ones [5]. Phase-by-phase adoption without a named target phase produces activity without evidence, and a team that cannot name the phase it is transforming cannot tell whether the phase improved.

Organisation size and risk profile decide which of the two you can afford to be wrong about. A large organisation with a mature platform function and a deep test estate amortises the bolt-model investment across enough units to pay it back, and its review capacity can absorb the early acceptance-rate penalty because it reads volume in absolute terms [3][5]. A small organisation, or a large one in a regulated domain where every change carries an audit obligation, cannot. The bolt model's failure mode is an unnoticed flood of rejected work, and a rejected change in a regulated pipeline does not cost a merge cycle — it costs an exception request. There, phase-by-phase augmentation is not the cautious option; it is the only one that keeps the blast radius of a bad adoption decision inside a single phase, where it can be reversed in a sprint.

What to measure before you start

The baseline is the part teams skip, and skipping it makes every later number uninterpretable. The cleanest baseline metric is 30-day PR acceptance rate [5], for three reasons: it is measured on work already flowing, it does not depend on your instrumentation being good, and it is the metric most likely to move first and worst.

Write down four numbers before the first agent run, with a date, in the place you will later read them from. Faros AI, across 22,000 developers and more than 4,000 teams, found throughput rising — tasks up 34% and epics per developer up 66.2% — while the process went the other way: median time in PR review up 441.5%, PRs merged with no review up 31.3%, PR size up 51.3%, and bugs per developer up 54% [6]. Those are the movements to pre-register, because an adoption that raises throughput and review burden together looks like success on a dashboard built only from delivery metrics.

The reason to insist is DORA's J-curve: a temporary productivity dip produced by the learning curve, the verification tax and pipeline adaptation, framed as the tuition cost of transformation [12]. An organisation that measures only the first month concludes the investment failed. Without a pre-adoption number you cannot distinguish a dip from a regression, and you will make the call on the dip.

Assign the read as carefully as the capture. A baseline that is collected but never read by the person who owns the budget is indistinguishable from a baseline that was never taken, and the organisation discovers both at the same moment: when someone asks why throughput rose and nobody can say what it was before.

What to measure during

The in-flight signals are ordered by lead time, and the first three move before throughput does. Median time in PR review is the earliest and most honest of them [6]. PR size is the second: if it rises as the agent share of merges rises, your units of work are too large, whatever the bolt specification says. Share of PRs merged without review is the third, and it is a governance signal rather than a quality signal [6][10].

The fourth is the refinement ratio — the share of an agentic task's cost incurred after the first successful call. Consultancy data puts it at roughly 60% of total cost, with 93% of organisations exceeding their AI budgets [13]. AltexSoft describes the characteristic failure mode this produces: correcting corrections, where each automated fix spawns another fix and the token budget burns down without progress [7]. The wording comes from a vendor's marketing overview of its own projects, so read it as an illustration of the mode rather than a measurement.

Read these in order rather than together. Review time and PR size are leading indicators, and they move while throughput is still rising. Bugs per developer is lagging, and will not move until long after the decision has been made [6]. A team that waits for the lagging indicator to confirm what the leading ones already said has not gained evidence, it has only delayed the conversation.

The trigger to act on is a conjunction. If median review time and PR size both rise while the agent share of merges rises, the team has entered agent-driven change without a stage-two substrate. The response is not to reduce agent usage; it is to stop merging and rebuild the checks, because the review queue is now the constraint and additional agent output only lengthens it [3][6]. If review time holds flat while throughput rises, you are inside the J-curve region and the correct response is to hold course [12].

Track cost per accepted change rather than tokens per task. DORA's finding on tokenmaxxing is that organisations spending the most get only a modest throughput gain at ten times the spend [11]. A per-token or per-task metric can improve while the bill and the acceptance rate both move the wrong way.

Where the economics turn negative

There are four shapes this takes, and each has an early indicator that appears before the bill does.

Failure shape	Early indicator	Correct response
Small change	Fixed process overhead per bolt exceeds the saving on trivial diffs [1][8]	Set a size threshold below which work stays on the human path
Refinement loop	Roughly 60% of task cost sits in review and refinement, and 93% of organisations exceeded their AI budgets (McKinsey survey, n=75) [13]	Cap iterations per bolt and return to a human instead of retrying
Review exhaustion	Reviewers read transcripts instead of diffs, which produces cognitive exhaustion [8]	Instrument review time and make diff-first review the default
Variance, not capacity	Failures trace to the environment rather than to the model [9]	Add backpressure and repair the environment before adding agents

The economics are decided at the level of the bolt, not the model. A protocol with fixed per-unit overhead specification, driver supervision and verification will cost more than it saves on a change a competent developer would have made in minutes, no matter how capable the model behind it is [1][8]. And the failure mode that survives longest is the refinement loop, because it looks like activity: agents are working, changes are being produced, and the cost per accepted unit climbs quietly. Optiver, in a company self-report, argues that backpressure reduces variance rather than adding capacity, and that most agent failures originate in the environment rather than in the model [9].

The stop condition is arithmetic. If cost per accepted change has risen for three consecutive reporting periods while throughput has risen, the dip is not the J-curve and further investment will not fix it. Re-scope to bounded work.

Governance is adoption infrastructure

Governance is usually positioned as a brake on adoption. The survey data suggests it is closer to a prerequisite. In the Stack Overflow Developer Survey 2026, with more than 30,000 participants, only 16% trust AI for important work decisions, while among those who can easily verify the output trust reaches 48% [10]. That is a description of an unmanaged layer forming inside an organisation: agents in use, no trust in their output, no attribution, no ceiling.

Three mechanisms matter, and all three are infrastructure rather than guidance. Usage limits and access scope: 38% of respondents reported that their organisation sets limits and 25% that it restricts who may use AI at all [10]. The natural boundary is visible in the same data — usage concentrates where the work is familiar, with code generation on familiar code at 67% and debugging at 61%, against 20% for deployment, operations and troubleshooting [10]. A permission boundary drawn around the first two is enforceable by reviewers rather than by trust. Source attribution: 78.7% care about being able to tell whether code came from AI or a human [10], which makes attribution a policy requirement with a technical implementation behind it.

Implement these as branch protection rules, identity groups, spend caps and required commit trailers, not as a document. A policy that exists only in a wiki constrains nothing; the same policy expressed as a protected-branch rule and a hard spend ceiling does. Attribution is a trailer and a required field. Governance becomes adoption infrastructure at the moment it stops being prose.

Choosing the first workload

The first workload should be bounded, high-volume and low-consequence. Bounded means the definition of done is executable. High-volume means enough samples accumulate inside one reporting period to support a decision. Low-consequence means failure is revertible without a customer conversation.

Candidate	Why it fits	Watch for
Dependency upgrades	Bounded, revertible, high volume, and one of the categories Stripe reports agents performing best on [3]	Flaky version resolution can produce oversized diffs; cap the diff and hand back
Configuration adjustments	The same shape at smaller size, and the cleanest way to measure cost per accepted change [8]	Fixed process overhead can exceed the saving on trivial changes [1][8]
Issue triage	Cloudflare, in a company self-report, reduced open issues from more than 200 to about 30 using isolated subagents with a written handoff and preview releases the reporter verifies [4]	The reporter must stay inside the verification loop, or triage quality is unobservable
Minor refactoring	Bounded and independently verifiable [3]	Scope creep inside a bolt turns a cheap change into an unreviewable diff

What to avoid as a first workload is anything whose failure is not revertible: a migration against live state, anything customer-facing without a human on the review path, and anything whose correctness is defined by taste. Where more than one candidate qualifies, prefer the one with the shortest feedback loop from agent output to a machine-checked verdict — not the one with the largest apparent saving. It is also worth stating the scale honestly. Stripe's reported volume — more than 1,000 agent PRs per week at first disclosure and more than 1,300 per week as of February 2026, all human-reviewed [3] — is a count of changes, not of features delivered, and it is concentrated on well-defined work [3]. Use it as a volume reference, not a productivity reference.

A ninety-day sequence

Week one — capture the baseline. Four numbers, dated and written down: 30-day PR acceptance rate [5], median time in PR review, PR size, and PRs merged without review [6]. Nothing else starts until this exists.
Weeks two to three — make correctness executable. Define the first workload's definition of done as a check that runs without a human. Confirm CI can run the coding agent non-interactively and that an API key carries budget for eval runs [2]. If either is missing, that is the project's real scope.
Weeks four to six — build the eval suite. Twenty to fifty real tasks drawn from recent work [2]. Wire each production incident to an eval owned by the team that hit it [2]. This is the asset that survives a model or vendor change.
Weeks seven to nine — shadow mode. Agents produce, humans review, nothing merges. You are measuring acceptance and review cost, not delivery.
Weeks ten to twelve — open the merge path. Under existing human review, with the two-iteration CI ceiling enforced [3]. Re-read the four baseline numbers.
The final week — decide. If cost per accepted change is flat or falling while throughput is up, continue and scope the next bounded workload. If it has risen for three consecutive reporting periods, stop and re-scope [11][13].

Adoption programmes usually fail at the second stage, not because the model was wrong but because the deterministic layer that would have made models comparable, gradable and cheap to retry was never funded. Once agents supply a measurable share of accepted changes — enough that the delivery metric itself is contaminated and no longer attributable — the questions stop being about tooling and become about structure: how work is grouped, who owns a queue nobody owns, and where review capacity is drawn from. That is the subject of the next article in this series.