The agentic SDLC is the software development lifecycle when AI agents plan, write, test and open pull requests, with engineers directing and approving the work. The stages you know are still there. What changes is who does each one, how fast changes arrive, and where things break.
In the classic SDLC a person writes the change, so the speed of writing caps everything after it. In the agentic SDLC an agent takes a ticket, reads the repo, writes the change and opens the PR, and your job moves from author to approver. Three things follow:
- The bottleneck moves downstream. Writing gets cheap; reviewing and running the result do not.
- The failures change shape. They are rarely syntax. They are changes that read correctly in the diff and behave badly under production load, data or permissions.
- One check at merge is not enough. Part of the judgment has to move earlier, into the editor, and part later, into runtime feeding back as a new check.
What is the agentic SDLC?
In the classic SDLC, a person writes the change, so the speed of writing caps the speed of everything after it. Review, testing and deploys were sized for that pace.
In the agentic SDLC, an agent takes a ticket, reads the repo, writes the change, runs the tests and opens the pull request. You decide what gets built and whether the result ships. Writing stops being the slow step. The work moves to judging changes you didn't write, at a rate you didn't plan for.
When a person wrote the change, the author knew what it touched. When an agent wrote it, nobody in the room necessarily does.
The stages of the agentic SDLC
Seven stages, run as a loop. The last one feeds the first, which is the part most teams skip.
| Stage | What happens | What goes wrong |
|---|---|---|
| Plan | The agent breaks a ticket into steps and proposes an approach. You approve the scope. | A plan that reads well and misses a constraint only your team knows, like a table that is hot at month end. |
| Write | The agent edits files, often several at once, across services. You steer when it drifts. | A correct-looking change to code it never needed to touch. |
| Review | A reviewer, human or bot, reads the diff. | The diff is reviewable, but its effect on production is not visible from the diff. |
| Merge | The change lands on main. You, or a policy, decide. | This is the last cheap place to stop a bad change, and approvals here get faster as volume grows. |
| Deploy | CI ships it. | An agent with deploy rights can ship without anyone watching the rollout. |
| Run | The change meets real traffic. | Failures show up as error rates and pages, often hours later and far from the change that caused them. |
| Learn | The incident becomes a fix and, ideally, a new check. | The lesson stays in a postmortem doc and the next agent makes the same change. |
How AI changes the SDLC: AI SDLC vs agentic SDLC
The two terms get used interchangeably, but they describe different setups.
An AI SDLC puts an assistant beside you. It completes lines, explains code and drafts tests while you type. You are still the author of every change, so the existing process holds: you know what you wrote, and review catches what you missed.
An agentic SDLC hands the agent a task and gets a pull request back. The agent picks the files, makes the edits and runs the checks without you in the loop for each step. Your role moves from author to approver.
That difference matters for reliability. AI in the SDLC as an assistant makes you faster. An AI driven SDLC where agents open PRs on their own makes changes arrive faster than people can reason about them, and the process has to account for that.
Where does the bottleneck move?
Agents make writing cheap. They do not make reviewing or running the result any cheaper, so the constraint moves downstream, to review and on-call.
The volume shift is already visible. On Alphabet's Q3 2024 earnings call, Sundar Pichai said that more than a quarter of all new code at Google is generated by AI, then reviewed and accepted by engineers (Alphabet investor relations). That is the AI SDLC at scale. The agentic version goes further: in September 2026, an automated report on GitHub's own gh-aw repository attributed about 95% of one week's 162 commits to automation. That is one repository's bot-generated report rather than an industry figure, but it shows what a team's history looks like once agents commit routinely.
Review capacity did not grow to match. A reviewer facing more PRs than they can read either slows everything down or approves faster, and approving faster is what usually happens. The failures that get through are rarely syntax. They are changes that look right in the diff and behave badly under production load, against production data, or with production permissions.
Where do reliability checks belong at each stage?
If the bottleneck is judging changes, the fix is to move part of that judgment earlier and part of it later, so the merge is not the only place anything gets checked. Each stage gets one check sized to what can go wrong there.
| Stage | What the agent does | What can go wrong | The check |
|---|---|---|---|
| Plan and write | Edits code in the editor or from a terminal | A change to a hot path, a dependency, or a resource it does not release | Scan the repo or the change in the editor, before a PR exists |
| Review | Opens the PR | The diff looks fine; its production effect is not visible | Score the PR for production reliability, not only for code style |
| Merge | Waits for approval | Fast approvals as volume grows | A merge gate with a threshold your team sets, advisory first |
| Deploy and run | Ships and meets traffic | Errors that show up hours later, far from the change | Tie runtime signals back to the change that caused them |
| Learn | Nothing, unless you make it | The same mistake in the next agent's PR | Turn each escalation into a check that runs on the next PR |
The merge gets the most attention because risk concentrates there: it is the last point where stopping a change costs a comment instead of an incident. But a gate on its own turns into a rubber stamp at high volume. The editor check and the feedback loop are what keep the gate from carrying everything. This is the same idea as shift left and shift right, applied to changes an agent wrote.
For the longer version of what a pre-merge check should look for, see pre-merge reliability analysis.
How do you measure an agentic SDLC?
Use a metric your team already trusts. DORA defines change fail rate as the share of deployments that require immediate intervention, such as a rollback or a hotfix. In an agentic SDLC, compute it twice: once for agent-written changes, once for human-written ones, in the same codebase over the same period.
The split is the useful part. One blended rate hides whether agents are making things better or worse. Two rates tell you whether to loosen the gate, tighten it, or leave it.
You need one thing in place first: a way to tell agent PRs apart. A label works, and so does the bot's author name. With a label called ai-authored, this lists last month's merged agent PRs with the GitHub CLI:
gh pr list --state merged --limit 500 \
--search "label:ai-authored merged:>=2026-09-01" \
--json number,title,mergedAtDrop label:ai-authored and add -label:ai-authored for the human-written set. Then count which of each set needed a revert, hotfix or incident. Reverts are the easiest proxy to start with:
git log --since=2026-09-01 --oneline --grep='^Revert'It is rough at first. A month of data is enough to see whether the two rates differ. For the full set of change-level metrics, see how to measure software change reliability.
Agentic software development tools by stage
Most teams already run something at each stage. The gap is usually the reliability layer between review and runtime.
| Stage | What the tool does | Examples |
|---|---|---|
| Plan and write | Coding agents that take a task and open a PR | Claude Code, Cursor, GitHub Copilot coding agent, OpenAI Codex |
| Review | Line-level review of the diff | CodeRabbit, GitHub Copilot code review, Qodo |
| Reliability | Scores what the change does to production before it merges | Tomosu |
| Run | Errors, traces and alerts after deploy | Datadog, Sentry, Grafana |
Security scanning is a separate concern with its own tools. It belongs in the pipeline too, but it answers a different question from "will this change hold up in production?"
How Tomosu helps
Tomosu sits in the reliability row of that table. It gives every repository and pull request a Production Reliability Index: in the editor through the VS Code plugin, inside agent sessions through the Tomosu MCP server, and on the pull request through the GitHub App, which posts the PRI delta. The Git Agent adds a PRI merge gate, advisory until you decide otherwise. Where runtime signals are connected, they count toward the score too.
See the seven sub-indexes behind the PRI for what the score is made of, or the scan guide for how a repository scan runs.
Key takeaways
- The agentic SDLC keeps the same stages; what changes is that an agent authors most of the work and you approve it.
- An AI SDLC makes you faster at writing. An agentic SDLC makes changes arrive faster than people can reason about them.
- The bottleneck moves from writing to review and on-call, and review capacity does not grow on its own.
- The failures that get through read correctly in the diff and fail under production load, data or permissions.
- One gate at merge becomes a rubber stamp at volume; pair it with a check in the editor and a loop back from runtime.
- Split DORA's change fail rate by author, agent versus human, in the same codebase. The split is what tells you anything.
- An agent cannot own an incident. The team that approved and merged the change does.
FAQ
What is the agentic SDLC?
The software development lifecycle when AI agents plan, write, test and open pull requests, with engineers directing and approving the work. The stages stay the same; the author of most changes does not.
How is the agentic SDLC different from the AI SDLC?
In an AI SDLC, an assistant helps you write code you still own. In an agentic SDLC, an agent produces the whole change and you approve it. The agentic development lifecycle moves your job from author to reviewer, which is why review capacity becomes the limit.
What are the risks of an agentic SDLC?
Changes that pass review but fail in production, approvals that get faster as volume grows, and agents with write or deploy access acting without a check in between. Most of these are production reliability problems rather than code-quality problems. For the runtime side, see what AI reliability means.
Who is accountable when an agent's change breaks production?
The team that approved and merged it. An agent cannot own an incident. That is the practical reason the approval step needs better information than a diff.
How do you measure an agentic SDLC?
Split DORA's change fail rate by author, agent versus human, in the same codebase. Add review time per PR if you suspect approvals are speeding up without the checks keeping pace.
Where should the first check go if we only add one?
At the pull request, scoring what the change does to production rather than how it reads. It is the last point where stopping a change costs a comment instead of an incident. Add the editor check next, so the gate is not carrying the whole load.
Agents will open the next pull request whether or not anything is checking it. Run a free Production Reliability Index scan to see where your repository stands before it lands.
