The AI-native SDLC: how to adopt it without losing control

Coding agents have changed where software delivery time goes. A feature that used to take a sprint to build can now be implemented in an afternoon. Yet many teams report that overall lead time has barely moved. The reason is simple: the steps around the code (refining requirements, waiting for review, security sign-off, release approval) still run at human speed.

Anthropic's recent AI-Native SDLC Playbook makes this point well: code is no longer the bottleneck; the human-speed steps around it are. It lays out how to redesign the whole lifecycle around agents while keeping people accountable for every decision that needs judgement.

This article is our practical companion to it. We summarise the model, then focus on what the playbook can't cover for every organisation: how to roll it out in a real company, where adoption usually stalls, and how to keep auditors, security teams and engineers comfortable along the way.

The model in one table

The playbook describes six stages. Each one produces a version-controlled artifact that the next stage reads, so the work flows from intent to production as a chain of plain files in Git.

Stage	Artifact	What the agent does	Where people decide	First metric to watch
Plan	`intent.md`	Turns a conversation into a structured problem statement	Is this worth doing?	Time from idea to committed intent
Design	`spec.md`	Drafts requirements and design with your policies applied	Is this the right solution?	Spec changes after build starts
Build	`plan.md` + code	Reads the codebase, proposes a plan, implements	Approve the plan	Changes merged from the first pass
Test	Tests, CI results	Runs tests and builds, iterates until green	Review what the agent flagged	First-pass CI success rate
Deploy	Pull request, review notes	Reviews PRs against policy, answers review comments	Approve risky changes and releases	Time to first review
Maintain	Incident record, new `intent.md`	Diagnoses anomalies, proposes fixes	Accept or reject the fix	Time from alert to proposed fix

Two ideas carry the whole model:

Every stage leaves a committed artifact. Intent, spec, plan, diff, review findings and incident notes are all in version control, so the history of a change is readable by anyone, human or agent.
Governance is code, not a committee. Policies live in files the agent reads while it works (skills and context files), checks that can't be skipped (hooks and CI), platform settings engineers can't override, and branch protection so an agent can never approve its own change.

Why regulated companies should like this, not fear it

The first reaction we hear from banks, insurers and healthcare teams is: "Agents writing code? Our auditors will never accept that." In practice, the opposite is often true.

A traditional lifecycle leaves its evidence scattered across tickets, chat threads, meeting notes and people's memories. An AI-native lifecycle, done properly, produces a complete, timestamped trail by default:

Why the change exists (intent.md, with who approved it);
What was agreed and which policies applied (spec.md and the policy files in force at that commit);
How it was built and tested (plan.md, the diff, test and CI results);
Who reviewed and released it (pull request approvals, protected branches, release gates);
What happened in production and how it was fixed (incident record linked to the follow-up change).

That is exactly the kind of traceability that change-management controls in ISO 27001, SOC 2, DORA and internal model-risk frameworks ask for. The work is making sure the chain is complete and tamper-evident, not arguing about whether agents are allowed at all.

One caution: this covers how you build software with AI. If the software you build is itself an AI system, obligations such as the EU AI Act apply to that product separately, and the same artifact chain becomes useful evidence for them too.

Governance as code: the four layers

Think of controls in four layers, from "guidance" to "impossible to bypass":

Context and skills tell the agent how your organisation works: architecture conventions, security rules, accessibility and brand standards, approved libraries. They are version-controlled and reviewed like code.
Hooks and CI checks are deterministic. They block an action or require approval: for example, stop an agent from editing existing tests while fixing a bug, or refuse a commit that contains a secret.
Managed settings are set centrally and can't be overridden by an individual engineer: which tools and MCP servers are allowed, sandboxing, network and credential access, minimum tool versions.
Branch protection and release gates enforce separation of duties: required human reviewers, code-owner approval for sensitive paths, and named sign-off before production.

A simple way to write this down, before touching any tool configuration, is a one-page policy per environment. An illustrative example:

# Illustrative autonomy policy (not a tool config)
development:
  agent_may: [read_repo, run_tests, edit_code, open_pr]
  requires_human: []
staging:
  agent_may: [open_pr, run_migrations_on_copy]
  requires_human: [merge]
production:
  agent_may: [propose_fix, run_preapproved_runbook]
  requires_human: [merge, deploy, change_access, change_data]
always_blocked: [read_secrets, disable_tests, approve_own_pr, push_to_main]

Agree this with security and platform teams first, then implement it in whatever tools you use. The policy is the durable part; the configuration will change as tools evolve.

Where adoption usually stalls

From what we see in engineering organisations, the model rarely fails on the technology. It fails on the seams between teams:

Review becomes the new queue. Agents open more pull requests than people can read line by line. Fix: agent-assisted first review against policy, smaller changes, and human attention focused on behaviour, risk and design rather than formatting.
Weak tests get gamed. If the test suite is thin, an agent that "iterates until green" will find the shortest path to green. Fix: protect existing tests from edits during fixes, require new tests for new behaviour, and add evaluations for anything non-deterministic.
Context files go stale. A CLAUDE.md or equivalent written once and forgotten slowly misleads every session. Fix: treat it like code, with an owner, reviews, and a regression check whenever it changes.
Parallel sessions overload CI. One engineer running five agent sessions can triple pipeline load overnight. Fix: budget CI capacity and cost before scaling, and cache aggressively.
Security joins too late. If the security team first sees the setup during a production approval, expect a pause. Fix: involve them in writing the autonomy policy in week one.
The wrong metrics. Lines of code and number of prompts measure activity, not delivery. Fix: measure lead time per stage, first-pass success, review time and escaped defects.

A 30/60/90-day adoption plan

You don't need the whole model on day one. The playbook's advice to start small is right; this is how we would sequence it for a typical product team.

Days 1 to 30: one team, one repository, build and test only

Pick a well-tested service with a motivated team.
Write the context file (architecture, conventions, how to run tests) and two or three skills for your most important policies.
Use plan mode for every non-trivial change: the agent proposes, a person approves, then it builds.
Add the first hooks: no secrets, no edits to existing tests during fixes.
Record a baseline: lead time, review time, first-pass CI rate, escaped defects.

Days 31 to 60: add the artifacts and the review layer

Introduce intent.md and spec.md for new work, committed next to the code.
Turn on agent-assisted first review against your policies; keep human approval required.
Agree and implement the per-environment autonomy policy with security and platform teams.
Start an evaluation suite that runs whenever context files, skills or hooks change.

Days 61 to 90: close the loop and scale

Connect monitoring so anomalies produce a draft intent.md for triage, not just an alert.
Turn every production incident into a permanent test or evaluation case.
Rehearse rollback before giving agents any production-adjacent runbooks.
Compare with the baseline, write down what worked, and roll out to the next two teams with managed settings in place.

What to measure first

If you track only four numbers, track these, per stage and per team:

Metric	Why it matters
Lead time from committed intent to production	The number the business actually feels
Share of changes merged from the first implementation pass	Shows whether context, skills and specs are good enough
Time to first review	Reveals whether review has become the new bottleneck
Defects escaping to production	Makes sure speed isn't paid for with quality

It isn't tied to one tool

The playbook is written around Claude Code, and it maps cleanly onto it. But the principles (committed artifacts, plan before build, self-checking sessions, governance as code, separation of duties, incidents feeding evaluations) apply whichever coding agents your teams use, and many organisations run more than one. Because the artifacts are plain Markdown in Git, they outlive any single tool choice.

Frequently asked questions

Do we need to redesign our whole SDLC before using coding agents?

No. Start with the build and test stages in one repository, measure a baseline, and add planning artifacts, review automation and production feedback loops step by step over roughly 90 days.

Can an AI agent merge or deploy its own code?

It shouldn't. Branch protection and release gates should make it technically impossible for an agent to approve its own pull request or deploy to production without a named human approver.

Is an AI-native SDLC compatible with ISO 27001, SOC 2 or DORA?

Yes, and it can make audits easier. Committed intent, spec, plan, review and incident artifacts give a complete, timestamped change trail, as long as the chain is complete and approvals are enforced by the platform rather than by convention.

How do we stop agents from gaming the tests?

Block edits to existing tests while fixing bugs, require new tests for new behaviour, keep a protected regression suite the agent cannot modify, and add evaluations for non-deterministic behaviour.

How we can help

We help engineering teams adopt agentic development safely: writing the autonomy policy with your security team, setting up context files, skills, hooks and managed settings, building the evaluation suite, and connecting production monitoring back into the loop. A typical starting point is a two to three week Architecture Sprint on one team and one repository, with a measured baseline and a rollout plan at the end.

Want to discuss your setup? Book a consultation.