Building an AI-native SDLC: artifacts, guardrails, and infrastructure

AI can write a working implementation in hours. The surrounding work still takes days: clarifying the request, finding the current design, waiting for security review, preparing a release, and working out who can approve it.

That mismatch is where many teams lose the time they gained from coding agents. Code moves faster, but the queues around code do not.

Figure 1. Coding agents move the bottleneck; they do not remove the delivery system. Original diagram based on concepts discussed in Anthropic’s AI-Native SDLC Playbook.

Anthropic’s AI-Native SDLC Playbook describes a useful way to rebuild the workflow. Its 14 lessons cover planning, design, build, test, deploy, and maintenance. This guide draws on that course, then extends the discussion to knowledge ownership, API access, team budgets, isolated execution, and operational evidence. It is an independent guide, not a lesson-by-lesson translation.

What is an AI-native SDLC?

An AI-native software development lifecycle is a delivery loop in which agents can plan, implement, test, review, and operate software, while people remain accountable for goals, risk, and production approval.

The loop is held together by committed artifacts:

intent.md → spec.md → plan.md → code + tests → reviewed PR → release record
    ↑                                                        ↓
    └──────────── incident / metric / user feedback ─────────┘

Each stage writes something durable to version control. The next stage reads it before acting. A chat transcript may explain how an answer was reached, but it is a poor system of record. A commit can show what was requested, what changed, which checks ran, and who approved the result.

Treat the six stages as a loop. A failed test can send the work back to the plan. A production alert can create a new intent.md. Every handoff still needs a named input, a reviewable output, and an owner.

Figure 2. The delivery record closes the loop between production evidence and the next intent. Original diagram based on concepts discussed in the Anthropic course.

What each stage should leave behind

Stage	Committed artifact	Work an agent can do	Judgment people retain
Plan	intent.md	Gather source material, expose missing constraints, draft success criteria	Decide whether the problem is worth solving and whether the scope is right
Design	spec.md, interface contract, prototype	Read the current system, draft a design, flag conflicts with existing rules	Choose trade-offs, accept risk, set the experience standard
Build	plan.md, code, tests	Inspect the repository, break down the work, implement, and run checks	Approve the plan and authorize sensitive actions
Test	Test output, eval results, review findings	Reproduce defects, run deterministic checks, review against written rules	Decide whether behavior meets the requirement and whether residual risk is acceptable
Deploy	Release record, approval, rollback point	Assemble the release, verify gates, execute approved steps	Choose the production window and give final authorization
Maintain	Metrics, incident record, new intent.md	Diagnose anomalies, collect evidence, prepare a corrective change	Decide whether to roll back, escalate, or begin another delivery loop

Start with a useful intent.md

A one-line feature request does not give an agent enough context to make good decisions. Keep the first artifact shorter than a full product requirements document, but make sure it answers five questions: What is wrong today? What should change? Who is affected? What cannot change? What is still unresolved?

# Intent: Let customers check refund status

Owner: Payments product team
Status: Draft

## Problem
Support staff manually check refund progress. Customers cannot tell whether
their refund is still processing or has already been returned.

## Expected outcome
The order page shows the refund state, expected arrival window, and an
escalation path when processing runs late.

## Scope
Order UI, refund service, payment-provider status sync, support console.

## Constraints
- Do not expose raw provider errors to customers.
- Reuse existing sign-in and order permissions.
- Customer and support views must use the same status definitions.

## Open questions
- How should partial refunds appear?
- Who owns cases that exceed the expected arrival window?

The product owner edits and accepts this file before design begins. If the direction is wrong, the team fixes a short document instead of discovering the mismatch in a nearly finished pull request.

Build three kinds of shared assets

A coding assistant can make one engineer faster. Repeatable team performance depends on shared assets that survive individual sessions.

Figure 3. Foundational practices support delegation and evaluation before teams automate delivery. This is a practical build order, not a mandatory product checklist; source concept: Anthropic Claude Academy.

Agent capabilities

Skills, tool definitions, repository instructions, hooks, and small scripts tell an agent how work is done in a particular environment.

• A Skill records a repeatable method, such as reviewing an external API, validating a release, or investigating an incident.
• MCP can expose source control, documentation, logs, monitoring, and ticket systems as permissioned tools.
• A Hook can block a forbidden action, scan for secrets, or require approval before a production command.
• Repository instructions record build commands, architectural boundaries, and mistakes the team has already corrected.

These mechanisms do different jobs. A Skill explains the method. A Hook or CI job enforces a rule. A prompt cannot replace access control, branch protection, or a release gate.

CLAUDE.md and Claude Code hooks are Anthropic-specific implementations. Other coding agents use their own repository instructions and command controls. The practice carries across tools, but each tool implements it differently.

Product and engineering knowledge

Agents need current project facts, not a larger pile of documents. Requirements, business rules, interface contracts, data definitions, test evidence, release records, and incident reviews should have owners and links to the code versions they describe.

A practical knowledge index records the owner, affected systems, risk, source documents, code references, and last review date for each piece of work. It should also distinguish among:

1. Supplier documentation and contractual statements.
2. Facts confirmed in source code or configuration.
3. Behavior observed in a named version and environment.

An agent can find missing links and draft updates. The person responsible for the system still accepts the official record.

Delivery rules

The workflow connects capabilities and knowledge. A copy change may need a short brief, a build, and a visual check. A payment change may also require a security design, contract tests, a migration plan, an approval, and a rollback rehearsal.

Git, a code host, CI, and manual approvals are enough to test the first version. A workflow platform is useful only after the team knows which artifacts and gates it needs repeatedly.

Infrastructure becomes part of the development process

Connecting a model API to an editor solves one task. Running many local sessions, CI jobs, support agents, and production automations creates a different set of problems.

Layer	Minimum capability	Why it matters
Model access	Consistent endpoints, model catalog, routing, timeouts, failure handling	Tools do not need a separate integration for every supplier
Identity and permissions	Separate keys for people, CI, and agents; limits by model, IP, lifetime, and operation	A compromised or looping task can be revoked without stopping everyone
Budget and billing	One team balance with limits and alerts by member, project, key, or task	The team can attribute spend and contain one runaway job
Context and retrieval	Versioned sources, inherited permissions, citations, review dates	Agents can tell current facts from stale or unauthorized material
Execution	Sandboxes, separate worktrees, network rules, command allowlists, secret isolation	Parallel tasks do not overwrite one another, and risky commands have boundaries
Quality	Unit and integration tests, evals, policy scans, human review	Model, prompt, or Skill changes can be checked for regressions
Delivery and observation	CI/CD, approvals, rollback, request logs, latency, errors, cost	A change can be traced, diagnosed, and reversed

Team budget management deserves explicit design. A developer session, a CI job, and a production agent should not share one unrestricted API key. They can draw from one funded account, but each caller needs its own identity, model access, expiry, limit, and cost record.

Keep hard gates deterministic

An agent may review agent-written code, but it should not be the only release gate. Compilation, type checks, unit tests, contract tests, secret scanning, branch protection, and production approvals should produce results that another system can verify.

Acceptance criteria should be runnable where possible:

• A bug fix starts with a test that reproduces the failure.
• A frontend change passes the build and the user journey, with a screenshot for visual review.
• An API change checks authentication, success and error responses, and billing records.
• A release records the source commit, artifact checksum, active version, and rollback version.

Do not let the implementing agent remove a failing regression test to make its change pass. Protect critical tests with repository permissions, hooks, or an independent read-only verification job.

Turn real failures into evals

An eval checks whether an agent still follows the expected behavior after a model, prompt, repository rule, or Skill changes. Start with a small set drawn from recent work: a recurring review comment, a real defect, or a production incident.

Each case needs an input, allowed tools, expected behavior, and a machine-checkable result. Track the failure category, human takeover, first-pass success, and cost alongside the pass rate. A single score does not explain what regressed.

A four-week trial is enough to expose the real gaps

Week 1: establish the source of truth

Choose one repository and one active request. Write the minimum repository instructions: build and test commands, directory boundaries, sensitive operations, and acceptance criteria. Draft an intent.md with an owner and open questions.

Week 2: run the artifact chain

Move the same request through intent.md → spec.md → plan.md → PR → release record. Ask each stage only for material the next stage will use. Record waiting time, rework, and every place where the agent needs missing context.

Week 3: encode repeated corrections

Put repeated working methods into a Skill or repository instruction. Put non-negotiable rules into a Hook or CI check. Add one real defect to the test or eval set.

Week 4: separate access and cost

Give people, CI, and agents separate identities. Set model permissions, expiry, and budgets. Confirm that logs can be queried by project and caller. Rehearse key revocation, task termination, and release rollback.

After this trial, the team has evidence for deciding whether it needs a workflow platform. Before the trial, that decision is mostly guesswork.

Measure delivery, not code volume

Lines of generated code and tokens consumed are activity metrics. They do not show whether the team ships better software.

Area	Useful signals
Delivery	Time from accepted intent to production; waiting time at each stage
Quality	First-pass acceptance, regression defects, rollbacks, incident recovery time
Knowledge	Coverage of official sources, broken index links, stale documents, takeovers caused by missing context
Agents	Task completion, failure categories, human takeover, model cost per successful task

Use different gates for different risks. A low-risk text change should not wait on the same process as a payment migration. A high-risk change should not bypass evidence and approval because the diff was generated quickly.

Frequently asked questions

Does an AI-native SDLC let agents publish code without people?

No. Agents can carry out more of the work, but the organization still defines production authority, separation of duties, and acceptable risk. Development environments can allow wider action. Production should keep explicit approval for sensitive changes.

Do teams have to use Claude Code?

No. Anthropic’s course uses Claude Code, CLAUDE.md, Skills, and hooks as its implementation. Committed artifacts, deterministic checks, separate identities, and human gates can be used with other coding agents.

Why keep Markdown in version control if the team already has a knowledge base?

The agent needs to know which version is current and how it relates to a code change. Version control supplies diffs, authorship, timestamps, and rollback. A knowledge base can remain the reading surface if it preserves those links.

When does a shared AI platform become useful?

It becomes useful when several projects repeatedly need the same model access, identity, budget, retrieval, evaluation, and audit controls. First run one complete artifact chain with Git and CI. Build or buy the platform around the constraints that appear in that trial.

How should a team control spending across many agents?

Assign separate keys to people, CI, projects, and agents. Set a model scope, expiry, and budget for each key while funding them from one team balance. Record usage by caller, and stop abnormal loops before they consume the remaining budget.

Sources and further reading

• The AI-Native SDLC Playbook, Anthropic Claude Academy
• Claude Code overview, Anthropic documentation
• Model Context Protocol documentation

For a first trial, choose one live request and commit its intent.md. Follow it through design, implementation, review, release, and production feedback. The waiting, rework, and human takeovers you record will tell you what to change next.