Long-form guide from **Anthropic** by **Louis Claxton** (Applied AI team), published on **August 21, 2026** on the claude.com blog: a stated **40-minute** read, roughly **64,000 characters**, presented as a collection of *plays* drawn from the team's work with its clients. (A) The diagnosis: with code no longer the bottleneck, it shifts to the stages on either side of the build (plan, review/test, deploy), line-by-line controls stop holding once the agent writes most of the diff, and governance cost rises as exceptions still route through periodic committees. (B) The response: six stages (Plan, Design, Build, Test, Deploy, Maintain) organized as a **loop** rather than a chain, each ending with a **committed artifact** that the next stage reads — `intent.md`, `spec.md`, `plan.md`, the diff and its tests, the PR and its findings, the incident record. (1) Institutional knowledge becomes versioned files: `CLAUDE.md`, skills, `REVIEW.md`, `bands.yaml`. (2) Governance splits into two layers, with the skill positioned as an advisory control and the hook as the deterministic layer behind it. Separation of duties is set as an invariant — the agent that writes the code cannot approve it — and the piece closes on *"The loop keeps running. Human judgement stays above it."* The corpus already holds [[clinton-anthropic-secure-ai-native-sdlc-2026-07-21]] on the security side of the same cycle, and [[hingel-augment-how-ai-changes-sdlc-six-stages-2026-06-08]] on the same six-stage breakdown as seen by a competitor.
#AI-native SDLC#software development lifecycle#plays
Louis Claxton (Anthropic, équipe Applied AI) · sur le blog claude.com ; contributions créditées à Jim Blackhurst · Will Steuk et Jamal Arif.
SFEIR analysis (consulting-firm voice, "an engineer's reading") articulating two frameworks too often conflated: the **SDLC** (Software Development Life Cycle — *building the software correctly and reliably*) and the **PDLC** (Product Development Life Cycle — *building the right product and succeeding in the market*). Central thesis: the two cycles are not competitors but **nested** — the SDLC is the subset of the PDLC **housed under its development phase**; when a product team reaches the "build" stage, a full SDLC cycle (design → build → test → review → deployment) runs inside it. The SDLC is standardized (**ISO/IEC/IEEE 12207**, 2017 and 2026 editions), with its lineage of models (Waterfall 1970, V-model, iterative/spiral, **Agile 2001**, **DevOps/DevSecOps 2009+**) and its **DORA** metrics (throughput, stability, MTTR, change failure rate). The PDLC, being the umbrella cycle, runs from **ideation/discovery** to **market withdrawal** (not to be confused with the marketing **PLC** of Theodore Levitt, 1965, which describes a *commercial curve*, not *organized work*: "the PLC observes a curve; the PDLC organizes work"). **Tipping point**: the SDLC natively addresses **only one risk in four** — via **Marty Cagan's "Four Big Risks"** framework (Value → PM, Usability → Designer, Feasibility → Lead Engineer, Business viability → PM) — an organization excellent at SDLC but blind to PDLC produces "software nobody wants" — John Cutler's **"feature factory"** (success measured by output, not outcome). **Why AI changes everything**: generative AI **compresses the SDLC** (Google/JetBrains data, May 2026: **~85% of developers** regularly use coding agents, **~41% of new code** is AI-generated; implementation goes from weeks to hours), so the **bottleneck shifts upstream** — deciding *what* to build (Marty Cagan, April 2026: "when the cost of delivery collapses, the bottleneck shifts to discovery"). Consequences: DORA 2025 (~5,000 professionals, 90% AI adoption) shows a **positive correlation with throughput but a negative one with stability** (more unvalidated features means instability and rework); Andrew Ng (AI Startup School, July 2025) reports teams **reversing the "1 PM for 4 engineers" ratio to "2 PMs for 1 engineer"**; and with **spec-driven development**, the PDLC/SDLC boundary becomes **porous** (the product spec becomes directly executable by agents). **What a CIO should take away**: an augmented SDLC becomes a **market standard, not a differentiator** — the junction with the product must be instrumented, **executable specifications** demanded as input, technical metrics cross-referenced with outcome metrics, and the role of "feature supplier" **refused**. For a CPO: the shift of the bottleneck toward discovery is both a **promotion** (product judgment becomes scarce again) and a **notice to act** (industrialize discovery to reach parity with the SDLC). SFEIR's in-house framework ("Designing and building in the agentic era" — **11-phase cycle** + **Software Factory 10x**) is positioned as the answer on the engineering side, with the **articulation of the two cycles** as the next lever. Conclusion: "as code becomes a commodity, margin shifts toward product judgment and governance."
An arXiv paper (cs.SE) by Martin Monperrus arguing a radical thesis for the SDLC: coding agents have crossed a threshold of capability such that **human code review is no longer a necessary component** of a quality pipeline. Two claims: (1) autonomous LLM-based systems achieve all the goals of review (defect detection, quality, compliance) at lower cost and higher throughput; (2) the hybrid model "the agent writes, the human reviews" is untenable — it does not ensure real quality and does not scale with AI velocity, creating a "false sense of security". Monperrus contrasts inspection de Fagan (1976) with a **multi-agent adversarial verification pipeline** (generator agent + independent reviewer agents + tests/formal methods + vote-based consensus). The human refocuses on the spec, architectural trade-offs, approval of critical domains, and edge cases. Recommendations: pilot first on low-risk components, measure agent vs. human, make rejection decisions explicit.
Atlassian data study (Inside Atlassian) measuring the actual return of an **AI-native SDLC** powered by **Rovo Dev**. Across 3,400 repositories from 2,500 customers (a quasi-experiment with propensity-score matching), adopting repositories merge **19% more PRs per month**; up to **37-51%** on low/medium-activity repositories and **59-87%** when **3 to 5 members** of the team adopt the tool. On the efficiency side, developers save **2-3 h/week** (≈10% of the 24 hours devoted to coding and review), i.e. 20-30 hours/week reinvested for a team of 10. The thesis: resolve Solow's (1987) "productivity paradox" by shifting from **usage metrics** (tokens) to **impact metrics** (throughput, time saved, failure rate, satisfaction). Recommendation: start with a **team** (not an individual) and measure 2-3 months later.