The AI-Native SDLC Playbook

The AI-Native SDLC playbook How to transform your software development lifecycle with AI—stage by stage. ‍ Category Enterprise AI Claude Code Product Claude Enterprise Claude Code Claude Tag Date August 21, 2026 Reading time 5 min Share Copy link https://claude.com/blog/the-ai-native-sdlc-playbook Author(s) Code is no longer the bottleneck Organizations have started using AI to write code at a speed unthinkable one year ago, yet the processes around the code haven't changed at the same pace. Many engineering teams still have the same approval gates, reviews, handoffs, and policies, stalling productivity gains made by using agentic coding solutions like Claude Code. The software development lifecycle (SDLC) is the process that takes software from idea to production. Most organizations run some version of the same six stages, covering planning, design, building, testing, deploying, and maintaining software. Traditionally, each stage is a discrete phase owned by a different role. Product managers write requirements, technical architects turn them into designs, engineers build the designs, QA teams at regulated enterprises verify it, releases teams ship it, and operations monitors what is running. Work moves between the phases through documents, tickets, and sign-offs. The traditional software development lifecycle (SDLC) is process-heavy to ensure accountability and control at each step. However, the traditional SDLC was designed to maximize efficiency in an era where the most time-consuming and expensive stage was writing and implementing code, which is no longer the case. PRDs, estimation rituals, and product security reviews all existed to force alignment during what could be weeks, months, or quarters of development work. The traditional SDLC also features controls that assume every step is performed by humans. The organizations generating the most value have rebuilt their process around what agentic AI can now do, while ensuring that humans stay in the loop. In this guide, we walk through several of our Applied AI team's best practices for integrating Claude internally across each stage of the SDLC to accelerate development and make processes run faster, inspired by working with our customers. When code is no longer the bottleneck and the build phase runs faster than the traditional SDLC allows for, three things become true: The bottleneck moves to the steps to the left and right of the build phase. This is mainly plan, review/test, and deploy, which still run at human speed. The controls stop matching reality and become intractable. Reviewing each line by hand made sense when a person had written it, but it can't keep up once agents write most of the diff. Governance costs increase because exceptions still route through meetings and committees that meet weekly or monthly. Build is no longer the constraint — the human-speed steps around it are. Human-speed stages keep their length while build collapses to hours. Let's use a security bottleneck as an example. Security teams are sized for human output, so when agents multiply code output, either the review queue builds or code ships under-reviewed. A regulated organization can't accept either outcome, so its security and policy checks have to keep pace with the agents. To better realize the productivity gains of and secure agentic AI, the traditional SDLC lifecycle requires the same level of transformation as the implementation phase has undergone. Table of contents Code is no longer the bottleneck Plays Stage 1 — Plan Stage 2 — Design Stage 3 — Build Stage 4 — Test Stage 5 — Deploy Stage 6 — Maintain Closing thoughts What is an AI-native SDLC? The AI-native SDLC is a reimagined process that combines the old control objectives with new enforcement. Instead of a linear flow, the process becomes a loop, and AI is embedded at each point. The AI-native SDLC promotes automated handover and triggering of subsequent plays, helping to address the manual and clunky nature of handoff between the phases of the traditional SDLC. You'll also hear this shift called the agentic SDLC, the AI SDLC, or simply agentic software development — the labels differ, but they describe the same thing. The shifts across the six stages of an AI-native SDLC The table below highlights the ends of the spectrum between traditional SDLC and AI-native SDLC, supported by Claude. Most organizations sit somewhere between the two columns. StageTraditional SDLCAI-native SDLC PlanRequirements gathered by committee, distilled through workshops and sign-offs, written up by handClaude synthesizes pain points straight from the sources and captures them within intent.md which is human readable and machine actionable DesignSpec written by analysts, parsed by designersRequirements and design compressed into one working session with an agent, guided by standards encoded as skills, versioned in git BuildTests and code are handwritten and documentation is written after the main development happensTests and code are generated by AI and institutional knowledge is maintained as versioned machine-readable CLAUDE.md files and skills TestQA gates at stage boundariesContinuous evals woven through implementation DeployHumans review every line of code and governance occurs in review cycles, often inconsistentlyLayers of agentic review with human review reserved for regulated and critical code. Governance is enforced as the AI acts, with hooks as approval gates MaintainHumans watch production for bugsAgents monitor live deployments. Any breached control band is diagnosed and written back into the loop as a new intent.md The thread running through the right-hand column is the committed artifact. Each stage ends by writing one to version control (including intent.md, spec.md, plan.md, the diff and its tests, the PR with its review findings, and the incident record) and the next stage begins by reading it. For the early stages, .md files are the predominant artifact because a product owner and an agent can both read and act on the same file. From Build onward, the artifact is code and its records. The chain of commits is also the audit trail: who asked for what, what the agent produced, and who approved it. Humans remain accountable for every decision that requires judgment. In the agentic SDLC world, the human attention shifts along with the artifacts that must be reviewed. Every stage commits an artifact the next stage can read. Together, the intent, the spec, the plan, the diff and the review findings are the audit trail. Plays The plays are the core of the playbook and are grouped into six non-linear stages (Plan, Design, Build, Test, Deploy, Maintain), which together cover the complete lifecycle. Each play covers: What changes; Getting started; Concrete steps for implementation; Governance considerations; and How you measure whether it worked. The steps are modular and organizations may choose to prioritize transforming different stages at different times based on their unique needs. Each play names its dependencies under "Prerequisites," which the dependency graph further illustrates. A stage ends by committing an artifact with the commit initiating the next stage. An accepted intent.md triggers the requirements and design pass, an approved spec.md triggers plan mode, a merged PR triggers the pipeline, and a breached control band in production writes the next intent.md and so the loop continues. First, you prompt each step by hand with the end state being a loop in which each accepted artifact fires the next gate. Human attention concentrates at the gates, reviewing what the agent flagged rather than starting each stage from scratch. The plays are listed with stage; the arrows give the order to adopt them in. The two are not the same. Start with any clay play — nothing points into it, so it needs nothing first. For any other play, the arrows pointing into it are the plays to adopt before it. 01 Plan Ideas stop waiting for someone to write them up. Intent is captured once, in the originator's own words, as a version-controlled artifact the next stage can act on. Capture as intent.md The intent.md, which kicks off the software development process can enter through different routes. A person has an idea, a ticket is filed, or an incident is surfaced via an alert (see Stage 6: Maintenance). When a person has an idea, they brainstorm with Claude and produce a markdown proto-spec. In the traditional SDLC, the same person must then convince a member of the product team to write the idea up with them or on their behalf. The proto-spec generated by Claude is human readable, version-controlled, and immediately consumable by the next stage. The proto-spec is saved as an intent.md. Regardless of whether the intent originates from an event trigger or an agent, the same steps apply: the product owner reviews and corrects the agent-written intent.md before it is committed. TraditionalAn idea passes through backlog entries, user stories, story points, and refinement meetings before anyone can act on it. Ownership transfers at each handoff, so what reaches engineering is several steps removed from what the originator meant. AI-nativeThe originator brainstorms with Claude and writes the result down as intent.md, a proto-spec in the originator's own terms. The artifact contains what is wanted, why, and under which constraints. Repeat processes are encoded via skills. Getting started Prerequisites None. Infrastructure Claude access for people who are not engineers (claude.ai or Cowork); an agreed intent.md template; a shared, version-controlled home for intent that the product owner watches. For a single product the simplest home is an intent/ folder in the product repo. This setup keeps the artifact chain next to the code derived from it. A dedicated intent repo is only worth the overhead when intent spans many repositories, and in a monorepo it is a directory. The Stage 3: Build sidebar covers how this home relates to a Jira or requirements tool that already holds the record. Setting this up is a one-time task for the platform or engineering team. A technical team member needs to stand up the intent home and decide who can write to it, since many contributors will come from across the organization. Once the repository exists, contributors without git experience don't need to use git directly. Instead a connector to the version-control system (e.g. GitHub) lets Claude commit markdown files on their behalf from claude.ai or Cowork. How to execute it The originator describes the problem to Claude in their own words. The originator may describe what they cannot do today, who is affected by the idea, what better looks like, or what is out of scope. No formal language is required. Brainstorm until the idea is concrete. Claude asks the questions an analyst would ask: scope, users, constraints, and what success looks like. Ask Claude to write the result as intent.md using the organization's template, which can be encoded as a skill set up by a technical team member and signed off by a lead. This can cover the problem, proposed outcome, affected users and systems, constraints, and open questions. The originator corrects anything Claude misunderstood. Commit intent.md to the shared home. Author and timestamp join the record, and the product owner picks the idea up from there. # Intent: claims status self-service Author: J. Ortiz (claims operations). Status: draft. ## Problem Customers phone the contact center to ask where their claim is. Handlers spend roughly a third of call time on status-only queries. ## Proposed outcome Customers see claim status, next step and expected date in the portal. ## Affected users and systems Claims handlers, portal team, claims-core API. ## Constraints No new PII in the portal session. Existing authentication only. ## Open questions Do third-part [truncated for AI cost control]