AI-Native SDLC: Closing the Loop from Intent to Operations

This is a field guide from the Claude team, with templates and implementation examples, not a comparative study. Most practices are familiar from software engineering and DevOps; the playbook's value lies in assembling them into one route. Once an agent can produce code quickly, the constraints shift to problem framing, design, validation, review, release, and operations. Optimizing Build alone cannot accelerate delivery while adjacent stages still rely on queues and manual handoffs. The guide is therefore a working hypothesis to test on a team's own flow. It does not prove universal gains, but it shows where to look for a displaced queue and which artifacts connect stages without losing intent.

Anthropic replaces that relay with a loop: Plan, Design, Build, Test, Deploy, and Maintain. A product owner describes a problem in ordinary language or by voice; the model asks questions and produces intent.md with the outcome, constraints, and acceptance evidence. Design turns it into spec.md. Versioning both artifacts lets a team trace a bad result past the code to a faulty specification or initial intent. Traceability corrects decisions rather than merely retaining audit documents. Separating intent from specification prevents a technical solution from silently replacing the user problem. If success is unclear at the first step, rapid implementation only creates a convincing but unacceptable result faster.

Organizational knowledge enters Design through CLAUDE.md, skills, and policies: approved technologies, API rules, security requirements, examples, and incident lessons. A declarative constraint survives model upgrades better than an imperative recipe tied to one model. In a regulated organization, advisory guidance is insufficient. Critical requirements need deterministic checks, narrow permissions, and CI/CD gates; each new exception should become a test or evaluation scenario. This creates a useful hierarchy: prose explains intent, a check detects violation, and a permission boundary makes a forbidden action impossible. The higher the failure cost, the less the system should depend on model compliance.

Build begins with plan.md, not code generation. A polished plan is easy to trust, so a human must check its sequence before implementation—moving design review to a point where corrections are cheap. The agent then uses project instructions, commands, hooks, skills, subagents, and automation. Guardrails must prevent secret leakage, bypassed checks, and tests tailored to an implementation. Confidence in this harness should come from accepted outcomes, regressions, and incident evidence, not an impressive demo. The plan also creates stop points. After each verifiable step, the team can decide whether execution should continue and what context belongs in the next stage, reducing the cost of a wrong direction.

Test combines conventional suites and security scanners with continuous evaluations of the agent workflow. The corpus grows from real exceptions and reruns whenever the model, prompt, or harness changes. Deploy uses familiar release gates, while Review becomes the next bottleneck as generated changes outgrow human attention. Hooks can block formal violations and repeatable questions can move into review.md, but humans still own judgments about architecture, risk, and the original intent. Review automation should reduce noise before a human decision rather than generate another volume of text to read. A useful check identifies a specific deviation and links it to a criterion, preserving expert attention for exceptions.

Maintain is the discussion's strongest stage. A monitoring signal or incident creates a new intent; an agent gathers evidence, proposes a specification and plan, prepares a branch, fix, and tests, and sends them through the same gates. Even without autonomous deployment, this produces a change ready for human approval sooner. The economics should be measured through accepted tasks and avoided rework, not token totals: use stronger models for ambiguity and cheaper ones to execute a well-specified plan under reliable tests. Closing the loop turns an operating fact into a new verifiable intent instead of losing it in a separate queue. Automated repair still leaves an incident owner and a human right to stop release.