SDLC With AI Agents: Why Every Stage Still Applies

7 min read · Last updated: October 24, 2026

Yes. The software development lifecycle (SDLC) still applies when AI agents write the code. Agents speed up one stage, writing, and leave planning, review, testing, rollout and monitoring in place. Google's SRE team argues those later stages now need machine-speed controls, because human review cannot keep up with the volume of generated code.

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The research

• AI in SRE: How Google is Engineering the Future of Reliable Operations, Google SRE (page is undated, read October 24, 2026)

The independent synthesis

• Beyond Code Generation: Reliability, Verification, and Cost Economics in the Agentic Software Development Lifecycle, Happy Bhati, arXiv, September 4, 2026

Key takeaways

• Agents change who writes the code. They do not remove planning, review, testing, rollout or monitoring.
• Google's paper says line-by-line review leads to "reviewer fatigue and rubber-stamping" once code volume grows 4x to 10x.
• The fix it proposes: humans approve specs and policies before code is written, not every line after.
• The agent that writes the code must be isolated from the agent that tests it.
• Production actions go through one control plane with mandatory dry runs and a pause button.
• A 2026 synthesis on arXiv says the real metric is production-qualified change, not lines generated.

Why does an AI-written codebase still need a lifecycle?

Because writing code was only one step of delivering software. A kitchen that hires a much faster cook still needs someone to taste the food, check the temperature and decide what goes out to the table. Faster cooking just moves the bottleneck to those checks.

Software works the same way. An agent can open a pull request in minutes. Someone still has to decide if it is the right change, prove it works, ship it safely and notice when it breaks.

Google's paper, written by Ioannis Papapanagiotou, Stevan Malesevic, Chris Heiser and Ruslan Meshenberg, states the problem directly. AI-driven development is outpacing traditional site reliability engineering (SRE) practices, because code generation and deployment get faster while human review does not scale with machine-generated volume.

The paper also cites a goal of up to 4x developer productivity and a 4x to 10x increase in code volume. More code in means more review, testing and rollout work downstream, not less.

What actually changes in the SDLC when agents write the code?

The stages stay. What changes is who does the work in each one and how fast the checks must run. Writing gets cheap. Verification becomes the expensive stage, and the controls around it have to move from human speed to machine speed.

Here is the mapping, using only what the two sources say.

SDLC stage	Old assumption	What the sources propose
Plan	Spec is a loose ticket	Humans approve the specification before code is generated ("shift left")
Write	A human writes it	An agent writes it, inside a defined scope
Review	A human reads every line	Humans review design, intent and policy
Test	The author writes the tests	A separate agent or harness writes the tests
Deploy	Fixed soak time and canaries	Adaptive progressive rollouts with continuous production validation
Operate	Roll back to last known good	Feature flags, dynamic config and AI-assisted fix-forward

What is the Verification Tax?

The Verification Tax is a term from a 2026 arXiv synthesis by Happy Bhati. It names the cost of checking agent output: review, integration, testing, security and rework. The paper argues these costs, not code generation, now limit how much reliable software an engineering team ships.

The same paper describes an "Agentic SDLC Throughput Paradox". Field studies show gains in coding activity, but those gains weaken considerably before reliable software ships. It is a synthesis of existing research with no new experiments, and it credits every number to its original source.

It also proposes Production-Qualified Change (PQC), meaning change that is actually ready for production. The question shifts from "how much code can the agent write?" to "how much qualified value do we deliver per dollar, per reviewer-hour and per unit of operational risk?"

How does an agent-era SDLC work, step by step?

The steps below follow the controls in Google's paper, in the order a change moves through them. Treat them as a checklist for any team letting agents touch real code or real systems.

1. Approve the spec first. Google says humans should review designs, intent and policies, and approve specifications before code is generated.
2. Separate the writer from the checker. The paper says the agent that writes code must be isolated from the agent that writes tests or reviews output. This prevents cross-bias and catches untested requirements mechanically.
3. Give agents their own identity. Agents get distinct, strongly authenticated identities and on-demand permissions, not a developer's credentials. The paper calls this no ambient access.
4. Require a dry run. Systems exposed to agents must support a dry_run=true mode that predicts blast radius before any state change.
5. Add circuit breakers. Agent-specific rate limits and automatic breakers stop runaway loops, and every agent action must be highly interruptible.
6. Roll out progressively, then validate continuously. Fixed soak times become a bottleneck, so the paper proposes adaptive rollouts checked at machine speed.
7. Fix forward behind flags. Rolling back can remove later fixes or security patches, which the paper calls the Intervening Pull Request Problem. Feature flags and targeted patches avoid it.
8. Grade the agent every night. Google runs nightly evaluations that combine LLM-as-a-Judge grading with strict deterministic scoring. A mitigation counts only if it exactly matches the golden parameters.

How much autonomy should an agent get?

Start with human approval and widen autonomy only as the agent proves reliable. Google calls this progressive authorization. Its SRE paper defines five levels, L0 to L4, for operational work such as incident response. The scale is Google's, built for production operations, not for writing code.

Level	Name	Who acts
L0	Manual	Humans do everything
L1	Assisted	Automation investigates and suggests, humans approve and act
L2	Partial	The system acts, a human approves each plan
L3	High	Automation acts alone on bounded scenarios
L4	Full	The system handles the whole incident lifecycle

Google's own AI Operator runs at L2 for critical operations and L3 for minor incidents. A control plane called Actus sits between the agent and production. If an L3 request looks risky, Actus downgrades it to L2 and asks a human.

The paper says this split between reasoning (the agent) and execution (Actus) keeps production changes inside deterministic, human-controlled safety boundaries.

When should you apply this, and when is it too much?

Use the full lifecycle when an agent can change something that is hard to undo. That means production deploys, shared databases, payments, auth and anything customers see. Skip most of it for throwaway scripts, prototypes and code that never leaves your laptop.

Situation	Apply the full lifecycle?
Agent edits production services or infrastructure	Yes: dry run, own identity, circuit breaker
Agent opens pull requests on a shared codebase	Yes: spec approval and a separate test agent
Agent writes a one-off data script	Light: read the output, run it on a copy
Weekend prototype nobody depends on	No: keep it fast

There is a limit to what the sources prove. Google's results (a 10% cut in mean time to mitigate from incident hypotheses, about 44% from investigation dashboards) come from internal A/B tests, and the paper gives no raw data. Treat them as Google's reports, not independent benchmarks.

What does it look like in code?

Here is a small merge gate that encodes steps 1, 2 and 4. It is my own illustration of the ideas above, not code from Google, and the blast-radius limit of 20 files is a number I picked, so tune it to your repo.

type Change = {
  specApproved: boolean;
  authorAgent: string;
  testerAgent: string;
  dryRun: { ok: boolean; filesTouched: number };
};

const MAX_FILES = 20;

export function mergeBlockers(c: Change): string[] {
  const blockers: string[] = [];
  if (!c.specApproved) blockers.push("Spec not approved by a human");
  if (c.authorAgent === c.testerAgent) blockers.push("Writer and tester are the same agent");
  if (!c.dryRun.ok) blockers.push("Dry run failed");
  if (c.dryRun.filesTouched > MAX_FILES) blockers.push("Blast radius too large");
  return blockers;
}

An empty array means the change can move on to a progressive rollout. Any entry sends it back to a human.

In words, the whole flow looks like this:

Human approves spec → Agent A writes code → Agent B tests it in a separate harness → Dry run predicts blast radius → Gate passes → Small rollout behind a flag → Continuous validation → Fix forward, or switch the flag off.

The human sits at the start and at the policy level, not on every line. If you want a practical method for the review step itself, read our guide to reviewing AI-generated code without missing critical bugs.

Does this mean coding skills matter less?

No. When review moves to design and intent, you need more judgment, not less. Someone has to recognise a bad spec, a missing test case or a risky blast radius. We make that case in why coding fundamentals still matter in 2026 and in code was never the hard part.

FAQ

Does the SDLC still matter if AI agents write all the code?

Yes. Agents speed up the writing stage only. Planning, review, testing, deployment and operations still decide whether the software is reliable. Google's SRE paper argues these stages need automated, machine-speed controls because human review cannot scale with generated code volume.

What does Google recommend instead of line-by-line code review?

Google's paper says line-by-line review causes reviewer fatigue and rubber-stamping at high code volume. It recommends that humans review designs, intent and policies, and approve specifications before code is generated. It also wants the writing agent kept separate from the testing and reviewing agent.

What is a dry run for AI agents?

A dry run is a mode, written dry_run=true in Google's paper, where a system predicts the blast radius of an action without changing any state. Google requires systems exposed to agents to support it, so a risky action can be caught before it runs.

Is Google's research proof that agent-written code is reliable?

No. It describes controls Google uses and proposes, with figures from internal A/B tests and no raw data. The separate arXiv paper is a synthesis of existing research with no new experiments, and it says gains in coding activity weaken before reliable software ships.

Pick one agent workflow on your team this week and add a single gate from the list, starting with the dry run. Then browse the free tools on Art of Code, and compare how two popular agents handle this in our Cursor vs Claude Code comparison.

Written by Adithya Guttha, Founder of Art of Code.