跪拜 Guibai
← Back to the summary

Anthropic's Playbook for Rebuilding the SDLC Around AI Agents

AI-Native SDLC Playbook

Original | Anthropic Official Blog Author | Louis Claxton Publication Date | August 21, 2026 Original Link | The AI-Native SDLC Playbook Translator | Liu Duorou Chinese Revised Edition | August 24, 2026

How to Transform the Software Development Lifecycle Phase by Phase with AI

Code Is No Longer the Bottleneck

Many organizations have already started using AI to write code at speeds unimaginable a year ago. The development processes surrounding code have not changed in sync.

Many engineering teams are still using the original approval nodes, code reviews, team handoffs, and internal policies. These steps are dragging down the efficiency gains brought by agentic coding tools like Claude Code.

The Software Development Lifecycle, or SDLC, refers to the complete process of software moving from an idea to a production environment. Most organizations follow a process with six phases: Plan, Design, Develop, Test, Deploy, and Maintain.

In the traditional model, each phase is separate and handled by different roles. Product managers write requirements, technical architects translate requirements into designs, engineers complete development, QA teams in regulated enterprises verify, release teams go live, and operations teams monitor production. Work is passed between phases through documents, tickets, and approval records.

The traditional SDLC established numerous processes to ensure clear responsibility and control at every step. This process was formed in a specific era when the most time-consuming and costly step was writing and implementing code. Today, that premise has changed. PRDs, effort estimations, and product security reviews were originally designed to keep participants aligned during development cycles that lasted weeks, months, or even quarters.

The traditional SDLC also assumes every step is done by a human. Currently, organizations gaining the most value from AI are already redesigning processes based on the capabilities of agentic AI, while keeping human judgment at critical junctures.

This article summarizes the practices of Anthropic's Applied AI team in integrating Claude into every phase of the SDLC internally. These practices also come from experience accumulated while working with customers, aiming to accelerate development speed and make the entire process more efficient.

When code is no longer the bottleneck, and the speed of development outpaces what traditional processes can handle, three results emerge.

Development is no longer the limiting factor; the real constraints come from the phases before and after that still run at human speed

Development is no longer the limiting factor. It can be shortened to a few hours, while the human-dependent phases before and after still maintain their original cycles.

Take security review as an example. Security teams are typically staffed according to the output scale of human development. When agents multiply code output several times over, there are only two outcomes. The review queue grows longer, or code goes live with insufficient review. Regulated organizations cannot accept either, so security checks and policy checks must also keep pace with agent speed.

To fully realize the efficiency gains of agentic AI while ensuring safe usage, the traditional SDLC must undergo systematic transformation just like the development phase.

What Is an AI-Native SDLC

An AI-native SDLC retains the original control objectives while adopting new execution and enforcement mechanisms suitable for AI agents. The process is no longer a one-time linear path, but a continuous cycle where AI is embedded in every phase.

Handoffs between phases can be automated, and subsequent processes can be automatically triggered by the artifacts of the previous phase, thereby reducing the large amount of human-dependent, inefficient handoffs in the traditional SDLC.

AI-Native SDLC Cycle

Changes in Two Modes

The table below lists the typical states at both ends of the traditional SDLC and the AI-native SDLC supported by Claude. Most organizations are currently somewhere in between.

Phase Traditional SDLC AI-Native SDLC
Plan Committees gather requirements, organize them through workshops and multiple rounds of approval, and finally have them written into documents by people Claude directly aggregates pain points from primary sources and writes them into intent.md. This document is both human-readable and machine-actionable
Design Analysts write specifications, and designers complete designs based on the specifications Agents complete requirements analysis and design in a single work session, constrained by organizational standards in skills, with results stored in Git version control
Develop Tests and code are written by people, and documentation is usually written after the main development is complete Tests and code are generated by AI, and organizational knowledge is maintained through version-controlled, machine-readable CLAUDE.md and skills
Test QA sets up checks at phase boundaries Continuous evals run throughout the development phase
Deploy People review code line by line, governance depends on review cycles, and enforcement standards are often inconsistent Specialized reviews are completed by multi-layered agents, with regulated and critical code still reviewed by people. Governance requirements take effect immediately when AI executes actions, and hooks enforce approval checks
Maintain People monitor production environments and search for bugs Agents monitor online deployments. When metrics exceed control limits, the system completes diagnosis and writes the results back into the cycle as a new intent.md

A common thread runs through the right column for each phase: version-controlled artifacts. At the end of each phase, an artifact is committed to the version control system. The next phase begins by reading this artifact.

These artifacts include intent.md, spec.md, plan.md, code diffs and their tests, PRs with review results, and incident records. The first few phases primarily use Markdown files, because product owners and agents can read and modify the same document together. Starting from the development phase, the main artifacts become code and its related records.

When commit records are strung together, they form an audit trail. It shows who proposed what, what the agent produced, and who approved it. For any decision requiring judgment, the ultimate responsibility always rests with a human. In an agentic SDLC, human attention follows the artifacts that need review, moving backward.

Each phase commits an artifact that the next phase can read. Intent, spec, plan, code diffs, and review results together form a complete audit trail.

Implementation Practices

These practices are the core of this playbook. They are distributed across the six non-linear phases of Plan, Design, Develop, Test, Deploy, and Maintain, together covering the complete software development lifecycle.

Each practice explains the following.

These steps are independent of each other, and organizations can prioritize transforming different phases at different times according to their own needs. Each practice states its dependencies in the "Prerequisites" section, and the dependency graph in the original text further illustrates these relationships.

A phase ends with a committed artifact, and this commit starts the next phase. An accepted intent.md triggers the requirements and design process, an approved spec.md triggers plan mode, a merged PR triggers the pipeline, and production metrics exceeding control limits generate the next intent.md, thus continuing the cycle.

At the beginning, each step is initiated by a human manually entering a prompt. The end state is a continuously running cycle, where each accepted artifact triggers the next check node. Human attention is focused on these nodes, only needing to review items flagged by the agent, without having to process each phase from scratch.

Implementation practices and recommended adoption order

The practices in the diagram are arranged by their phase, and arrows indicate the recommended adoption order; the two are not exactly the same. Light brown practices without arrows pointing to them do not depend on other practices and can be started directly. The remaining practices require adopting the prerequisite practices that point to them first.

01 | Plan

Ideas no longer need to wait for someone else to organize them into documents. The initiator only needs to record the intent once in their own words, forming a version-controlled artifact that the next phase can act upon.

Writing Ideas as intent.md

intent.md is used to start the software development process. It can originate from different entry points. A person proposes an idea, a team receives a ticket, or an alert exposes an incident. The incident entry point is explained in the sixth phase, "Maintain."

When someone proposes an idea, they can first discuss it with Claude and generate a preliminary specification draft in Markdown format. In the traditional SDLC, the same person would also need to convince a product team member to help organize it, or write a formal document on their behalf.

The specification draft generated by Claude is human-readable, can be version-controlled, and can be directly used by the next phase. The team saves it as intent.md.

Whether the intent comes from an event trigger or an agent, the subsequent steps are the same. The product owner needs to review and correct the agent-written intent.md before committing it.

Traditional Approach

An idea goes through a backlog, user stories, story points, and requirement grooming meetings before anyone starts acting on it. Each handoff transfers ownership, and the content that finally reaches the engineering team is often several layers removed from the initiator's original intent.

AI-Native Approach

The initiator discusses with Claude and writes the result as intent.md. This is a specification draft written in the initiator's own language, explaining what is wanted, why it is needed, and what the constraints are. Repetitive processes can be encoded as skills.

How to Get Started

Prerequisites

None.

Infrastructure

The organization needs to make Claude accessible to non-engineering personnel, for example through claude.ai or Cowork. It also needs a unified intent.md template, and a shared, version-controlled storage location that the product owner continuously monitors.

For a single product, the simplest approach is to create an intent/ directory within the product repository. This way, the intent artifact and the code it generates are kept together. Only when an intent involves multiple repositories does the extra cost of a separate intent repository become worthwhile. In a monorepo, it remains just a directory. The third phase's "Legacy Systems and Source of Truth" section will explain how this location works with Jira or existing requirements tools.

The platform team or engineering team only needs to set this up once. Technical members need to establish the storage location and decide who can write to it, as contributors may come from different departments within the organization.

Once the repository is set up, contributors without Git experience do not need to operate Git directly. Claude can commit Markdown files on their behalf from claude.ai or Cowork through connectors to version control systems like GitHub.

Execution Steps

  1. The initiator describes the problem to Claude in their own words. They can explain what cannot be done currently, who is affected, what the ideal outcome is, and what is out of scope. Formal wording is not required.
  2. Discuss with Claude until the idea is sufficiently concrete. Claude will ask the questions an analyst would typically ask, including scope, users, constraints, and success criteria.
  3. Have Claude write the result as intent.md according to the organizational template. The template can be encoded as a skill, built by a technical member and approved by the owner. The template can cover the problem, desired outcome, affected users and systems, constraints, and open questions.
  4. The initiator corrects anything Claude misunderstood.
  5. Commit intent.md to the shared location. The author and timestamp enter the record, and the product owner takes over from here.

Example

# Intent: claims status self-service

Author: J. Ortiz (claims operations)
Status: draft

## Problem

Customers call the support center to inquire about claim progress. Support agents spend roughly one-third of their call time on simple status inquiries.

## Proposed outcome

Customers can view claim status, next steps, and estimated dates in the portal.

## Affected users and systems

Claims support agents, portal team, claims-core API.

## Constraints

Cannot introduce new personally identifiable information in the portal session. Must use existing authentication methods.

## Open questions

Do third-party adjusters also need access?

Governance Considerations

The evidence is the committed intent.md. The file contains the author, timestamp, and complete revision history, all recorded in the Git history of the intent storage location.

The product owner is responsible for approval. The decision to let this intent enter the second phase is reflected by merging the artifact, or closing the related review.

How to Measure

Leading Indicators

Measure the time from the first discussion to the commit of intent.md. The author and timestamp can be read directly from the Git history of the storage location. The expected result is to shorten the requirements elicitation and grooming cycle that used to last weeks down to a few hours.

Lagging Indicators

Measure the proportion of intent.md files that the product owner allows to enter the second phase, which the original text calls the survival rate. Acceptance decisions are reflected by merging the artifact, and rejection decisions by closing the review.

Also, count how many times intent.md is modified after the first spec.md is submitted for the same change.

02 | Design

Requirements analysis and design are merged into a single session. Policy requirements are applied as the specification is being written, without having to wait until the review phase weeks later to discover issues.

Merging Requirements Analysis and Design

After the product owner approves the intent, Claude generates the requirements and design specification based on the accepted intent.md. The organization's brand, security, compliance, and UX skills provide constraints during this process.

The product owner is responsible for reviewing the specification but does not have to write it personally. The ultimate goal is to obtain a specification that the engineering team can use to formulate a plan, with issues requiring attention already flagged.

Frontend development best illustrates this practice. After intent.md is accepted, the product owner can generate design drafts based on it in the Claude Design beta. After multiple rounds of adjustments and confirmation of satisfaction, the design draft is exported to Claude Code for implementation.

Traditional Approach

Requirements analysis and design are completed by two teams in separate phases. Analysts first organize ideas into formal requirements, and designers then complete the design based on the requirements. This division of labor clarifies responsibility but slows down speed and loses information during handoffs.

AI-Native Approach

The two phases are completed in a single prompt-guided session. Claude generates the requirements and design specification based on intent.md, with the organization's skills providing constraints, and issues requiring attention are explicitly flagged.

How to Get Started

Prerequisites

Infrastructure

A product owner who can use Claude, with no engineering skills required.

Execution Steps

  1. The product owner starts a session, loads the organization's skills, and attaches intent.md.
  2. The prompt needs to reference intent.md, explicitly state the constraints, and ask Claude to flag issues requiring attention. The team can first execute this manually, then turn the prompt into an organization-level slash command. Later, accepting intent.md can be set as a trigger. When the file is merged, the system starts a non-interactive task, loads the organization's skills, and submits spec.md via a pull request. The CI/CD practice in the fifth phase will introduce this pipeline. After automation is complete, the product owner's first intervention is reviewing the specification.
  3. The same product owner needs to review the specification against the original idea. Does the specification solve the originally proposed problem? Have the open questions in intent.md been answered, or are they left for later?
  4. Prioritize the issues flagged by Claude. Analysts would have also forwarded such issues to specialists. Before the engineering team sees the specification, the product owner needs to resolve each item with the corresponding policy owner.
  5. Commit spec.md together with intent.md. These two documents jointly record the goals and decisions already made.
  6. The product owner decides whether the specification and intent can enter development. Items deemed high-risk by the organization require consultation with the tech lead. This judgment is always made by a human. Accepting the specification starts the plan mode of the third phase.

Example Prompt

Read the attached intent.md and write a requirements and design specification explaining how to integrate it into the existing codebase.

Apply the currently available skills to ensure the solution meets brand, security, and UX standards.

Write the complete content into spec.md so that the engineering team can formulate a plan based on it.

Clearly state all issues requiring attention, especially when conflicting policy requirements cannot be simultaneously satisfied.

Governance Considerations

Policy requirements are read and applied as the specification is being formed, without needing to wait until the review phase weeks later to discover issues. The organization's skills become constraints for the specification.

The specification, the prompt that generated it, and the skill versions in effect at the time are all retained in the version control record. The product owner approves the specification and hands off flagged issues to the corresponding policy owners.

How to Measure

Leading Indicators

Measure the time from the commit of intent.md to the commit of spec.md for the same change. Two Git timestamps can directly provide this data, which can be compared against past requirements-plus-design cycles.

Lagging Indicators

Measure requirements rework after development has started. Count how many commits occur to spec.md after the first plan.md is submitted for the same change. Git logs can directly provide this data.

03 | Develop

No implementation begins without an approved plan. Organizational knowledge becomes files that agents can read, and guardrails are enforced as code, no longer relying solely on human habits.

Defaulting to Claude Code Plan Mode

The engineer starts a Claude Code session in plan mode and gives Claude the spec.md approved in the second phase. Claude then asks the engineer questions, and both parties continuously modify the plan until the engineer is satisfied.

Traditional Approach

The engineer reads the design and starts writing code. How to implement the change, which files need modification, and what tests need to be added usually exist only in the engineer's mind, or at best in ticket comments. Others cannot review this content in advance.

Reviewers see the completed code diff for the first time. By this point, rework has already become slow.

AI-Native Approach

Work begins with a written plan. Claude generates the plan in plan mode. This mode allows it to read the codebase but not modify anything.

The engineer corrects the plan before code generation, and the approved version is committed as plan.md, which subsequent phases will use to check against the actual results.

How to Get Started

Prerequisites

If an intent artifact already exists, intent.md or spec.md needs to be provided. Having a CLAUDE.md is also helpful.

Infrastructure

Claude Code with access to the codebase.

Execution Steps

  1. The engineer starts a Claude session in plan mode.
  2. Give intent.md and spec.md to Claude and ask it to formulate an implementation plan. The plan needs to state which files will be modified, the order of work, and which tests will be used to verify the results.
  3. Continue questioning the plan. What might this change break? Which step is the highest risk? What alternative approaches did Claude not adopt?
  4. Keep modifying until an engineer who has never seen this session could complete the implementation by reading the plan alone.
  5. Commit the approved plan as plan.md. It becomes part of the audit trail. The PR review in the fifth phase will check the final code diff against the plan.
  6. Accept the plan and let Claude start implementing. When the plan is sufficiently solid, implementation can often be completed in one go.
  7. When the actual implementation deviates from the plan, update plan.md in the same commit. Teams can consider using a hook to enforce keeping the two in sync.

plan.md Example

# Plan: claims status self-service (from intent.md 2026-06-02)

## Files that change

portal/src/claims/StatusPanel.tsx (new), claims-api/routes/status.py,
claims-api/tests/test_status.py

## Order of work

1. Add a status endpoint behind existing authentication.
2. Have the panel call that endpoint.
3. Integrate the panel into the portal navigation.

## Risks

The claims-core API rate limit is 50 requests per second; the panel must use caching.

## Proof

test_status.py covers four claim statuses, and screenshots match the approved design draft.

Governance Considerations

Design review is completed before any code generation. At this point, changing direction only requires editing a document. Plan mode itself enforces this, because Claude cannot edit files until the engineer accepts the plan.

The plan and its revision history are saved, and the person who accepted the plan is also recorded. Routine changes are approved by the engineer; changes deemed high-risk by the organization are handed to the tech lead or architect.

How to Measure

Leading Indicators

Count the proportion of changes that can be merged on the first implementation, and the time from plan approval to PR merge. The required data is in the PR metadata.

Lagging Indicators

Count the number of rework rounds each change undergoes, with data also from PR metadata. Also observe the proportion of merged code diffs that remain consistent with the committed plan.md.

Claude Code Auto Mode

Claude Code can also run in auto mode. After the engineer goes through multiple rounds of adjustment and approves the plan, Claude applies changes one by one without requesting permission for each individual edit.

As the guardrails in subsequent practices mature, auto-accept becomes the default for routine work. These guardrails include a tuned CLAUDE.md, skills for coding policies, hooks that block unsafe actions, and a test suite that Claude can run on its own.

Work suitable for auto-accept typically has three characteristics: a clearly scoped spec.md, a small blast radius, and existing test coverage for the relevant code.

The way of working also changes. Users no longer need to watch the agent edit and review each action one by one; they can review the artifacts directly after longer autonomous sessions. Auto-accept combined with worktrees also supports parallel work for individuals and teams. It is also the foundation for letting the SDLC run autonomously and completing the cycle in the sixth phase.

Legacy Systems and Source of Truth

This section applies to every artifact produced by the process.

The existing SDLC is likely already tracking these artifacts, just not using Markdown files. Work items might be stored in Jira, requirements might be stored in tools with built-in regulatory tracking capabilities, designs in Figma, and change approvals recorded by a change advisory board.

These systems are hard to replace. Auditors and regulators have accepted them, and other teams depend on them. The AI-native SDLC must therefore adapt to the existing environment.

When transitioning to an AI-native SDLC, a single source of truth system needs to be designated for each artifact produced by the process. Other systems can only keep copies, or save links pointing to the original. Different artifacts can use different configurations.

Code Repository as Source of Truth

Markdown artifacts are the source of truth, and legacy systems reference the files in specific commits. For organizations led by engineering teams, this is usually the cleanest configuration. All records are in one tool, using the same set of timestamps as evidence.

Legacy System as Source of Truth

Jira, ServiceNow, or requirements tools hold the source of truth, and Markdown artifacts are just working copies. Claude reads the record at the start of the session and writes the results back to the legacy system via MCP connectors in the same session that generates the specification or plan.

Minimum Requirement: Establish Bidirectional Links

All artifacts record the corresponding item number, and all legacy records also save the commit SHA of the Markdown file. Early in the transformation, starting with bidirectional links is acceptable, but the organization needs to accept the temporary existence of two sources of truth.

Legacy systems and Markdown-centric systems can coexist. At minimum, there must be links between them, or one must be explicitly designated as the source of truth.

CLAUDE.md

CLAUDE.md provides Claude with the context a new team member would need to onboard, including team conventions, common commands, system architecture, and the errors the team encounters most often.

Knowledge previously stored in human brains and wikis becomes a file that agents read at the start of every session. The entire team co-maintains this file, updating it whenever an error occurs.

How to Get Started

Prerequisites

None.

Infrastructure

A codebase, Claude Code installed, and an engineer familiar with the codebase.

Execution Steps

  1. Run /init in the codebase. Claude generates an initial version of CLAUDE.md based on what it discovers.
  2. Trim the generated file down to what a new member truly needs on their first day. Keep build, test, and lint commands, truly important conventions, and things Claude frequently gets wrong.
  3. Commit CLAUDE.md to the repository root so the whole team shares the same version. Changes to it should also be reviewed like code.
  4. Adopt a simple rule: the second time Claude makes the same mistake, write the correction into CLAUDE.md.
  5. Keep the file to one page or less. Claude reads the entire content at the start of each session; stale information only wastes context space.

CLAUDE.md Example

# Payments service

## Commands

- Build: make build
- Test: make test (unit tests), make itest (integration tests, requires Docker)
- Lint: make lint (also runs in CI, must be fixed before pushing)

## Conventions

- Java 21, Spring Boot 3. Do not add Lombok.
- Always use BigDecimal for monetary amounts, never double.
- Every endpoint needs an integration test in src/itest.

## Architecture

- api/ holds REST controllers, core/ holds domain logic, adapters/ handles connections to external systems.
- Kafka events are defined in schemas/. Do not edit generated classes.

## Things Claude gets wrong

- Do not upgrade dependency versions; the platform team handles this.
- The legacy v1/ package is frozen; changes should go into v2/.

Governance Considerations

CLAUDE.md is version-controlled, so the instructions used by agents can be reviewed and audited. Team conventions take effect through this file, every modification is recorded in Git history, and approved by code owners during PR review.

How to Measure

Leading Indicators

Count the frequency with which Claude repeats mistakes that should have been prevented by CLAUDE.md. Corrections and modifications to CLAUDE.md should also be tracked in Git history.

Lagging Indicators

Count the time it takes for a new team member's first PR to be merged after joining. Data comes from PR history.

Preserving Organizational Knowledge with Skills

Organizations can turn internal knowledge into practical action through skills. Instructions become explicit, version-controlled, widely used across the organization, and centrally updated when policies change.

A practical principle is to write organizational knowledge that needs to be consistently enforced every time as a skill. Content that belongs in CLAUDE.md or a regular prompt does not need to be a separate skill.

How to Get Started

Prerequisites

No hard prerequisites. CLAUDE.md is helpful because it keeps the agent's working knowledge in the codebase, but skills do not depend on it.

Infrastructure

A policy that has a designated owner and a written authoritative source.

Execution Steps

  1. Pick a standard or rule that is currently enforced most inconsistently. It could be a security standard, an API design convention, or a brand rule.
  2. Write it as a skill. A skill is a directory containing SKILL.md, with frontmatter specifying when it triggers and the body specifying what to execute. The engineer writes it based on the policy owner's authoritative material, or can have Claude assist.
  3. Place the skill in .claude/skills/<name>/ within the codebase so it is distributed with the code. It can also be distributed across the organization via plugins.
  4. Test whether the skill triggers. Ask Claude to perform the relevant task using different phrasings and confirm it loads the skill every time.
  5. When the policy changes, update the skill, and have the policy owner approve the change.
  6. Engineers automatically get the new version in their next session.

.claude/skills/secure-api-review/SKILL.md Example

---
name: secure-api-review
description: Apply API security standards. Use when creating or modifying external endpoints, reviewing API code, or generating OpenAPI specs.
---

# Secure API review

When creating or modifying API endpoints, perform the following checks.

1. Authentication. Every endpoint requires a gateway JWT; no anonymous routes except /health.
2. Input validation. Validate request bodies against the OpenAPI schema and reject unknown fields.
3. Audit. Every state-changing endpoint must emit an audit event containing actor, action, entity, and timestamp.
4. Data classification. Fields marked as pii in the schema must not appear in logs or error messages.

Run scripts/check-endpoints.sh and include the output in the summary.

Governance Considerations

Skills are advisory controls. They increase the probability that Claude applies the policy when writing code, but no mechanism can force every session to comply.

Policies that must always hold also need a deterministic mechanism, such as a hook that blocks the relevant action, or a specialized review that re-checks the policy at the PR stage. Skills reduce violations; hooks make violations extremely difficult.

Skill invocations are recorded in the session trace, and policy owners must review skill modifications just like code reviews.

How to Measure

Leading Indicators

Measure the time from when a policy owner approves a policy change to when the updated skill is merged. Data comes from the PR corresponding to the skill directory.

Lagging Indicators

Count the number of issues citing that policy in PR reviews. After the skill starts applying the policy during the code-writing phase, this number should gradually approach zero.

If the number does not drop, there are usually two reasons: the skill is not triggering, or its text has diverged from the official policy.

Establishing Development-Phase Guardrails with Hooks

Skills provide advisory controls; hooks provide deterministic constraints behind the scenes. Most actions Claude performs during the implementation phase are editing files and running shell commands, so hooks trigger most frequently in this phase.

Development-phase hooks can perform the following operations.

Any policy that must be enforced without exception should have a hook added after the corresponding skill. Hooks run on every matching action, so development-phase hooks should be fast enough and only check files that have changed. Heavier checks like full test suites are better suited to run at commit or PR stage.

Hooks requiring human approval should be placed in the approval nodes of the fifth phase. Frequent approval prompts during development would put a person back on the critical path for all parallel sessions.

Parallel Sessions and Sub-Agents

A single engineer can advance multiple pieces of work simultaneously.

A parallel session is another complete Claude Code instance. It works on an independent task in its own Git worktree. The sessions are unaware of each other; the only commonality is that the same engineer is responsible for coordination.

A sub-agent runs within a single session. It is a scope-limited assistant with its own context window and tool permissions, suitable for handling recurring work across multiple tasks, such as verifying that an application runs as expected.

Parallel sessions increase the number of tasks one engineer can advance simultaneously; sub-agents keep each session focused. The engineer coordinates and reviews all results.

Traditional Approach

An engineer works on one task at a time, with a significant portion of each day or week spent waiting for builds, tests, and reviews. They could switch tasks during the wait, but context switching is taxing, and few people are willing to do it frequently.

AI-Native Approach

An engineer runs multiple Claude sessions simultaneously. Each session completes its own task in an independent worktree. Recurring work is handed to sub-agents with independent context and tool restrictions. The engineer's work gradually shifts toward coordination, eventually becoming building and monitoring autonomous cycles.

How to Get Started

Prerequisites

CLAUDE.md is needed because all sessions read this file. The feedback loops introduced in the fourth phase are also very helpful. Once sessions can verify their own results, the supervision required from the engineer decreases.

Infrastructure

A Git repository. Worktrees provide isolation. Permission settings also need to be tuned to avoid sessions constantly waiting for approval when executing commands the organization deems safe.

Execution Steps

  1. The engineer breaks the work into tasks that modify different files. The plan generated by plan mode can help determine which tasks are independent of each other. Tasks that need to modify the same file should be placed in the same session and executed sequentially.
  2. Each parallel task uses its own worktree. For example, run claude --worktree feature-auth in one terminal and claude --worktree fix-rate-limit in another. A worktree is an independent working copy on a separate branch, preventing different sessions from modifying the same file simultaneously.
  3. Starting with two to three sessions is appropriate. The actual number depends on whether one person can seriously review the results of each stream. Only increase sessions when the review speed can keep up.
  4. Define recurring work as sub-agents. Definition files go in the .claude/agents/ directory, written in Markdown, and contain a name, a description of applicable scenarios, and allowed tools. Common examples include a code simplifier that removes unnecessarily complex designs, a verifier that runs the application and checks behavior, and a research agent that explores the codebase and reports results. The last practice avoids consuming the main session's context. Commit these definitions to Git so the whole team can share them.

.claude/agents/verifier.md Example

---
name: verifier
description: Run the application before the session reports completion and check whether the changes take effect
tools: Bash, Read
---

Start the application using make run. Check the changed behavior and the two closest related flows.

Report what was run, what was observed, and any behavior that does not match plan.md.

Do not fix problems, only report.

Governance Considerations

More sessions mean more output, so control measures must come from the configuration in the codebase. Hooks and permission settings apply to all sessions. The operations performed by each session are logged and attributed to the engineer who started it.

How to Measure

Leading Indicators

Count the number of sessions each engineer runs simultaneously without a drop in review quality. Data can be obtained from OpenTelemetry exports. Also count the proportion of the day spent coordinating tasks, compared against waiting time.

Lagging Indicators

Count the number of changes merged per engineer per week, observed together with the rework rate from PR history.

04 | Test

Every session must check its own work before a human sees the results. The configuration used to guide agents must also undergo regression testing, just like the code the agents write.

Building Feedback Loops for Claude

Always provide Claude with a way to verify results, whether it's tests, builds, or screenshot diffs. The session needs to check itself before the engineer sees the results and fix its own errors.

Feedback loops and the verifier sub-agent introduced in the third phase serve different purposes. Feedback loops run throughout the task, with the number of runs determined by the work itself. The verifier sub-agent is a way to encapsulate the final check. After the session believes the work is complete, it performs the check in a fresh context window, so the final judgment is not influenced by the assumptions made while generating the code.

Traditional Approach

Signals about whether code works often come very late. CI takes minutes to return results, testers might not intervene for days, and problems might not even be exposed in production for weeks.

When code is generated by agents, late feedback means someone must check all of its output, and that person then becomes the bottleneck.

AI-Native Approach

The session needs to check itself before a human sees the results. Run tests, complete builds, capture screenshots. Claude keeps modifying until the checks pass. The results the engineer receives have already gone through this round of verification.

The engineer running the session is responsible for building the feedback loops, and the steps below are aimed at these engineers.

How to Get Started

Prerequisites

None.

Infrastructure

The test suite and build process should both support running locally with a single command. For UI work, Claude must also be able to see the results, either using a browser tool or accessing a screenshot tool via MCP.

Execution Steps

  1. If the check work requires running multiple commands in sequence and depends on some environmental knowledge, encapsulate these steps into a single unified command or build target, such as make test or npm test. When a check fails, the command must exit with a non-zero status code.
  2. List each command in the Commands section of CLAUDE.md, along with an example of normal output.
  3. Set quantifiable goals so Claude can check itself without asking. For example, all tests in test_status.py must pass, the screenshot must match the design draft in the attachment, or the endpoint must return 200 and include the new field.
  4. When fixing a bug, first write a failing test. Have Claude reproduce the bug as a test, run the test, and confirm it fails for the expected reason. Commit this test first, then have Claude fix the code without modifying the test. The test file hook introduced in the last step can enforce this restriction. The test existed before the fix, and the agent cannot rewrite it, which proves the bug has truly disappeared.
  5. UI work must complete the feedback loop through visual checks. Provide Claude with a browser or screenshot tool, plus the design draft, and let it repeatedly implement, screenshot, compare, and adjust. Two to three rounds are normal, and each round should show improvement.
  6. Include verification in the completion criteria. The relevant instructions are written in CLAUDE.md. Claude must run tests and show the output before reporting task completion.
  7. The feedback loop itself also needs protection. An agent fixing code must not be able to weaken the checks against that code. A hook can prevent the agent from editing test files during a fix task. Another approach is to check the code diff during review and reject any change that modifies tests.

Verification Configuration Example in CLAUDE.md

## Verifying your work

- Build: make build (must end with "Build succeeded")
- Test: make test (all tests must pass; do not skip or delete failing tests)
- Lint: make lint (zero warnings)

Before reporting task completion, run the above three checks and paste the output.
If tests fail, fix the code; do not modify the tests.

Governance Considerations

What Needs to Be Enforced

Verification must pass before reporting task completion. During fixes, the agent cannot edit test files. When the organization needs to guarantee these two requirements, they can be implemented as hooks.

What Can Serve as Evidence

The make test output that Claude actually ran and pasted, build logs, or screenshot diffs. The evidence comes directly from the toolchain.

Where Records Are Kept

Records are saved in the session logs, and OpenTelemetry exports forward them to the organization's observability system. PR check records also retain relevant information, visible to both reviewers and future auditors.

Approver

The code owner reviewing the PR. Evidence from automated checks is already attached, so reviewers can focus their attention on the intent of the change and the risks.

How to Measure

Leading Indicators

Count the proportion of agent-written changes that pass on the first CI run. Existing CI systems usually already support this data.

Lagging Indicators

Count the review time per PR, with data from PR metadata. This time should decrease once tests start catching issues that reviewers previously had to find. Also count the change failure rate from the incident tracking system.

Running Evals Continuously in CI

Evals are the AI-native equivalent of traditional phased QA. The actual form is an evaluation suite that runs whenever the agent configuration changes.

When a team changes models or rewrites prompts, the eval suite can determine whether the agent can still complete work to the same standard.

Evals should be treated as a continuously changing test set. As models improve, cases that previously differentiated performance will gradually lose their discriminatory power. Teams need to add new cases based on issues discovered through continuous monitoring.

Different scenarios can use different run modes. Some teams run evals offline on a fixed schedule, without needing to execute them on every change. The steps below target continuous evals.

How to Get Started

Prerequisites

CLAUDE.md, and the feedback loops introduced in this phase.

Infrastructure

CI capable of running Claude Code non-interactively, and an API key with sufficient budget to run the evals.

Execution Steps

  1. A platform engineer collects 20 to 50 real tasks from recent work and records the expected or acceptable results.
  2. Write each task as an eval. It consists of a prompt and a check to determine whether the result is acceptable, such as tests passing, lint having no errors, behavior not changing, and policies being followed.
  3. The eval suite runs non-interactively in CI. It needs to execute on a schedule and also whenever CLAUDE.md, skills, or hooks change. These configurations guide the agent and should undergo the same regression testing as code.
  4. Set the eval results as a merge check for configuration changes. If a skill modification causes the pass rate to drop, it must be reviewed before merging.
  5. Add an eval for every production incident, written by the team responsible for that incident, and kept permanently in the suite as a regression test.

.github/workflows/agent-evals.yml Example

name: Agent evals
on:
  pull_request:
    paths: ['CLAUDE.md', '.claude/**']
  schedule:
    - cron: '0 2 * * *'
jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install -g @anthropic-ai/claude-code
      - name: Run eval suite
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          for eval in evals/*.json; do
            claude -p "$(jq -r '.prompt' $eval)" \
              --allowedTools "Read,Edit,Bash(make test)" \
              --output-format json > result.json
            ./evals/check.sh "$eval" result.json
          done

Governance Considerations

Evals provide a check for QA that can keep pace with agent output speed. The pass rate threshold is enforced as a merge check, every run leaves a record, and teams can compare results across different periods. The team owning the configuration change is responsible for approval.

How to Measure

Leading Indicators

Observe the change in eval pass rate over time. The suite reports results on every run. Also count the time it takes for a production incident to become a permanent eval.

Lagging Indicators

Compare regressions caught in CI against regressions found in production. Production data comes from the incident tracking system.

05 | Deploy

Reviews happen bidirectionally, and governance requirements take effect immediately when agents execute actions. Agents can complete all work up to the production approval node but cannot cross this node on their own.

Bringing AI into the PR Review Loop

Claude can both review content submitted by others and receive reviews from others on its own work. It checks newly submitted PRs against organizational policies while also handling review comments received on PRs it created.

This way, engineers can focus on behavior during PR reviews, ultimately needing to judge only two things: whether the change matches the intent, and whether the risk is acceptable.

Traditional Approach

Review capacity is configured according to human output scale. A PR waits for a reviewer to read everything, and review quality fluctuates with the reviewer's load. Submitters constantly urge reviewers, and the backlog continues to grow.

AI-Native Approach

All PRs receive the same set of specialized reviews, and discovered issues are sorted by severity. Human attention shifts to a higher level, judging whether the change achieves the planned goal and whether the risk is acceptable.

How to Get Started

Prerequisites

Infrastructure

The codebase needs the Claude integration installed. Administrators can enable the managed Code Review service, currently in research preview. Teams can also run claude-code-action in their own CI. When needed, model calls can be made through AWS Bedrock, Google Vertex, or Microsoft Foundry. The CI/CD practice later will explain deployment options.

It is also recommended to enable branch protection rules requiring code owner approval.

Execution Steps

  1. The managed Code Review service is the fastest starting point. An administrator enables the service and selects the codebase. When needing to control the pipeline, or wanting model calls to continue using the organization's existing cloud service contracts and account systems, run reviews using claude-code-action in your own CI. The CI/CD practice later will explain the relevant connection methods.
  2. The tech lead writes REVIEW.md in the repository root, dividing the review policy into specialized reviews the organization cares about. Common categories include bugs and logic errors, security and vulnerabilities, compliance with the spec spec.md, implementation plan plan.md, and design principles. REVIEW.md also defines what counts as Important, what only counts as Nit, and what does not need to be reported.
  3. The tech lead sets the criteria for human intervention. Review findings themselves do not approve or block PRs; branch protection still requires code owner approval. Platform engineers who wish to block merges based on findings can read the machine-readable severity counts published by the check task.
  4. After a reviewer or submitter mentions @claude in a review comment, Claude processes the comment and pushes a fix. The PR discussion thread records both the request and the change. This fix loop runs through claude-code-action. In the managed service, commenting @claude review requests a new review. For PRs created by Claude itself, it can also be set to continuously process issues until the PR meets merge conditions. Teams can turn this loop into a custom slash command that scans unresolved review comments and failed checks, processes issues and pushes fixes, until the PR passes everything and only awaits code owner approval.
  5. Review findings should feed back into CLAUDE.md. The second time the same error is found by a review, write the correction into CLAUDE.md during that review. The review process reads CLAUDE.md, so the next PR will catch this type of error from the start. Reviews should also point out which changes make CLAUDE.md outdated.
  6. The tech lead adjusts the configuration monthly. Improve the reviewer by scoring review findings, limit the number of Nits in REVIEW.md, and exclude generated file paths and content already enforced by CI.

REVIEW.md Example

# Review instructions

## Passes

Perform three rounds of specialized review and label each finding with its category.

- Bugs: Logic errors, broken edge cases, subtle regressions
- Security: Injection risks, authentication gaps, PII in logs
- Compliance: Changes conform to spec.md, plan.md, and organizational design principles

## What Important means here

Important is only used for issues that break behavior, leak data, or violate policy.
Style and naming issues are Nits.

## Cap the nits

Report at most five Nits per review; for the rest, only summarize the count.

## Do not report

Do not report generated files under src/gen/, or content already enforced by CI.

Governance Considerations

Separation of duties is preserved because the agent that writes the code does not have permission to approve code. The review policy in REVIEW.md applies to all PRs. Findings, fixes, scores, and approvals are all recorded in the PR history, so the PR itself is the audit record.

Final approval is still made by a human and enforced by branch protection rules. Review findings inform the human's decision.

How to Measure

Leading Indicators

Count the time waiting for the first review, with the goal of shortening it to minutes. Also count the proportion of review comments resolved without a human needing to modify the branch, with data directly stored in Git.

Lagging Indicators

Compare defects and vulnerabilities found before merge against issues that escape to production. Data comes from PR history and the incident tracking system.

Establishing Approval Nodes with Hooks

The third phase used hooks as guardrails, allowing or blocking actions without human involvement. Hooks can also initiate approval requests and pause the current action until a designated person approves. This is exactly the behavior needed for release approvals.

This practice is placed in the deployment phase because release approvals best illustrate its use, but hooks are not limited to deployment. Hooks can run wherever Claude executes actions.

For example, the third phase can use hooks to block database migrations and infrastructure modifications without a change ticket. The fourth phase can also block agents from editing test files during fix tasks.

How to Get Started

Prerequisites

None.

Infrastructure

A written list listing all approvals required by the change process.

Execution Steps

  1. Engineering management, together with change management and compliance teams, jointly lists the human approval nodes that must be retained, such as change management approval, release authorization, and modifications to protected paths.
  2. A platform engineer implements each approval node as a hook. A hook is a script that runs before Claude executes an action and can allow, request approval for, or block the action.
  3. Team-level hooks go in .claude/settings.json in Git. Non-negotiable hooks go into managed settings managed by platform admins or IT admins, which individual engineers cannot disable.
  4. When blocking an action, the reason must be explained. After a hook blocks an operation, the reason and the method to request approval should appear in Claude's output.

.claude/settings.json Example

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/production-gate.sh"
          }
        ]
      }
    ]
  }
}

.claude/hooks/production-gate.sh Example

#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
  if [ -z "$RELEASE_APPROVAL" ]; then
    echo "Production deploys need a release authorization." >&2
    exit 2 # exit 2 blocks the action; the message goes to Claude
  fi
fi
exit 0

Governance Considerations

Hooks are the approval nodes. Check conditions are enforced for every person, every action. Allow and block decisions are timestamped and recorded. The approval node also defines what counts as a valid approval, such as an approved change ticket, or a release manager's authorization.

Managed Settings Example for Regulated Enterprises

The following configuration is pushed by the platform team via MDM or the admin console. Engineers cannot edit or override any of these settings.

{
  "permissions": {
    "deny": [
      "Read(.env*)",
      "Read(./secrets/**)",
      "WebFetch",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "allow": [
      "Bash(git *)",
      "Bash(make build)",
      "Bash(make test)",
      "Bash(make lint)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": [
        "git.internal.example.com",
        "registry.npmjs.org"
      ]
    },
    "credentials": {
      "files": [
        {
          "path": "~/.ssh",
          "mode": "deny"
        },
        {
          "path": "~/.aws/credentials",
          "mode": "deny"
        }
      ],
      "envVars": [
        {
          "name": "GITHUB_TOKEN",
          "mode": "deny"
        }
      ]
    }
  },
  "allowManagedHooksOnly": true,
  "disableSideloadFlags": true,
  "allowManagedMcpServersOnly": true,
  "strictKnownMarketplaces": [
    {
      "source": "github",
      "repo": "example-corp/approved-plugins"
    }
  ],
  "requiredMinimumVersion": "2.1.193"
}

Below is a point-by-point explanation of the control effects these settings provide.

permissions.deny prevents secrets from entering the agent's context and also blocks tools from arbitrarily accessing external networks. permissions.allow pre-approves safe daily development operations, avoiding frequent authorization prompts caused by the deny list.

With disableBypassPermissionsMode combined with allowManagedPermissionRulesOnly, neither engineers, project files, nor command-line arguments can relax the rules.

sandbox is used to cover gaps that permission rules cannot address. Blocking WebFetch at the tool level does not prevent shell commands from accessing the network. An OS-level domain allowlist can directly block unauthorized external connections.

failIfUnavailable and allowUnsandboxedCommands make the sandbox a mandatory check. Claude Code refuses to start if the sandbox cannot be initialized. Commands that fail inside the sandbox also cannot be retried outside the sandbox.

credentials covers another gap left by deny rules. permissions.deny manages Claude's file tools, but shell commands inside the sandbox might still read ~/.ssh or ~/.aws/credentials by default. This section blocks reading these files and removes specified keys from the environment variables of every sandbox command.

allowManagedHooksOnly means only the approval hooks defined in this section can run; local configurations cannot add or replace them.

With disableSideloadFlags combined with strictKnownMarketplaces, every skill, agent, hook, and MCP server on an engineer's machine must come from an organization-approved plugin marketplace and cannot be sideloaded from the user's home directory.

allowManagedMcpServersOnly turns the agent's tool scope into an allowlist maintained by the platform team.

requiredMinimumVersion refuses to start versions below the approved floor, ensuring these control measures are enforced by a version of Claude Code the organization has already evaluated.

The configuration above is just a starting point that needs to be adjusted to actual circumstances; direct copying is not recommended. Every deny rule restricts some capability, and the correct balance depends on the data classification of the codebase. The settings reference documentation lists all configuration keys, including items that can only be set by administrators.

How to Measure Hooks

Leading Indicators

Count the wait time at each approval node. Every hook decision is written to the OpenTelemetry export, recording the timestamp and the allow or block result, so the wait time at each node can be observed.

Lagging Indicators

Compare the number of incidents that violated approval requirements and entered production before and after introducing hooks. Data comes from the incident tracking system.

CI/CD Integration and Deployment

Run Claude Code non-interactively in the CI/CD pipeline. The execution environment uses a sandbox to keep long-running agents safe. Deployment capabilities are provided through MCP integrations, and the rollback path is repeatedly rehearsed before the agent ever truly needs it.

Traditional Approach

The pipeline runs deterministic scripts. Any work requiring judgment waits for a human, such as analyzing flaky tests, writing changelogs, or identifying the cause of a build failure. Deployment and rollback rely on runbooks, executed by people under pressure.

AI-Native Approach

Claude handles steps requiring judgment non-interactively inside the pipeline. It runs in a sandbox, holding only narrowly scoped credentials. Deployment tools are provided to the agent via MCP.

This way, the same workflow that completes code writing and testing can also complete releases and rollbacks within the approval nodes the organization has set for each environment.

How to Get Started

Prerequisites

Claude is already in the PR review loop, and hooks are already serving as approval nodes. Approval nodes must exist before automation starts accelerating the process.

Infrastructure

Execution Steps

  1. Platform engineers start with read-only judgment work. Use claude -p in pipeline jobs to analyze build failures, summarize flaky tests, or draft changelogs.
  2. Add write operations after existing approval nodes, such as fixing lint, updating generated docs, or processing review comments via @claude mentions. Anything the agent writes must enter the codebase through PRs and branch protection; the agent cannot push directly to main.
  3. All execution happens in a sandbox. Agent tasks run in containers subject to network policies, holding only short-lived, narrowly scoped tokens, with no production credentials by default.
  4. Provide deployment capabilities through MCP. Deploy, status query, and rollback become tools with permissions scoped by environment. The agent's deployment permissions are explicitly limited by an allowlist, no longer relying on shell scripts carrying credentials.
  5. Scale autonomy by environment. In development environments, agents can deploy freely. In production environments, agents prepare releases, release managers authorize, and hooks enforce the production approval. Staging environments sit in between.
  6. Rollback should become the most rehearsed path in the pipeline. It should be a command the agent can run, regularly rehearsed in staging environments. The continuous cycle introduced in the sixth phase calls rollback when metrics exceed control limits, so this path must be validated in advance.

Pipeline Step Example

- name: Triage failed build
  if: failure()
  run: >
    claude -p "Read the build log in out/build.log. Point out the most likely cause,
    judge whether this failure is more like a flake or a real fault, and write a
    three-line summary for the PR discussion thread." >> triage.md

Governance Considerations

The core principle is to let the agent execute up to the production approval node but not cross it on its own. The following control measures enforce this principle.

How to Measure

Leading Indicators

Count the proportion of pipeline failures where analysis is completed without notifying a human. Data comes from CI/CD pipeline logs.

Lagging Indicators

Observe DevOps Research and Assessment, i.e., DORA metrics. CI systems and deployment tools can usually already generate this data.

06 | Maintain

The cycle connects back to the starting point here. Triggers can call Claude without human initiation, and Claude's findings re-enter the pipeline as intent.md.

Maintaining and Keeping the Process Running

The previous sections introduced how to add Claude to each phase of the SDLC. Initially, each phase requires a human to start the first step. In the maintenance phase, the focus shifts to letting Claude run autonomously, enabling the entire process to cycle continuously.

For example, a continuously running monitoring agent can create intent.md after a bug ticket appears, then let it pass sequentially through the requirements, plan, development, test, and review phases.

The maintenance phase can run unattended. Independent trustworthiness checks are set between phases, where a deterministic check or an adversarial review agent decides whether the previous phase's result can continue flowing, or needs to be handed off to a human.

Traditional Approach

Maintenance is a passive phase. All tickets and incidents wait for people to handle them, and then for people to restart the process. A 3 AM alert might be missed, tickets might stay in the backlog forever, and action items from incident postmortems might never enter the codebase because new incidents keep arriving.

AI-Native Approach

Metrics exceeding control limits, tickets, channel messages, or scheduled tasks can all call Claude without human involvement. Claude is responsible for diagnosis, can only take action through paths with checks in place, and writes findings as intent.md, handing them off to the phases introduced earlier.

Humans continue to be responsible for dispatching and reviewing this work but no longer have to personally start the process.

Closing the Loop

A deterministic script is responsible for monitoring the production environment. When metrics exceed control limits, the script calls Claude. Monitoring metric excursions is just one common scenario used to illustrate the autonomous cycle. The Claude Tag section at the end of this phase will introduce work entering from other channels.

How to Get Started

Prerequisites

Infrastructure

Execution Steps

  1. The service owner or platform engineer selects a metric with a stable rolling baseline, such as CI test failure rate, post-deployment 5xx rate, or PR cycle time.
  2. Write the detection script. A common approach is to calculate the mean and standard deviation over a rolling time window, then use Western Electric or similar rules so the control limits can detect both sudden spikes and slow drifts. The script should be version-controlled and have unit tests. The detection process remains fully deterministic and does not use a model.
  3. Define response tiers in a version-controlled configuration, like the bands.yaml example below. At 1σ, the script only logs. At 2σ, it calls Claude read-only for diagnosis. At 3σ, Claude can take action, but only by submitting a PR for review, or triggering a pre-approved runbook.
  4. The trigger layer can use scheduled workflows in GitHub or GitLab, webhooks sent by existing monitoring systems, or internal cron jobs. Claude runs statelessly, either as a non-interactive step on a CI executor, or as an Agent SDK service in a sandbox container. The CI/CD practice introduced deployment and model access options. The run process is stateless and requires no interaction, so the entire cycle can start and end on its own without anyone initiating it.
  5. The agent writes the diagnosis as intent.md following the format of the first phase. The content includes the anomaly and its evidence, the suggested outcome, affected systems, and open questions. After this, the finding goes through the complete pipeline like any other work.
  6. The service owner or on-call engineer processes the dispatch queue, handing product-related findings to the product owner. They can choose to fix immediately, schedule for a later plan, or dismiss. Dismissal results are used to adjust control limits and reduce noise.
  7. After the fix goes live, add an eval for this incident. Continuous evals will keep it as a regression test, preventing the same type of issue from recurring.

bands.yaml Example

The configuration below monitors the CI test failure rate.

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

Governance Considerations

The boundaries of the response tiers are enforced by version-controlled configuration, and permissions and managed settings deny production access. Every invocation, every finding, and every dispatch decision is timestamped and recorded.

The service owner is responsible for handling and approving findings. The resulting changes still go through normal PR review. Runbooks that the agent can trigger must also be pre-approved.

How to Measure

Leading Indicators

Count the time from when a metric exceeds control limits to when intent.md enters the dispatch queue, and compare it against the past time from incident occurrence to the formation of a postmortem action item. Detection script logs record the excursion timestamp and incident tier.

Lagging Indicators

Count the proportion of findings that ultimately become merged fixes. The dispatch queue can be cross-referenced against actual PR history. Also count the number of times the same type of incident recurs. As fixes continuously add cases to the eval suite, this number should decrease.

Examples

Detection always remains deterministic. Claude is only called after a metric exceeds control limits, and the response tier determines what actions it can take.

On-Call with Claude Tag

Incidents can also enter through work communication tools like Slack or Teams. In the past, an urgent fix message appearing in an incident channel at 10 PM would wait for a human to handle it. Now, such messages can receive an immediate response.

Claude Tag is currently in public beta for Slack. It lets Claude join channels using its own identity, giving every new incident an immediate first responder. The handling process also becomes part of the cycle and leaves a record that can be referenced when handling similar incidents in the future.

Conversations and organizational knowledge stay in the channel, and anyone in the channel can guide and handle the response. Team members can validate hypotheses, try new approaches, and conduct investigations in real time. The channel history also improves the auditability of the entire process.

Claude accesses relevant systems via MCP, confirms whether metrics have returned to baseline, and reports results in the discussion thread. It also writes the incident postmortem into a version-controlled experience file, to be read by future investigations.

The work handled by Claude Tag is not limited to incidents. When Claude is mentioned in a ticket via MCP, or receives a question in a channel, it dispatches work in the same way.

Smaller, well-bounded fixes result in a PR and go through the review node. Larger work is written as intent.md and re-enters the first phase. At this point, the cycle begins to run on its own.

Claude Tag handling an incident in a channel

The channel itself is the audit record. Requests, diagnoses, human authorizations, and fixes all remain where the incident was actually handled.

Conclusion

As models and their supporting tools and control frameworks continue to strengthen, organizations can transform how code is produced, and can also transform the entire software development lifecycle.

This transformation keeps human judgment at the center of the process while considering the governance and regulatory requirements of large enterprises.

This guide compiles many real practices that Anthropic's Applied AI team executes daily for customers. We hope it can serve as a practical, directly actionable resource.

The cycle runs continuously, and the final judgment always rests with a human.

Resources and Acknowledgments

The following documents can help platform teams build the control measures introduced in this article. The order roughly corresponds to the recommended implementation order.

Thanks to Jim Blackhurst, Will Steuk, and Jamal Arif for their contributions to this guide. This article is inspired by and built upon their extensive prior work.