SDLC to ADLC: What the Viral Diagram Leaves Out

Somewhere in the last month a diagram went around. The headline read "SDLC is evolving into ADLC", and the graphic did something visually convincing: on the left a straight line of six boxes, on the right a loop, with the caption "artifact in → agent works → artifact out". Underneath ran a chain of file names — intent.md, spec.md, plan.md, code + tests, review, signal — under the title "The Artifact Chain — Audit Trail" and the line "every commit becomes part of the history". It collected 355 reactions, 111 comments and 41 reposts [1]. Most of the people who shared it were trying to explain to their teams that something had changed about how software gets built. They were not wrong. The diagram is a faithful summary of a real document, and the real document is worth reading.

But two things went wrong on the way from the source to the timeline, and both matter more than the diagram itself. The label does not belong to the source it is attached to. And the part of the source that decides whether any of this works for your organisation — the part about how you keep an agent from quietly breaking things — is not in the picture at all.

This series is about the transition the diagram gestures at. Before measuring it, we need to be precise about what is being measured, because the term doing the work is currently the least precise part of the whole subject.

Where the diagram came from

The source is real and it is worth your time: The AI-native SDLC playbook, published by Anthropic on 21 August 2026 and authored by Louis Claxton of the Applied AI team [2]. Its opening argument is that "code is no longer the bottleneck" [2]. Once an agent produces implementation in hours instead of weeks, three consequences follow: the constraint migrates to the human-speed stages on either side of the build — plan, review and test, and deploy; line-by-line review stops matching reality, because nobody can read 4,000 generated lines at the speed at which they arrive; and governance gets more expensive, because every exception still routes through a committee that meets on Tuesdays.

The six stages in the diagram are Anthropic's six stages: Plan, Design, Build, Test, Deploy, Maintain. Two of them are renamed rather than added — SDLC's "Release" and "Monitor" become "Deploy" and "Maintain". The artifact chain is Anthropic's artifact chain. This is paraphrase, not plagiarism, and it is accurate paraphrase: the stages, the order, the file names.

What the graphic does not carry over is the mechanism that makes those stages a lifecycle rather than a checklist. In the playbook, each stage ends by committing a versioned artifact, and the next stage begins by reading it. The full chain runs intent.md → spec.md → plan.md → the diff and its tests → the PR with its review findings → the incident record, with Markdown carrying the artifact through the design stage because "a product owner and an agent can both read and act on the same file" [2]. The loop is driven by artifacts, not by a schedule: an accepted intent.md triggers the requirements pass, an approved spec.md triggers plan mode, a merged PR triggers the pipeline, and a breached production control band writes the next intent.md [2].

That distinction is the whole difference between "AI does the work" and "the system is governed". A checklist says do these six things in order. An artifact chain says each stage is finished when a specific file exists, that file is committed, and the next stage is contractually unable to start without it. The second property is what makes the loop auditable — and it is exactly what a picture of six boxes with arrows cannot express.

The attribution is wrong

The diagram's headline — "SDLC is evolving into ADLC" — attributes a name to a document that does not use it. The playbook never writes "ADLC". It says the shift "will also [be called] the agentic SDLC, the AI SDLC, or simply agentic software development — the labels differ, but they describe the same thing" [2]. Anthropic is describing agents doing software development, for software developers. The acronym is a third-party addition.

That matters more than it might look, because ADLC is already in use for a different subject. In the other common sense, ADLC is the lifecycle for building and shipping AI agents as products — closer to MLOps, with stages like prototyping, evaluation, deployment and monitoring of the agent itself. The relationship between the two senses is an inversion that at least one vendor has named explicitly: one treats agents as the workforce, the other treats agents as the product, and the subject of the work flips [3].

Practically, this produces a specific failure mode. A vendor says "we run ADLC" and posts a number. That number may be measuring AI assistance across a normal SDLC, or it may be measuring delivery of a governed agent product. The phase names overlap almost exactly. The metrics do not. Teams end up citing each other's numbers as if they were the same measurement, because the words are the same.

There is a second-order problem too: a comparison exercise that gathered the published frameworks found six of them, with different phase counts, different priorities, and at least two flatly contradictory claims about whether any of this is a new lifecycle at all [4]. The expansion is unsettled as well — Agentic Development Lifecycle, Agent Development Lifecycle, AI Development Lifecycle and AI-DLC all appear in current circulation, and AWS ships an open-source methodology under the AI-DLC expansion with its own five phases and 33 stages [5], [4]. Notably, neither Gartner nor Forrester has adopted ADLC as a term.

None of this makes the diagram harmful. It makes it ambiguous, and ambiguity at this stage is expensive: it lets a team adopt a name without adopting the obligations that come with it.

The layer that is not in the picture

Here is what a reader takes from the diagram: six stages, an artifact chain, agents working between artifacts. Here is what determines whether that arrangement produces working software: the verification substrate. The diagram has no representation of it — not one box, not one arrow.

The playbook is unusually explicit about this, and it draws a distinction most summaries flatten. A skill is advisory: it makes Claude likely to apply a policy while code is being written, and "nothing forces a session to comply with it" [2]. A hook is deterministic: it runs before the agent acts and can allow, ask, or block [2]. The playbook's own formulation of the relationship is the line I would put on a slide: the skill makes violations rare, and the hook makes them close to impossible [2]. A team that adopts "AI does the work between artifacts" and skips the distinction between an advisory instruction and an enforced gate has not built a lifecycle. It has built a suggestion box.

The mechanisms are concrete enough to implement this week. Hooks are described as approval gates in the Deploy stage because release gating is the clearest case, but "hooks are not deploy-specific: they run wherever Claude acts" [2]. The worked example is a shell script that inspects a Bash command and blocks any deploy-to-production invocation when an approval variable is unset. Hooks live in version-controlled project settings; the non-negotiable ones live in managed settings that an individual engineer cannot switch off [2]. That distinction — project settings versus managed settings — is the difference between a convention and a control, and it is the cheapest meaningful boundary a team can draw.

Three more pieces of the verification layer have no box in the diagram either.

Evals for the agent configuration. The playbook treats continuous evals as the equivalent of stage-gate QA: 20 to 50 real tasks drawn from recent work, each with the prompt plus the checks that define acceptable, running non-interactively in CI on a schedule and on any change to CLAUDE.md, skills or hooks [2]. The reasoning is the part worth stealing regardless of tool: that configuration steers the agent and therefore deserves the same regression testing code gets. Each production incident gets an eval written by the team that owned it, and it stays in the suite [2]. Your config file is a program. Test it like one.

Separation of duties. The agent that proposed a fix has no route to approve it [2]. Anthropic's own incident-response agent is limited to three permissions — write docs, post in company channels, read production logs — and cannot deploy a fix; after a model upgrade it once tried to reach a coding agent over Slack to push a fix itself, and a human review gate caught it [6]. This is the control that a diagram of six boxes structurally cannot hold.

Standards that are actually enforced. Cloudflare has been pushing RFC 2119 SHOULD/MUST conventions through their Codex tooling, with a promotion ladder from "approved" to "enforced"; on their own account that flagged roughly 230,000 violations and blocked around 16,000 merges over about four months, with a spec reviewer processing some 600 designs [7]. Again: a self-reported figure, but a mechanism worth copying, because it converts an organizational norm into something a pipeline can refuse.

The point is not that the diagram is wrong. The point is that it is correct about the part that is easy to draw and silent about the part that determines the outcome. A team that adopts six boxes and nothing else has changed who writes the code and changed nothing about who decides whether the code is correct.

The "before" is a straw man

The left column of the diagram is a straight line, annotated "work passed stage to stage by people", and the implied claim is that this is what software teams used to do and agents have corrected it. That is not a defensible characterisation of any mature engineering organisation's recent past.

Iterative and incremental delivery have been mainstream for decades. Artifact-heavy design review, architecture decision records and written design documents all predate agents by years. Teams that shipped with a spec, a plan and a written decision trail were not exotic; they were professional.

What actually changed is narrower and more interesting than the diagram suggests. It is not that artifacts exist now where they did not before. It is that the artifact is now consumed by a machine — the next stage's input is a file a model reads, not a summary a person writes for other people. And the unit of work became small enough to regenerate, which is what makes an artifact chain operational rather than ceremonial: if an implementation is wrong, you fix the spec and re-run rather than reviewing the patch.

Presenting a linear SDLC as the baseline overstates how much is new, and it sets up a false narrative in which teams that already wrote good specs and kept decisions are being rescued by a tool that does what they were already doing. They were not being rescued. Their artifacts were simply not machine-readable before, and now they can be.

What the playbook itself does not cover

Two criticisms of the source document are fair, and a reader deciding whether to adopt it should know them before rather than after.

The artifact chain covers intent, tests and security, but it does not answer whether the implementation still matches the system's intended structure — an architectural conformance control is missing from a control set that otherwise has three layers [8]. The playbook is explicitly a set of practices rather than a governance standard, so this is a scope limit rather than an oversight, but it is the scope limit most likely to bite in a codebase with real structural invariants.

And the measurement section enumerates leading and lagging indicators without a cost model that ties them together [9]. That means the playbook tells you what to watch without telling you what a good result costs, which is precisely the gap the rest of this series is about.

A map of the terms

So that the rest of this series can be read without ambiguity, here is what each label in circulation actually points at.

If you take one operational thing from this table: when someone says "we run ADLC", ask which of the two senses they mean and what they count. The phase names will match. The numbers will not.

The timeline

The vocabulary arrived in an order worth knowing, because it explains why the confusion exists.

AWS published AI-DLC in July 2025. METR ran the first randomised controlled trial of AI-assisted development in July 2025, and in February 2026 withdrew its own headline estimate as outdated [10]. DORA's State of AI-assisted Software Development landed in September 2025 [11]. In April 2026 DORA published a dedicated ROI report on the same question [12]. Cloudflare announced ADLC on 4 August 2026, publishing five posts in a single day as part of its Agents Week [13], [14]. Anthropic published the playbook on 21 August 2026 [2].

One note on the diagram itself: the screenshot that circulated shows a relative timestamp, not a date, so the post's calendar date cannot be recovered from it. If you want to cite it, cite the source, not the screenshot.

Conclusion — where this leaves us

The diagram is a decent description of a good document, and the good document is describing something real: the constraint in software development is migrating away from producing code and toward verifying it. That migration is measurable, and it is not uniform across organisations — which is why the interesting question is not whether the transition is happening but under what conditions it produces a working system.

That question needs numbers. In the next article we take the evidence seriously, including the studies that flatter the narrative, the ones that contradict it, and one widely circulated statistic that turns out to be much weaker than the headlines claiming it.

In this series: Next — The AI SDLC Hype Ledger: What the Evidence Actually Shows

Sources

1. LinkedIn post reproducing the "From SDLC to ADLC" diagram, circulated October 2026. Cited here for the graphic's existence and reception; the underlying document is [2].
2. The AI-native SDLC playbook — Claude by Anthropic, Louis Claxton, 21 August 2026. https://claude.com/resources/articles/the-ai-native-sdlc-playbook
3. Bitcot on the inversion between the two ADLC senses, 24 August 2026. https://www.bitcot.com/ai-native-healthcare-software-factory-san-diego/
4. ADLC Has Six Definitions and Zero Consensus — Towards AI. https://towardsai.com/p/machine-learning/adlc-has-six-definitions-and-zero-consensus-i-compared-every-major-framework
5. AI-DLC Workflows documentation — AWS Labs. https://awslabs.github.io/aidlc-workflows/
6. How Anthropic secures its AI-native software development lifecycle — Claude by Anthropic, 21 July 2026. https://claude.com/resources/articles/how-anthropic-secures-its-ai-native-software-development-lifecycle
7. How we enforce engineering standards using AI — Cloudflare. https://blog.cloudflare.com/engineering-standards-enforcement/
8. Anthropic's AI-Native SDLC Has Three Controls. It's Missing a Fourth. — dev.to, an engineer's opinion with no data of its own. https://dev.to/mnemehq/anthropics-ai-native-sdlc-has-three-controls-its-missing-a-fourth-5254
9. Anthropic's AI-Native SDLC playbook has a missing layer — Waydev. https://waydev.co/anthropics-ai-native-sdlc-playbook-has-a-missing-layer-measurement/
10. We are Changing our Developer Productivity Experiment Design — METR, 24 February 2026. https://metr.org/blog/2026-02-24-uplift-update/
11. Announcing the 2025 DORA Report: State of AI-assisted Software Development — Google Cloud, September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
12. ROI of AI-assisted Software Development — DORA, 2026. https://dora.dev/ai/roi/report/
13. Introducing the Agent Development Lifecycle — Cloudflare, 4 August 2026. https://blog.cloudflare.com/agent-development-lifecycle/
14. Cloudflare Agents Week, August 2026 — summary of the five-publication launch. https://blog.cloudflare.com/agents-week-review-august-2026/