The Agentic SDLC: Your Bottleneck Didn’t Disappear, It Moved

An agentic SDLC starts from a problem many engineering leads now recognise. The team adopted AI coding tools, code arrives in minutes, and releases still ship no sooner than before. Pull requests wait for review, tests wait for someone to run them, and approvals wait for the next meeting. The tools work. The bottleneck simply moved to the stages nobody redesigned.

An agentic SDLC is a software delivery process where AI agents do the work at every stage, from planning to maintenance, each stage leaves a short written record that the next stage reads, and named people approve at the gates. The records become the audit trail, rules that must never be broken are enforced by automated checks rather than just written down, and the whole loop is measured with delivery numbers the team already trusts.

In the sections below, we look at what changes when delivery becomes an agentic SDLC loop, who does what at each of the six stages, why guardrails are only advice until something enforces them, how to measure an agentic SDLC, and how a mid-sized team can start with one team and one release.

What changes in an agentic SDLC

Anthropic's AI-native SDLC playbook describes the shift well: AI writes code at a speed that was unthinkable a year ago, yet the processes around the code have not changed at the same pace, so the bottleneck moves to plan, review and test, and deploy, which still run at human speed.

A traditional SDLC is a line of hand-offs: Plan to Design, Design to Build, Build to Test, Test to Deploy, Deploy to Maintain. Every hand-off is a wait, and much of the context lives in someone's head, a meeting or a chat thread. That was tolerable when people wrote code at a pace other people could review. It breaks when agents produce more changes in a morning than a reviewer can read in a day.

An agentic SDLC turns the line into a loop. Each stage ends with a short written record committed to version control, and the next stage, whether a person or an agent, begins by reading it. Anthropic's playbook lists these records (the intent, the spec, the plan, the diff and its tests, the pull request with its review findings, and the incident record) and notes that the chain of commits is also the audit trail: who asked for what, what the agent produced, and who approved it. In practice:

• A planning conversation ends with a one-page intent note, not a verbal agreement.
• A design session ends with a written specification that the build agent reads.
• A pull request review ends with written findings attached to the change.
• An incident closes with a short record that becomes the input for the next fix.

In an agentic SDLC, nothing important lives only in memory, and anyone can follow a change from idea to production by reading files. The business case for working this way, and what it means for team size, is in our article on why delivery is moving from headcount to intelligence. Here we stay with the mechanics of the AI software development lifecycle.

The six stages: who does what

Seeing delivery as a loop raises the practical question: at each stage, what do the agents do, and who signs off before work moves on? The table below is a tool-neutral starting point for a mid-sized team. Adapt the roles to the people you have; the structure of an agentic SDLC matters more than the job titles.

Three details hold an agentic SDLC together, and they are the ones teams most often skip.

A short project instructions file. Each Claude Code session begins with a fresh context window, so the team's conventions have to be written down where every agent will read them; Claude Code uses a file called CLAUDE.md, loaded at the start of every conversation, and can also read a repository's AGENTS.md in its place. AGENTS.md is a simple, open format for the same job, described as a README for agents and supported by many coding agents. Keep the file to a page of concrete rules: where the tests live, the naming conventions, the checks a change must pass. The Claude Code memory documentation puts it simply: the more specific and concise your instructions, the more consistently they are followed.

A written plan before any code. The spec says what to build; a short plan says how the agent intends to build it. In Anthropic's playbook, design review happens before any code is generated, when changing course is still a matter of editing a document. It is the cheapest gate in the agentic SDLC: reading a short plan is quick, and a misread requirement caught there costs far less than one caught in review.

A failing test first, and a small evaluation set. For bug fixes, the playbook says to write the failing test first, confirm it fails for the reason you expect, and only then ask the agent to make it pass. Separately, keep a small set of real tasks with known good outcomes and re-run them on a schedule and whenever prompts, models or agent configuration change; the playbook suggests collecting 20 to 50 real tasks from recent work for this continuous evaluation. The aim is not a huge regression suite but an early warning that a change has made the agents worse.

Guardrails: advice versus enforcement

The table says who approves. In an agentic SDLC, approval only means something if the rules behind it hold, and this is where many teams get caught out: a written rule is not the same as an enforced one.

The Claude Code documentation is explicit. Instruction files are treated as context, not enforced configuration, and to block an action regardless of what the agent decides, you use a hook instead. Hooks are user-defined handlers, such as shell commands, that run automatically at specific points in the agent's work, and a PreToolUse hook can block a tool call before it runs. So "never deploy to production without approval" written in an instructions file is advice. The same rule as a hook or a required pipeline check is a control. In an agentic SDLC, every rule whose breach would hurt (production deploys, secrets, deleting data) belongs in the second group.

The OWASP entry on Excessive Agency names the typical root causes of an AI system taking damaging actions: excessive functionality, excessive permissions and excessive autonomy. Its mitigations map directly onto delivery. Limit the permissions agents are granted to the minimum necessary, and use human-in-the-loop control to require a person to approve high-impact actions before they are taken. In an agentic SDLC, give each agent only the tools and access its stage needs, and put a named human approval in front of anything that reaches production. These human approval gates are not bureaucracy; they are where accountability sits.

Security belongs inside the loop too. NIST's Secure Software Development Framework (SP 800-218) notes that secure software development practices usually need to be added to each SDLC model, and describes a core set of practices that can be integrated into each SDLC implementation. An agentic SDLC is one more SDLC model, so the same applies. The difference is that many of those practices can now run as automated checks on every change rather than as a periodic review.

Finally, someone has to own the agentic SDLC loop: decide which rules are advice and which are enforced, watch the numbers, and change the process when they slip. That is the AI SDLC Owner role. Without an owner, the gates slowly decay back into habits.

Measure it with numbers you already trust

Guardrails decide what is allowed. Measurement tells you whether an agentic SDLC beats the process it replaced, and the numbers already exist. DORA divides its software delivery performance metrics into throughput and instability. Throughput is change lead time, deployment frequency and failed deployment recovery time. Instability is change fail rate and deployment rework rate.

These numbers matter more in an agentic SDLC. The DORA State of AI-assisted Software Development report finds that AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses, and that the greatest returns come from a focus on the underlying organizational system rather than the tools. A team with weak reviews and unreliable tests that adds agents will produce more changes, and more failed ones. A team with clear gates and written records will see the benefit. The metrics tell you which team you are.

Add two numbers from the stages themselves: first-pass merge rate (how many changes merge without a rework cycle) and defects caught before merge versus after release. Both come from your pull requests and bug tracker, so no new tooling is needed. Then follow one rule: measure a baseline before you change anything. Without one, you cannot tell whether the plan-before-code rule helped or the quarter was simply quieter.

How we run it ourselves, and where to start

We run an agentic SDLC on our own work. Our content pipeline runs on coding agents with a written project instructions file, automated checks that block a post from publishing when it fails them, parallel agent sessions in separate git worktrees, an independent fact-check before anything goes live, and a person who approves every publish. The main lesson matched the guardrails section: some rules that existed only as written instructions were occasionally skipped, so the ones that mattered became automated checks.

For a mid-sized team, the way into an agentic SDLC is not a company-wide programme. It is one team and one release:

1. Pick one team and one real release, small enough to finish and measure.
2. Write that team's instructions file: one page, specific.
3. Add a plan-before-code rule and one blocking check, such as no production deploy without a named approver.
4. Record the DORA baseline for that team.
5. Run the release, compare the numbers, and decide what to change next.

This is how our AI-assisted development and modernization work runs: one release at a time, with a person accountable for each one. The same release-by-release logic applies to older systems, and our guide to upgrading a legacy PHP app one release at a time shows it on a codebase nobody wants to touch.

If you want a second opinion on where an agentic SDLC would help your team, Book a free Next-Step Review. It is a 30-minute conversation about your delivery process, followed by a one-page brief within two working days. If one team and one measured release is the right first step, the brief will say so.

Frequently Asked Questions

What is an agentic SDLC?

An agentic SDLC is a software delivery process where AI agents do the work at every stage, from planning to maintenance, each stage leaves a short written record the next stage reads, and named people approve at the gates. The records form the audit trail, and rules that must never be broken are enforced by automated checks.

Is an agentic SDLC the same as AI-assisted software development?

No. AI-assisted development usually means a developer using an AI coding tool inside the existing process. An agentic SDLC, sometimes called an AI-native SDLC, redesigns the process itself: agents work between written records, and human approval gates decide what moves forward. Many teams have the first without the second, which is why their bottleneck moved rather than disappeared.

Do AI agents replace developers, testers or reviewers in an agentic SDLC?

No. Agents do the work between approvals, and named people stay accountable for every decision that needs judgment. Developers approve plans and review changes, testers own what counts as good enough, and a person approves every production deploy.

Do I need a specific AI coding tool for an agentic SDLC?

No. The model is tool-neutral. What matters is that your agents read a short instructions file and work inside automated checks that can block an action. Claude Code is one example; AGENTS.md is an open format that many agent tools support.

How do I enforce guardrails in an agentic SDLC instead of just writing instructions?

Use instructions for context and automated checks for rules that must hold. A hook or a required pipeline check can block an action regardless of what the agent decides, for example a production deploy without a named approver. OWASP recommends human-in-the-loop approval for high-impact actions.

What should we measure before changing our delivery process?

Start with DORA's five delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. Add first-pass merge rate and defects caught before merge versus after release. Record a baseline first, then compare after one release.