What is the agentic SDLC?
The agentic SDLC is the software development lifecycle run with coding agents as the main producers of work. An agent takes a ticket, writes a plan, edits files, runs the build and the tests, and opens a pull request. People set intent, approve the plan, review the change and own the release. The difference from AI-assisted development is that nobody is watching each keystroke, so control has to live in the handoffs between stages.
That reframes the CTO's job. You are no longer choosing an autocomplete tool. You are designing a pipeline where most artifacts are machine-written and the human role is approval. The questions become: which artifacts need a signature, who signs, and how you know the signatures mean something.
What changes at each stage?
The stages are familiar. The split between agent and human is new. This is the default split I would start a team on, then loosen per task type as the evidence comes in.
| Stage | What the agent does | Where the human stays | Artifact to keep |
|---|---|---|---|
| Spec | Drafts requirements and acceptance criteria from a ticket or prompt | Approves intent, scope and what done means | Spec file in the repo |
| Plan | Proposes a design and a task list, names files and interfaces it will touch | Approves the approach for anything beyond a small fix | Plan and task list |
| Code | Implements tasks, runs commands, iterates on compiler and linter output | Interrupts or redirects; usually not watching each step | Branch with small commits |
| Test | Writes and runs tests, including checks derived from the spec | Checks that tests encode the spec, not the implementation | Test results attached to the change |
| Review | First-pass AI review comments; summarises the change | Owns the merge decision | Pull request with spec link |
| Deploy | Prepares release notes, runs pipelines, watches canaries | Owns the release decision and rollback call | Release record |
| Operate | Triages alerts, proposes fixes, opens follow-up tickets | Approves any production change; owns incidents | Incident and fix records |
The right-hand column matters as much as the middle ones. Each stage should leave a file in the repository or a record on the pull request, so the next agent, the reviewer and the auditor can see what was intended and what was checked. Agents are stateless between sessions; your repository is their memory.
Why does the spec become the main control point?
Intent is cheapest to correct before code exists. A one-page spec with acceptance criteria takes minutes to review. The same mistake discovered in a large agent-written diff costs a review, a rejection, a second agent run and a second review. Moving the main checkpoint upstream is the single biggest lever on review cost.
Tooling has caught up with the idea. GitHub released Spec Kit in September 2025, which adds specify, plan and tasks steps to agents such as Copilot, Claude Code and Gemini CLI, with an explicit checkpoint between each phase. AWS built the same flow into Kiro, which writes requirements, a design and a task list before coding and checks the result with property-based tests derived from the spec.
The rule I would use: require a spec above a size or risk threshold, such as anything that changes a public interface, a data model or a security boundary. Below that line, a good ticket is the spec.
Where must humans stay in the loop?
Sort decisions by two properties: how hard the result is to reverse, and how far a mistake spreads. A test added to a branch is reversible and contained. A schema migration on a shared database is neither. Human approval belongs where both are high, and agents can run with lighter review where both are low.
- Always human: merging to the main branch, schema and data migrations, authentication, authorization and payment code, infrastructure and IAM changes, production releases, and any action against production data.
- Human approves the plan, agent executes: features across several modules, refactors, and migrations between frameworks or languages.
- Agent runs, human samples: dependency bumps, test additions, lint and type fixes, documentation, and changes behind a feature flag that defaults off.
Treat the middle and bottom tiers as earned, per task type. An agent that has produced clean dependency bumps for a quarter can move to sampled review for that task. That says nothing about its next refactor. For the cost side of that trade, see what autonomy actually costs.
Why does review become the bottleneck?
Agents raise the volume of changes faster than they raise the number of people who can judge them. The 2025 DORA report on AI-assisted software development, a survey of nearly 5,000 technology professionals, called AI an amplifier: it magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones (InfoQ summary). It found that AI adoption now correlates with higher delivery throughput, while delivery instability keeps rising.
The mechanism is simple. When writing a change is nearly free, every unclear requirement becomes a pull request someone has to read. Three responses help. Keep changes small, so review stays tractable. Use AI review as a first pass that flags issues, never as the merge decision. And give reviewers the spec, so they review against intent rather than reconstructing it from the diff.
Which metrics tell you the agentic SDLC is working?
Self-reported speed is the wrong evidence. In METR's randomised trial of experienced open-source developers in early 2025, developers expected AI to make them 24% faster, believed afterwards it had made them 20% faster, and were in fact 19% slower (METR, July 2025). METR's February 2026 follow-up said developers are likely faster now, but that its own measurement had become unreliable, partly because many developers would no longer agree to work without AI (METR, February 2026). If careful researchers struggle to measure speedup per task, an internal survey will not do better.
Measure outcomes at the system level, split by whether an agent authored the change:
| Metric | What it tells you | How it misleads |
|---|---|---|
| Lead time for changes, split by author type | Shows whether agent work reaches users faster end to end, not just whether code is written faster | Faster coding with a growing review queue leaves lead time flat |
| Change failure rate, split by author type | DORA 2025 found AI adoption now improves throughput while delivery instability keeps rising | Counting only incidents misses quiet reverts and hotfixes |
| Review time and reviewer load per change | Review is where the human cost moved; this is the capacity constraint | Rubber-stamp reviews look fast and hide risk |
| Rework within 30 days | Catches agent changes that passed review but had to be rewritten | Needs commit-level attribution to be meaningful |
| Rejections at plan stage versus at pull request | A high rejection rate at plan stage is cheap; at PR stage it is expensive | Zero rejections usually means nobody reads the plans |
| Cost per merged change | Token and seat spend divided by merged, non-reverted changes | Per-seat price hides model mix and retry loops |
The attribution is the hard part. Tag agent-authored commits and pull requests at creation, through commit trailers or bot accounts, or none of these splits are possible later. For the wider metrics debate, see engineering metrics beyond DORA and AI team metrics.
How do the tools map to the lifecycle?
Vendors differ less in model quality than in which stage they make easiest to control. Our partner site keeps scored reviews of each.
| Lifecycle emphasis | Examples | Review |
|---|---|---|
| Spec and plan as first-class artifacts | Kiro (requirements, design, tasks); GitHub Spec Kit on top of other agents | Read (partner site We The Flywheel) |
| Editor-centred coding with diff review | Cursor; Devin Desktop (formerly Windsurf) | Read (partner site We The Flywheel) |
| Step-approval agent in existing editors and CI | Cline (VS Code, JetBrains, CLI, SDK) | Read (partner site We The Flywheel) |
| Background agents with admin-set autonomy | Factory Droids | Read (partner site We The Flywheel) |
| Long-running agents on their own machines | Amp orbs | Read (partner site We The Flywheel) |
Expect churn. In 2026 alone, Windsurf became Devin Desktop (Cognition, June 2026), SpaceX completed its acquisition of Cursor, and Google announced that Jules shuts down on 31 December 2026 (Jules changelog). Keep the lifecycle artifacts, meaning specs, plans, rules files and test suites, in your repository in plain formats, so switching agents costs a migration of configuration rather than of process.
Related questions
Frequently asked questions
What is the agentic SDLC?
The agentic software development lifecycle is the usual sequence of spec, plan, code, review, test, deploy and operate, with AI agents producing most of the artifacts at each stage. Humans move from writing to approving: they set intent, approve specs and plans, review changes and own the release decision. The stages stay; the division of labour changes.
How is the agentic SDLC different from AI-assisted development?
In AI-assisted development a person writes the code and an assistant suggests completions or answers questions. In an agentic lifecycle an agent takes a task, plans it, edits many files, runs commands and tests, and opens a pull request, often without a person watching each step. That shift moves the control problem from the keyboard to the checkpoints between stages.
Where should humans stay in the loop?
At every point where a mistake is expensive to reverse or the blast radius is large: approving the spec and plan, merging to the main branch, changing schemas, authentication or payment code, touching production data, and releasing to users. Low-risk, easily reverted work such as dependency bumps or test additions can run with lighter review once the agent has a track record on that task type.
What metrics should a CTO track for agentic development?
Keep the DORA delivery metrics (lead time, deployment frequency, change failure rate, time to restore) and split them by agent-authored and human-authored changes. Add review time per change, rework within 30 days, escaped defects and cost per merged change. Avoid self-reported speedup surveys as the main evidence; controlled studies show they are unreliable.
Does spec-driven development slow agents down?
For small, well-understood fixes, yes: writing and approving a spec can cost more than the change. For features that touch several modules or carry business rules, a spec usually saves time, because review happens on a short document before the agent writes hundreds of lines in the wrong direction. A practical rule is to require a spec above a size or risk threshold, not for every task.
Sources
- GitHub, Spec-driven development with AI: get started with a new open source toolkit (2 September 2025).
- InfoQ, DORA report finds AI is an amplifier in software development (29 September 2025).
- METR, Measuring the impact of early-2025 AI on experienced open-source developer productivity (10 July 2025) and We are changing our developer productivity experiment design (24 February 2026).
- Kiro, Pricing and models; SiliconANGLE, Kiro general availability (17 November 2025).
- Cognition, Windsurf is now Devin Desktop (2 June 2026); Google, Jules turndown (29 October 2026).