AI SDLC: what it is, how it works and how it changes the traditional SDLC

In short: an AI SDLC is the software development lifecycle run with AI agents doing most of the coding, testing and documentation, while people own the intent, the specification and the final review. The main effect is not that everything gets faster. It is that the slow, expensive step moves from writing code to deciding what to build and checking what the agents produced.

This guide explains what an AI SDLC is, how it works phase by phase, what changes compared with the traditional SDLC, what the research actually says about productivity, how each role on the team changes, and how a small or mid-sized team can adopt it in 90 days without creating a mess of unreviewed code.

It is written for CTOs, engineering leads and founders who already use tools like Claude Code, Cursor or GitHub Copilot and want a working process around them, not another list of tools. Most of what ranks for this topic today is a vendor playbook. This one is not selling you a platform, and it includes the results that did not go well.

‍

Key takeaways

• An AI SDLC keeps the familiar phases (plan, design, build, test, release, maintain) but changes who does the work inside each one. Agents draft, people decide.

• The bottleneck moves. Building gets cheap, so specifying and reviewing become the scarce, valuable work.

• The evidence is mixed. 90% of developers now use AI (DORA 2025), yet a controlled study found experienced developers 19% slower with AI in early 2025, and teams with heavy AI use saw review time rise 91%.

• The teams that gain are the ones with clear specs, strong tests and strict review gates. AI amplifies the process you already have, good or bad.

• Roles shift: developers spend more time reviewing and specifying, tech leads own the rules agents follow, QA moves from manual testing to test design.

• Governance is not optional: approval gates, audit trails, secret handling and the EU AI Act's AI literacy duty all apply.

• Start small: one team, one type of work, three human gates, and measure lead time, review time and rework before and after.

‍

What is an AI SDLC?

An AI SDLC (AI software development lifecycle) is a way of building software where AI agents perform a large share of the work in every phase of the lifecycle, and human engineers set the direction, define the rules and approve the results. It sits on top of the same phases teams have used for decades. What changes is the division of labour inside them.

The term gets used for three different things, which is why search results feel confusing. The first is AI-assisted development: a developer writes code with autocomplete or a chat assistant at their side. The lifecycle stays the same, the typing gets faster. The second is the AI-native or agentic SDLC: agents take whole tasks from a written spec, write the code and tests, open a pull request and wait for review. Here the lifecycle itself changes, because the unit of work becomes a spec, not a ticket. The third meaning is the lifecycle for building AI systems themselves, with data collection, model training and evaluation. That is really an ML lifecycle, and it is a different subject.

This article is about the second meaning, because that is where the real change is happening in 2026. It also helps to separate the SDLC from the product lifecycle around it. The SDLC covers how software gets built, tested and shipped. The product development lifecycle covers why: discovery, validation, prioritisation and learning after launch. We wrote a separate guide to the AI PDLC and how it works; the AI SDLC is the engineering engine inside it.

‍

Traditional SDLC vs AI SDLC: what changes in each phase

The phases do not disappear. Requirements still need to be clear, code still needs to be tested, releases still need to be safe. What changes is who does the work in each phase, what the main artifact is, and where a human has to step in.

‍

‍

The easiest way to see the difference is to follow one feature. In a traditional setup, a product manager writes a ticket, a developer estimates it, builds it over three or four days, writes some tests, opens a pull request, and a colleague reviews it a day later. Most of the calendar time sits in the build.

In an AI SDLC, the same feature starts as a short written spec: what it should do, what it must not do, how it will be tested, and which parts of the codebase it touches. An agent turns the spec into a plan, a human approves the plan, the agent writes the code and the tests, and the pull request is ready within hours. Then the time goes somewhere else. Someone has to read a large diff carefully, check the edge cases the spec missed, and decide whether the change is safe. The build shrank. The thinking before it and the checking after it grew.

That is the core shift, and it explains most of what follows. If your team writes vague tickets and reviews lightly, an AI SDLC produces more code of uncertain quality, faster. If your team writes clear specs and reviews properly, it produces more good software with the same people.

‍

How an AI SDLC works, step by step

An AI SDLC works as a loop of written artifacts. Each step produces a document or a change that the next step reads, and three of the steps are human gates where nothing moves forward without a person signing off.

‍

‍

1. Intent

Every piece of work starts with a short statement of intent: the problem, the user, the outcome and how you will know it worked. This is the input from the product side, and it is usually a few paragraphs, not a long document. Agents cannot guess intent. When it is missing, they fill the gap with plausible assumptions, and that is where most AI-built features go wrong.

2. Spec and plan (gate 1)

The intent becomes a specification: behaviour, constraints, acceptance criteria, data involved, and what is out of scope. An agent can draft the spec and a technical plan from the intent and the existing codebase. A human then approves both. This is the first gate, and it is the cheapest place to catch a mistake. A wrong assumption fixed here costs minutes; the same mistake found in review costs hours. We cover how to write these in our guide to specification driven development.

3. Build and verify

Agents write the code, the tests and the documentation from the approved plan, often several tasks in parallel. Before a human ever sees the result, automated checks run: tests, type checks, linting, security scans and any project rules the agents are required to follow. These rules live in the repository itself, in files that tell the agents how this codebase works, which patterns to use and what never to do. Good teams treat those rule files as seriously as the code.

4. Review (gate 2)

A human reviews the pull request against the spec. This is now the most expensive step in the loop, and it deserves the most care. The reviewer checks whether the change does what the spec says, whether it does anything the spec did not ask for, and whether it fits the architecture. Small, well-scoped pull requests make this possible. Huge agent-generated diffs make it impossible, which is why scoping the spec well matters so much.

5. Release (gate 3)

Releases follow the same safety practices as before: staged rollouts, feature flags, monitoring and a quick way back. The difference is volume. When a team ships more changes per week, the release process has to be automated and boring, and a human still decides when risky changes go live.

6. Observe and feed back

Production behaviour, incidents and user feedback become the next round of intent. The step most teams skip is the important one: when an agent makes a mistake that review catches, the lesson is written into the project rules so the agents do not repeat it. Over time, the rule files become the team's memory, and the error rate drops.

‍

If you want a starting format for the intent and spec steps, our free AI product requirements template gives you the sections agents need to work from, including acceptance criteria and out-of-scope rules.

‍

What the research says about AI SDLC productivity

The honest answer is that AI makes good engineering teams faster and struggling teams busier. The research from 2025 and 2026 is consistent on that point, even where the headline numbers seem to disagree.

Adoption is no longer the question. Google's 2025 DORA report, based on about 5,000 technology professionals, found 90% of respondents using AI at work, with over 80% reporting higher productivity. Its main conclusion is that AI acts as an amplifier: it magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones.

Measured speed is less clear. In a randomised trial published in July 2025, METR found that experienced open-source developers were 19% slower when using AI tools on their own repositories, while believing they had been 20% faster. METR's February 2026 follow-up with newer tools pointed to a speed-up instead, though not a statistically significant one, and METR itself now calls the 2025 result out of date. The lesson is not that AI slows people down. It is that perceived speed and real speed can be very different, so you have to measure.

The clearest picture of where the time goes comes from Faros AI's analysis of more than 10,000 developers. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, but pull request review time rose 91% and pull requests got 154% larger. More output, and a review queue that becomes the new constraint.

Trust tracks the same pattern. In the Stack Overflow 2025 Developer Survey, 84% of developers use or plan to use AI tools, yet more developers distrust the accuracy of AI output (46%) than trust it (33%), and 66% name "solutions that are almost right, but not quite" as their top frustration. That is exactly why an AI SDLC puts its human effort into specs and review.

‍

How roles change in an AI SDLC

Nobody's job disappears, but almost everyone's week looks different. The pattern is the same for each role: less producing, more deciding and checking.

• Product manager: writes sharper intent and acceptance criteria, because agents act on exactly what is written. Vague requirements now cost more, not less.

• Developer: spends less time typing and more time writing specs, steering agents, reviewing diffs and handling the hard parts agents get wrong. The skill that matters most is reading code critically.

• Tech lead or architect: owns the rule files, the architecture boundaries and the review standards that agents and humans both follow. This role becomes more important, not less.

• QA engineer: moves from manual test execution to test design, so agents generate tests against well-chosen scenarios and edge cases.

• Designer: hands over design systems and components that agents can reuse consistently, instead of one-off screens.

• DevOps or platform engineer: builds the pipelines, permissions and sandboxes that let agents work safely, and keeps the release process automated.

The practical consequence for hiring is that seniority matters more. One senior engineer with good judgement can now direct a lot of agent output; a team of juniors without strong review will ship more defects faster.

‍

The main AI SDLC frameworks compared

Several vendors have published their own version of the AI SDLC. They describe the same shift in different words, and it helps to know how they map onto each other.

Anthropic's AI-native SDLC playbook is the most detailed. It frames the lifecycle as a chain of committed files, from an intent document to a spec, a plan, a pull request and back, with governance built into repository rules and hooks. It is tied closely to Claude Code.

AWS describes an AI-Driven Development Life Cycle (AI-DLC) in three phases, inception, construction and operations, with short work cycles it calls bolts replacing sprints. Atlassian's AI SDLC transformation playbook focuses on the organisational side: measurement, platform investment and change management.

Spec-driven development is the thread that runs through all of them: the spec becomes the main artifact and code is generated from it. Thoughtworks placed spec-driven development in the "Assess" ring of its Technology Radar, a sensible signal that the idea is promising but the tooling is still young. Our view is that you do not need to adopt any vendor's framework wholesale. The three-gate loop above captures what they agree on, and it works with any of the major coding agents.

‍

Governance, security and EU rules

An AI SDLC needs explicit guardrails, because agents act quickly and do not ask permission unless you make them. Four areas matter most.

First, approval gates. Agents should never merge to the main branch, change infrastructure or touch production data without a human approving it. Configure this in the tools, do not rely on habit.

Second, secrets and data. Keep credentials out of anything an agent can read, run agents in sandboxes with limited permissions, and know where your code and prompts are processed. For European teams that includes checking the data-processing terms of every AI vendor under the GDPR.

Third, prompt injection. Agents that read issues, web pages or third-party files can be manipulated by text hidden in that content. Treat external input as untrusted, and restrict what an agent can do after reading it.

Fourth, the EU AI Act. Coding assistants are not high-risk systems under the Act, but Article 4 has required companies since February 2025 to ensure their staff have sufficient AI literacy for the systems they use. In practice that means a short, documented training on how your team uses agents, their limits and your review rules. Our guide to what the EU AI Act means for SMEs covers the wider picture.

‍

What an AI SDLC costs and how to measure it

The direct cost of an AI SDLC is small compared with salaries. Seat plans for the main coding agents run from roughly €20 to a few hundred euros per developer per month in 2026, depending on how heavily the team uses autonomous agents, and token-based billing can add more on intensive days. Check current vendor pricing, because it changes often.

The real cost sits in review time, rework and the setup work: writing rule files, building test coverage and tightening the pipeline. That is why the return depends far more on process than on the tool you pick.

Measure before and after on one team, using the metrics you probably already know plus a few AI-specific ones:

• Lead time from approved spec to production.

• Review time per pull request, and pull request size.

• Change failure rate and time to restore service.

• Rework rate: how often merged work has to be fixed within two weeks.

• Tool spend per merged pull request.

A simple worked example shows why this matters. Suppose a feature used to take an engineer 8 days and now takes 3 days of agent-driven build plus 2 extra days of spec and review. At a fully loaded cost of €600 per engineer-day in the Netherlands, that is €4,800 before and €3,000 after, plus a few euros of tool usage. The saving is real, but only if those 2 days of review actually happen. Skip them and the rework rate eats the gain within a quarter.

‍

How we run the AI SDLC at Codelevate

We build client software this way every day, so this section describes practice, not theory. Every project runs on the three-gate loop. A person approves the spec and plan, a person reviews every pull request against the spec, and a person decides on each release.

Our website builds are a good example of how the agent roles work. They run through four specialised agents in sequence: one turns the design or brief into a precise build spec, one checks every value against the client's design system before anything is built, one does the build, and one audits the result and returns a pass or a numbered list of failures. Two of those steps are hard gates. Nothing moves forward until they pass.

The part that makes the biggest difference over time is the memory. When review catches a mistake, we write it down as a rule in the project's knowledge base, and every agent reads those rules before its next task. The same error should only ever happen once. We also connect agents directly to the tools a project uses, such as the CMS, through MCP connectors, so they work on the real system under real permissions rather than on copied files.

What we have learned is mostly about discipline. The tools change every few months. The habits that make an AI SDLC work stay the same: write the spec down, keep changes small, review everything, and turn every mistake into a rule.

‍

How to adopt an AI SDLC in 90 days

You do not need a transformation programme. A focused 90-day pilot with one team tells you more than any playbook.

Days 1 to 30: set the foundation. Pick one team and one type of work, such as internal tools or well-tested backend features. Write the first version of your repository rules, agree the three gates, and record your baseline metrics. Run a short AI literacy session and document it.

Days 31 to 60: run the loop. Every task in scope starts as a written intent and an approved spec. Keep pull requests small. Hold a short weekly review of what the agents got wrong and add each lesson to the rules.

Days 61 to 90: measure and decide. Compare lead time, review time, rework and change failure rate with the baseline. If the numbers improved without quality dropping, extend the loop to a second team or a riskier type of work. If they did not, the problem is almost always spec quality or review capacity, not the tool.

‍

When an AI SDLC is the wrong choice

An AI SDLC is not right for every team or every codebase, and it is worth being clear about where it struggles.

• Codebases with little test coverage: agents cannot be verified automatically, so every change needs heavy manual review and the gains disappear.

• Teams without senior reviewers: more output with weak review simply creates more defects and technical debt.

• Safety-critical or heavily regulated changes, such as medical devices or payment cores, where every line needs formal verification and traceability that agent workflows are not yet built for.

• Work that is mostly discovery: if you do not yet know what to build, start with the product loop, not with agents writing code.

‍

The bottom line

An AI SDLC keeps the shape of the traditional lifecycle and changes the economics inside it. Building becomes cheap, so the value moves to clear intent, precise specs and careful review. The research is consistent once you read past the headlines: AI amplifies the process you have. Teams with good specs, solid tests and strict gates ship more good software. Teams without them ship more problems, faster. Start with one team, three human gates and honest metrics, and let the numbers decide how far you take it.

‍

‍

Free download: our AI product requirements template gives your team the spec format agents work best from. If you would rather see an AI SDLC working on your own backlog first, we run one sprint with your team using this exact loop, and if the result is not up to your standard, you do not pay for it. Book a call with Nicko to plan it, or read how a dedicated product team from Codelevate works.

‍