Every stage commits
an artifact the next one reads

Organizations can now produce code at a speed that would have been difficult to imagine a year ago, while the surrounding approval gates, reviews, handoffs and policies have changed far less. Those unchanged processes can stall the gains from agentic coding, where an AI agent reads the codebase, edits files and runs commands to complete a coding task instead of merely suggesting the next few lines to a person.

The software development lifecycle, or SDLC, is the process that takes software from an idea into production and keeps it running. Most organizations operate some version of six stages: plan, design, build, test, deploy and maintain. In a traditional flow, each is a discrete phase owned by a different role. Product managers write requirements, often in a PRD, or product requirements document. Technical architects turn those requirements into designs. Engineers build the software. QA teams, particularly in regulated enterprises, verify it. Release teams ship it, and operations teams monitor it.

Work moves between these roles through documents, tickets and sign-offs. The weight of the process is deliberate: each stage establishes accountability and control before work advances. It also rests on two assumptions. The first is that writing and implementing code is the most time-consuming and expensive part of delivery. PRDs, estimation rituals and product security reviews therefore force alignment before teams commit weeks, months or quarters to development. The second is that humans perform every step.

Once build runs faster than that process permits, the constraints move outward. Plan, review and test, and deploy still proceed at human speed. Existing controls become difficult to operate at the new volume. Reviewing every line manually was feasible when a person wrote it, but it cannot keep pace once agents produce most of the diff, meaning the difference between the code before and after a change. Governance also becomes more expensive because exceptions continue to pass through meetings and committees that convene weekly or monthly.

Build is no longer the constraint, the human-speed steps around it are. Human-speed stages retain their former length while build contracts to hours. Security makes the mismatch concrete. Security teams are staffed for human code output. If agents multiply that output, either the review queue grows or code ships without sufficient review. A regulated organization can accept neither, so its security and policy checks must operate at the agents' pace.

The AI-native SDLC retains the control objectives of the older process but changes how they are enforced. AI is embedded at each point, and the process promotes automated handover and the triggering of subsequent plays, which addresses the manual and clunky handoffs of a linear flow. The result is a loop rather than a one-way sequence.

Each stage writes its result to version control, and the next begins by reading it. The chain starts with intent.md, followed by spec.md and plan.md. It then moves through the diff and its tests, the pull request and its review findings, and finally the incident record. In the early stages, markdown files are the predominant artifact because a product owner and an agent can both read and act on the same file. The product owner is the person accountable for the product's requirements and for deciding whether work proceeds. From Build onward, the artifacts become code and the records attached to it.

Those artifacts also provide the trigger relationships that turn a linear process into a loop. At first, people prompt each step manually. The intended end state is a loop in which acceptance of one artifact activates the next gate, with human attention concentrated at those gates, where people review the issues the agent has flagged rather than reconstructing each stage from the beginning.

Existing processes probably already track many of these artifacts, although not as markdown files. Work may live in Jira, requirements may sit in a tool with regulatory traceability, designs may be stored in Figma, and change approvals may pass through a change board. These systems are difficult to displace because auditors and regulators already accept them, and other teams depend on them. An AI-native SDLC therefore has to fit around the systems already in place. For every artifact, one system should be named as the source of truth, while every other system stores either a copy or a link to the original. That choice can differ from one artifact to another.

Every play follows the same 5-item structure: what changes; getting started; concrete steps for implementation; governance considerations; and how to measure whether it worked. These measurements define leading and lagging indicators rather than reporting achieved results. The plays are modular, so an organization can transform different stages at different times, and each play identifies the work it depends on under Prerequisites.

In the dependency graph, there are 12 plays across 5 tiers. The first tier contains 5 clay-colored plays with no arrows pointing into them. "Clay" is the colour name used for the orange boxes in the figure, not a category of play. Because none has a prerequisite in the graph, any one can serve as a starting point. For every other play, the incoming arrows identify the plays that should be adopted first.

Adoption can therefore begin with a play in Build or Test rather than working through Plan, Design and Build in order. Wherever it starts, the mechanism remains the committed artifact: a stage ends by committing its output, and that commit initiates the next stage.

A person with an idea brainstorms with Claude and produces a markdown proto-spec, a half-formed requirements document that records the idea before it becomes a formal specification. Saved as intent.md, it is human-readable, version-controlled, and ready for the next stage. This replaces a path in which the originator first finds someone in product to turn the idea into backlog entries, user stories, story points, and refinement material. Each transfer of ownership moves the final document further from the originator's meaning.

Whatever its route into the process, an agent-written intent.md is reviewed and corrected by the product owner before it is committed. The originator describes the current problem, the people affected, the desired improvement, and anything out of scope, without needing formal product language. Claude asks about users, constraints, scope, and success until the idea is concrete, then writes it in the organization's template. That template can be encoded as a skill, a folder containing a SKILL.md file whose frontmatter says when it should trigger and whose body says what to do. Frontmatter is the metadata block at the top of a markdown file, fenced by ---. The template can cover the problem, proposed outcome, affected users and systems, constraints, and open questions. The originator corrects misunderstandings, then commits the file so its author and timestamp become part of the record.

The required infrastructure is deliberately small: access through claude.ai or Cowork, Anthropic's Claude product for non-engineering roles; an agreed template; and a shared, version-controlled home watched by the product owner. For one product, an intent/ directory in the product repository keeps intent beside the code derived from it. A dedicated repository is warranted only when intent spans many repositories; in a monorepo, a directory is enough. A platform or engineering team establishes the location and its write permissions. Contributors who do not use git directly can have Claude commit the markdown through a version-control connector.

The committed intent.md is also the governance evidence. Git records the author, timestamp, and full revision history, and the product owner's decision to advance or reject it is recorded as a merge or a closed review.

Design begins when the accepted intent is turned into a requirements and design specification. Traditionally, analysts formalize an idea and designers reinterpret those requirements, preserving accountability but introducing delay and information loss. Here, Claude produces spec.md in one session, applying the organization's brand, security, compliance, and UX skills and flagging conflicts or concerns. The product owner reviews rather than authors the specification. For front-end work, the same owner can use Claude Design (beta), Anthropic's design tool, to create and refine a mock from intent.md, then export it to Claude Code for implementation.

The initial pass can be run manually with the prompt below.

Once the process is stable, the prompt can become an organization-level slash command. Acceptance of intent.md can then trigger a non-interactive job that loads the relevant skills and opens spec.md as a pull request. The product owner checks that the specification solves the stated problem and either answers or carries forward every open question. Flagged concerns are handled first with the relevant policy owner, the named owner of the written policy who signs off changes to it.

Committed together, intent.md and spec.md record what was requested and what was decided. A human team member determines whether they progress to Build, consulting a technical lead for changes classified as higher risk. The live policies, generating prompt, specification, and skill versions are all preserved in version control. Accepting the specification starts plan mode.

Engineers open Claude Code in plan mode, a mode in which Claude can inspect the repository but cannot change files, and provide the approved spec.md. Claude interviews the engineer and produces an implementation plan covering the files to change, the order of work, and the tests that will prove the result.

The plan is challenged before any code exists. The engineer asks what could break, which step carries the most risk, and which alternatives were rejected, then iterates until someone outside the conversation could implement the change from the document alone. The approved version is committed as plan.md, joining the audit trail and giving the later PR review a basis for comparing the intended work with the finished diff. If implementation departs from it, plan.md changes in the same commit; a hook can enforce that synchronization. A hook is a script that runs around an agent action and can allow, ask, or block it.

Once the plan is settled, the engineer can use auto mode, also called auto-accept: Claude applies each change without asking for approval edit by edit. Auto-accept becomes suitable for routine work as the surrounding controls mature, including a precise spec.md, a limited blast radius, a tuned CLAUDE.md, relevant skills, deterministic hooks, and tests the agent can run. Attention shifts from watching individual actions to reviewing artifacts produced by longer sessions. Used with worktrees, auto-accept also opens up parallelism for an individual and a team, and it is fundamental to running the SDLC autonomously and closing the loop.

CLAUDE.md supplies the context a new team member would need: build, test, and lint commands; important conventions; architectural boundaries; and recurring mistakes. Running /init creates a starting file, which the team reduces to day-one essentials and commits at the repository root. When Claude makes the same mistake twice, the correction goes into CLAUDE.md. The file stays under a page because Claude reads all of it at the beginning of every session, and stale material consumes context without helping the work. Its changes are reviewed like code.

Skills make institutional knowledge operational. The rule of thumb is to write a skill for institutional knowledge that must be applied consistently, and not to write one for material that belongs in CLAUDE.md or in a prompt. A security standard, API convention, or brand rule can be written from the policy owner's source of truth and stored under .claude/skills/, or distributed organization-wide through a plugin. The team tests the skill by prompting for the relevant task in different ways and confirming that it loads each time. When the underlying policy changes, the skill changes centrally, the policy owner signs off the revision, and engineers receive the new version in subsequent sessions.

A skill is a control, though an advisory one. It makes Claude likely to apply a policy while writing code, but nothing forces a session to comply. A policy that must always hold needs a deterministic layer behind it, such as a hook that blocks the action or a PR review that checks the policy again. Skill invocations remain visible in session traces, and changes receive the same review as code.

Build is where hooks may fire most often because implementation consists largely of file edits and shell commands. They can block changes to protected paths, run a formatter or linter after an edit, and stop credentials from entering a diff. Hooks that run on every matching action should be fast and scoped to the changed file; full tests belong at commit or PR time. Human approval hooks belong with Deploy gates, since inserting an approval prompt into Build would put a person on the critical path of every concurrent session.

Concurrency comes in two distinct forms. A parallel session is a separate Claude Code instance working on another task in its own worktree, a git feature that gives one repository independent checkouts on disk, each on a separate branch, preventing sessions from colliding on files. A subagent is a scoped helper inside one session, with its own context window and tool limits. Parallel sessions increase the number of tasks in flight; subagents keep an individual session focused.

The implementation plan shows where work can be separated. Tasks that touch different files can run in distinct worktrees, using commands such as claude --worktree feature-auth and claude --worktree fix-rate-limit; tasks that share files stay in one session and run sequentially. Two or three parallel sessions are a sensible starting point, with further concurrency limited by how many streams an engineer can review properly. Repeated jobs can become subagents under .claude/agents/, such as a simplifier, a verifier, or a researcher, each declaring when it should run and which tools it may use.

More sessions produce more output, so the controls live in repository configuration rather than individual habits. Hooks and permission settings apply across sessions, while session activity is logged and attributed to the engineer who ran it.

Traditional feedback may arrive from CI minutes later, a tester days later, or production weeks later. With agent-generated code, that delay makes a person responsible for checking the entire output and recreates the bottleneck.

Verification begins with a single reliable command. If checking the work requires several commands and environment knowledge, the sequence is wrapped in make test or npm test, with a non-zero exit on failure. CLAUDE.md lists each command and an example of healthy output. The task itself receives a quantifiable target, such as all tests in test_status.py passing, a screenshot matching the supplied mock, or an endpoint returning 200 with the new field.

For a bug fix, Claude first reproduces the defect as a failing test, runs it, and confirms that it fails for the expected reason. That test is committed before implementation begins, and Claude is then asked to make it pass without editing the test, with a test-file hook enforcing the restriction where required. A test that existed before the fix, and that the agent couldn't rewrite, is proof the bug is gone.

UI work closes the same loop visually. Claude receives the mock and access to a browser or screenshot utility through MCP, the Model Context Protocol that exposes external systems to an agent as tools. It implements, captures the result, compares it with the mock, and adjusts. Two or three rounds are normal. Verification becomes part of "done": the instruction lives in CLAUDE.md, the session runs the checks before reporting completion, and it presents the output.

The loop itself also needs protection, because an agent fixing code must not be able to weaken the check applied to that code. A hook can block test-file edits during a fix; alternatively, review can reject a diff that changes the test. The enforced controls are verification before completion and, where guaranteed, the prohibition on editing the test. Evidence consists of the literal make test output, build log, or screenshot diff, and it is preserved in the session transcript and the PR check run. OpenTelemetry, an open standard for exporting logs and metrics, can forward the transcript into the organization's observability stack. The code owner approves the PR with the mechanical evidence already attached, leaving the review focused on intent and risk.

The agent's configuration is regression-tested through continuous evals. Each eval pairs an input with an accepted outcome, and the suite of them says whether the agent still works to the same standard. This is the AI-native counterpart to stage-gate QA, the traditional practice of placing quality gates at stage boundaries. When a model changes, a prompt is rewritten, or CLAUDE.md, a skill, or a hook is modified, the suite tests the resulting behavior. Some teams may instead run it offline on a fixed cadence.

A platform engineer starts with 20 to 50 real tasks from recent work and records the prompt plus the checks that define an acceptable result, such as passing tests, clean lint, unchanged behavior, or policy compliance. CI runs the suite non-interactively on a schedule and on any change to CLAUDE.md, skills or hooks, and a skill change that drops the pass rate is reviewed before it merges. The suite remains live: when cases stop distinguishing behavior, new ones must be added, drawn from ongoing monitoring, and every production incident contributes a regression eval written by the team that owned it.

With implementation and verification complete, the artifact chain moves to review and release.

Traditional review capacity is planned around human output. A pull request waits for someone to read it, review quality varies with workload, and the author chases responses as the backlog grows. In the AI-native model, every pull request receives the same review passes, producing findings, the problems identified by the review, ranked by severity, or how serious each problem is. Engineers can then concentrate on behavior: whether the change matches the intended plan and whether its risk is acceptable.

This starts with the updated CLAUDE.md produced during Build, any skills that encode written review policies, and defined subagents. The repository also needs a Claude integration. The fastest route is managed Code Review (research preview), Anthropic's managed service, enabled by an administrator for selected repositories. Teams requiring control over the pipeline can instead run claude-code-action, the official action for running Claude Code inside their own CI, routing model calls through AWS Bedrock, Google Vertex or Microsoft Foundry where necessary. Branch protection, meaning git-platform rules that govern merging, can require approval from a code owner, the named owner of a section of code.

The tech lead writes the review policy into REVIEW.md at the repository root. Its passes cover bugs and logical errors, security and vulnerabilities, and compliance with spec.md, plan.md and the organization's design principles. It also distinguishes Important findings from a Nit, a trivial naming or style comment, and states what the reviewer should skip.

Findings neither approve nor block a pull request by themselves, and branch protection still requires code-owner approval. If an organization wants findings to gate merges, the check run publishes severity counts as a machine-readable tally that the platform engineer can evaluate.

When a reviewer or author tags @claude on a review comment, Claude addresses the comment and pushes the fix through claude-code-action, and the pull-request thread preserves both the request and the resulting change. With the managed service, @claude review requests a fresh review. Some teams also wrap the loop in a custom slash command that lets Claude "babysit" its own pull request, to use the guide's word, repeatedly clearing unresolved comments and failing checks until it is green and waiting only for code-owner approval.

Review also writes lessons back into the system. If the same mistake is flagged again, the correction is added to CLAUDE.md during that review, allowing subsequent reviews to catch it immediately, and review can likewise flag when a change has made CLAUDE.md obsolete. Once a month, the tech lead rates findings to improve the reviewer and tunes REVIEW.md, excluding generated paths and checks already enforced by CI; the source's example permits at most five nits per review and summarizes any others as a count.

Separation of duties remains intact because the agent that wrote the code cannot approve it. REVIEW.md applies the same policy to every pull request, while findings, fixes, ratings and approvals remain in the pull-request history, so the pull request becomes the audit record, with final approval supplied by a human through branch protection.

Hooks extend this control to individual actions. During Build, a hook could allow or block an action without human involvement. It can also ask, pausing the action until a named person approves. Engineering leadership, change-management teams and compliance teams identify the approval gates that must remain, including release authorization, change-management sign-off and edits to protected paths. The platform engineer expresses each gate as a script that runs before Claude acts and returns allow, ask or block. Team hooks live in .claude/settings.json; non-negotiable hooks live in managed settings, configuration deployed by the platform or IT administrator that engineers cannot disable. A block should explain itself, so a blocked action reports both the reason and the route to approval. The same mechanism can prevent edits to migrations or infrastructure without a change ticket during Build, or stop changes to test files during a Test-stage fix.

A managed configuration can make those boundaries non-optional. It is distributed through the admin console or MDM, the system used to push configuration to employee machines, and cannot be edited or overridden by engineers.

The pipeline follows the same pattern. claude -p runs Claude Code non-interactively, accepting a prompt and returning output in a form suited to a pipeline job. A platform engineer can begin with read-only judgment tasks such as triaging a failed build, summarizing a flaky test or drafting a changelog. Write tasks, including lint fixes, generated-documentation updates and responses to review comments, remain behind existing gates, and anything the agent writes arrives as a pull request with no route to push directly to main.

Agent jobs run in sandboxed containers under network policies, using short-lived scoped tokens and no standing production credentials. Deployment is exposed through MCP integrations so deploy, status and rollback are environment-scoped tools rather than shell scripts carrying credentials. Autonomy varies by environment: the agent may deploy freely in development, staging sits somewhere in the middle, and in production the agent prepares a release that a release manager must authorize, with a hook enforcing the gate. Rollback should be the most rehearsed path, implemented as a single command and exercised regularly in staging before the closing loop needs it.

Branch protection routes the agent's changes through pull requests. The production hook waits for a named release manager. Each non-interactive run uses the agent's own identity, separating its actions from those of the engineer who triggered it, while environment-specific permissions determine how far it may proceed.

The stage runs headless, and between stages an independent confidence gate, either a deterministic check or an adversarial reviewing agent, decides whether the output proceeds or is escalated. Traditional maintenance is reactive: an alert fires at 3 a.m. and may be missed, a ticket can remain untouched in a backlog, and post-mortem actions may never reach the codebase. Here, a control-band breach, ticket, channel message or schedule invokes Claude without a person starting the process. Claude diagnoses the event, acts only through gated routes and records the finding as intent.md. People triage and review the resulting work rather than having to launch it.

A script watches a production metric with a stable rolling baseline, such as CI test failure rate, post-deploy 5xx rate or pull-request cycle time. A control band is the normal range calculated from the mean and σ, or standard deviation, which measures how much a metric ordinarily varies. Typically the detection script takes the mean and standard deviation over a rolling window, such as rolling_30d, with Western Electric or similar process-control rules so the bands catch slow drift as well as spikes. It is version controlled and unit tested.

A scheduled GitHub or GitLab workflow, a monitoring webhook or a Cron Job inside the network can provide the trigger. Claude runs statelessly through a CI runner or an Agent SDK service in a sandboxed container, allowing the loop to begin and end without an interactive session.

The diagnosis becomes intent.md, using the Plan format to record the anomaly, evidence, proposed outcome, affected systems and open questions. The service owner or on-call engineer routes product-facing findings to the product owner and chooses whether to fix, schedule or dismiss them; dismissals tune the bands and reduce noise. When a fix ships, the incident becomes an eval so the eval suite can test for recurrence.

Tier boundaries remain in version-controlled configuration, while permissions and managed settings deny production access, and invocations, findings and triage decisions are timestamped. A 3σ breach in CI test failures can lead the agent to quarantine a flaky test or open a revert pull request. A 3σ post-deploy 5xx breach with a recent deployment can trigger the existing rollback pipeline. A drift rule on pull-request cycle time can produce a report for engineering leadership, which the guide notes shows the harness works for process metrics as well as production ones.

Incidents can also enter through workplace communication systems. Claude Tag (public beta currently available in Slack) places Claude in a channel under its own identity, so a 10pm Slack message in an incident channel can receive an immediate first response. The discussion and institutional knowledge remain visible in the channel, where team members can test hypotheses, explore options and guide the response, and the channel history adds to the auditability. Through MCP, Claude can verify that a metric has returned to baseline, confirm that result in the thread and write the post-mortem into a version-controlled lessons file. A bounded fix becomes a pull request through the review gate; larger work becomes intent.md, restarting the Plan flow.

The guide presents this as an extension of advances in models and harnesses from coding into the wider software-development lifecycle, while retaining human judgement and accommodating enterprise governance and regulation. It describes itself as a consolidation of many of the real best practices the Applied AI team executes on a daily basis for customers, and it acknowledges Jim Blackhurst, Will Steuk and Jamal Arif as contributors whose earlier work informed it.

Across all 12 plays, the required data already exists in git history, timestamps from the intent home and skill folders, pull-request metadata and history, CI, OpenTelemetry exports, incident trackers and the pass rate recorded by the eval suite on each run. Delivery indicators can also use DORA measures, the standard DevOps Research and Assessment metrics for software delivery. Read down the table below and every indicator lands on one of those existing systems.

Two examples. For Plan, the leading indicator is the time from the first conversation to a committed intent.md, which the source expects to fall from a multi-week elicitation and refinement cycle to hours; that is an expectation rather than a measured result. Its lagging indicator is survival rate, the share of intent.md files accepted by the product owner into Design rather than closed. For Skills, the lagging indicator is the number of pull-request findings that cite the policy, which should move towards zero as the skill applies the policy while code is being written; if it does not, either the skill is failing to trigger or its text has drifted from the official policy.