# The AI-native SDLC: how to adopt it without losing control > Coding agents make the build phase fast. Planning, review and deployment are now the bottleneck. A practical guide to redesigning your software lifecycle, with governance built in. Source: https://aibyos.com/blog/the-ai-native-sdlc-how-to-adopt-it-without-losing-control AI Agents · SDLC · Governance · Claude Code · Engineering # The AI-native SDLC: how to adopt it without losing control Coding agents make the build phase fast. Planning, review and deployment are now the bottleneck. A practical guide to redesigning your software lifecycle, with governance built in. AIBYOS · 29 August 2026 · 8 min read 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](https://claude.com/blog/the-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: 1. **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. 2. **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": 1. **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. 2. **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. 3. **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. 4. **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: ```yaml # 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](https://aibyos.com/how-we-work) on one team and one repository, with a measured baseline and a rollout plan at the end. Related: [AI Agents & Agentic Workflows](https://aibyos.com/services/agents) · [Agent Infrastructure & Runtime](https://aibyos.com/services/agent-infra) · [Evaluation, Guardrails & AI Security](https://aibyos.com/services/evals) · [AI Governance & EU AI Act](https://aibyos.com/services/governance) Want to discuss your setup? [Book a consultation](https://aibyos.com/contact). [← All articles](https://aibyos.com/blog/)