Agentic Software Development Lifecycle Explained

The agentic software development lifecycle (agentic SDLC, or ADLC) keeps the stages every developer already knows: planning, coding, testing, review, deployment, monitoring. What changes is who does the work inside each stage. Instead of a human writing the code while a tool autocompletes suggestions, an autonomous agent takes a goal, plans its own steps, executes them, checks its own output, and hands back a finished result. A human sets the direction and reviews what comes out the other end.

That distinction matters more than it sounds. A code-completion tool like a code-hosting platform's assistant waits for a prompt, gives a suggestion, and stops. A human approves or rejects every line. An agent works differently: give it "build a password reset flow," and it can plan the task, write the code across multiple files, pick the dependencies, run the tests, and open a pull request, all before anyone opens an IDE. Deloitte's framing captures it well: agentic systems "can complete complex tasks and meet objectives with little or no human supervision," which puts them in a different category from chatbots and copilots entirely.

One naming note worth clearing up early: some vendors, including IBM and Salesforce, use "Agent Development Lifecycle" to describe building and operating AI agents themselves. That's a different subject. This is about agents building software, not the reverse.

Right now, three delivery models run side by side across the industry. Traditional SDLC has humans at every stage, with tools that assist but don't act. AI-assisted development has humans directing the work while AI speeds up individual steps. The agentic SDLC has agents executing end-to-end tasks while humans set direction and review outcomes. None of these has fully replaced the others yet, and understanding which one a team is actually operating in is the first step to using any of it well.

How the agentic SDLC evolved and where it stands in 2026

A 2026 preprint on agentic software lays out three stages of evolution, and they're worth knowing because they explain why some parts of the SDLC feel more "agentic" than others right now.

Stage I, roughly 2023 to 2025, was tool-augmented: agents worked as assistants inside workflows humans still ran. This is where the breakthrough code generation for well-scoped tasks happened. Humans still broke problems down and checked the answers.

Stage II, roughly 2025 to 2027, is single-task autonomous. Agents start owning complete tasks from spec to deployment. Systems like Devin and OpenHands showed this was possible: navigating a codebase, implementing a feature, submitting a pull request, without a human doing the intermediate steps. The human job shifts from doing the work to specifying and verifying it.

Stage III, roughly 2026 to 2029, is multi-agent teams. Specialized agents coordinate the way a human engineering org does. A "product manager agent" translates business requirements into technical specs, other agents build, other agents test. That's the direction things are heading, but it's not where most teams sit today.

Most professional organizations are somewhere between Stage I and Stage II. Coverage isn't even across the SDLC. Coding and testing are further along; planning and analysis lag behind. That unevenness is the whole story of this article, stage by stage.

The adoption numbers back up how fast this moved. Per the DORA 2025 report, 90% of software development professionals now use AI tools. This isn't early-adopter territory anymore. Gartner projects that 33% of enterprise software applications will include agentic AI by 2028, up from less than 1% in 2024. That gap, from under 1% to a third of all enterprise applications, is the transition period every team is living through right now. Forrester's The State Of Agentic Software Development, 2026 states that generative AI has stopped being just a way to write code faster. It's reshaping how software gets planned, built, tested, and delivered.

Three structural shifts define what's actually different. The unit of work shrinks from sprints to tasks, since agents finish work in minutes or hours and human review happens at the boundary of that work, not in the middle of it. The developer's job shifts from producing to orchestrating, meaning less hands-on-keyboard implementation and more directing, reviewing, and governing. And the metrics that matter change too: instead of tracking process (story points, velocity), teams start tracking agent acceptance rate, escalation quality, and how much supervision the agents actually need. Keep those three in mind. They show up again at every stage below.

Stage 1: Requirements and guardrails: translating intent into instructions agents can act on safely

Here's the problem with agents at the requirements stage: they execute literally. A vague instruction doesn't produce a vague result, it produces a confident, wrong result. Ambiguity here doesn't stay contained. It compounds through planning, coding, testing, everything downstream.

What agents are good at in this stage:

• Turning messy inputs (meeting notes, user interviews, rough specs) into clearer requirements and functional specs
• Producing rapid prototypes straight from that clarified spec
• Shortening the path from concept to buildable design, which is widely cited as an early leverage point for agentic tools

A preview of where this is heading: a "product manager agent" pattern, part of the Stage III model, autonomously translates business requirements into technical specs. That's not standard practice yet, but it's the direction.

What still has to come from a human? Two things, mainly. First, writing requirements that are actually testable and specific, not loose feature descriptions. That's the brief the agent will act on, and a bad brief is where wrong-but-confident software gets born. Second, setting guardrails: the boundaries an agent isn't allowed to cross. Blocking risky prompts. Rules around data exposure. Constraints on scope. Everything downstream depends on getting this stage right, since it is the one phase where human judgment can't be handed off without the risk compounding.

Early accounts from practitioners suggest that work once measured in months, translating requirements through scenario analysis, refinement, mapping to architecture, and UML diagrams, can now be scaffolded by an agent in a fraction of the time. The claim being made here does not assert that the quality is equivalent. It's a claim about how much the speed of the first draft has changed.

Setting guardrails deserves to be treated as its own skill, not a compliance checkbox. It's the difference between an effective agent orchestrator and a developer who just got very fast, very wrong software.

Stage 2: Architecture and planning: what agents can scaffold and what still requires a senior engineer

Agents can propose a system architecture once requirements are in place: breaking down components, suggesting dependencies, drawing service boundaries. They can generate scaffolds and blueprints, and they can scan an existing codebase to flag architectural problems before anyone writes a line of implementation.

Where does this break down? A few places.

Agents optimize for patterns they've already seen. Novel architectural constraints, internal politics about who owns what system, non-functional requirements like latency targets or compliance mandates: these need human judgment, because there's no training pattern that captures "our compliance team will reject this in review."

Dependency selection carries a specific, measurable risk: agents can hallucinate packages that don't exist. That sounds like a small bug. It isn't; it's a security hole waiting to happen, and it comes up again in the review and deployment stage below.

Even the frameworks for doing this well are still being worked out. One academic paper proposes a six-layer reference architecture just for organizing agentic software engineering systems. That's worth sitting with for a second: the industry is still standardizing how to think about agentic architecture at the same time it's asking agents to do architecture. The technology itself isn't at fault here; this is an honest read of where things stand.

The human role here looks more like a principal engineer than a business analyst. Review the architecture for organizational fit. Validate the dependencies. Set the guardrails that the coding agents will operate inside once they start executing. PwC's tier framework is a useful way to see where any given org sits: "Pioneer" organizations (those with six or more SDLC stages AI-augmented) treat architecture as a genuine human-agent collaboration. Most organizations are still "Experimenters" or "Integrators," where planning stays largely human-led. In other words: architecture is the stage where the agentic SDLC is least mature, even as coding races ahead.

"more throughput"

This is where agents are furthest along. Give an agent a ticket, and it can read the codebase, write the implementation across multiple files, run an initial test pass, fix what fails, and open a pull request. Autonomously, start to finish.

The scale is already large. AI-authored code made up 26.9% of all production code in early 2026, up from 22% the quarter before. The pace shown here is quarter-over-quarter acceleration rather than a slow creep.

The individual productivity numbers back up why teams keep adopting this. Developers using AI coding tools save an average of 3.6 hours a week (about 187 hours a year), based on a sample of more than 135,000 developers from DX. Daily AI users merge roughly 60% more pull requests than light users. A field experiment across Microsoft, Accenture, and a Fortune 100 company found developers completing 26% more tasks on average with AI coding tools. Individually, this works.

So why doesn't it always add up at the team level? This is the part worth sitting with. Faros AI studied more than 10,000 developers across 1,255 teams in June 2025. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. Pull request size grew 154%. And then: review time went up 91%, bugs went up 9%, and overall delivery throughput did not improve proportionally.

Why would faster code production not translate to faster delivery? Because writing and testing code is only about 25 to 35% of the total SDLC, according to Bain's analysis. Speed up a third of the pipeline and leave the rest untouched, and the whole system doesn't move much faster. It just backs up somewhere else.

The DORA 2025 report names the mechanism directly: time saved writing code often gets re-spent auditing it. Call it the verification tax. The time didn't disappear, it moved from the "write" column to the "review" column.

There's a quality cost showing up too. CodeRabbit's December 2025 report found AI-coauthored pull requests carry about 1.7 times more issues overall, with readability problems more than three times higher and security issues up to 2.74 times higher.

So agents at the coding stage are genuinely transformative for one developer working alone. Whether that gain survives at the team level depends almost entirely on what happens next, at review. Which is where things either scale or fall apart.

Stage 4: Testing: where agents catch defects earlier and why test coverage alone does not equal quality

Agents earn their keep here in a few concrete ways. They generate test cases straight from requirements and code, catching edge cases a developer might not think to check. They surface defects earlier, before a human reviewer ever sees the code. And they can run full debugging loops on their own: take a failing test or bug report, read the stack trace, trace the execution path, form a hypothesis, write a fix, rerun, repeat until it passes.

The debugging loop is a useful illustration of what agents can replace: narrowing down the issue, digging through logs, tweaking scripts, trying again, a cycle that has historically consumed a significant share of developer time. Agents that read logs and surface the specific error can meaningfully reduce that cycle.

The quality data is genuinely encouraging. The Qodo State of AI Code Quality 2025 report found that using AI in code review pushed quality improvement rates up to 81%, from 55% without it. An Atlassian RovoDev study from 2026 found that 38.7% of comments left by AI agents in code review actually led to a code fix, not just a suggestion that got ignored.

But there's an honest counterweight here, and it matters. A 2025 randomized controlled trial from METR found a 19% net slowdown for experienced developers on complex tasks, despite those same developers feeling like they were faster. Reviewing AI-generated code, it turns out, often takes longer than just writing it yourself. That's a real finding, not a footnote. The good news: an early 2026 follow-up on the same developers showed an 18% speedup, suggesting the initial slowdown was a learning curve, not a permanent ceiling. Teams adjust. It just takes time.

High test coverage can hide subtler problems. An agent can generate a test suite that hits every line of code and still be testing the wrong thing, because the same system that wrote the code also wrote the tests checking it. Coverage as a number stops meaning what it used to mean once the author and the grader are the same agent.

So what's left for the human? Define what "passing" actually means for the feature, not just for the test runner. Read the test logic for intent, not just for whether it executed. And stay alert to that hallucinated-dependency risk from the architecture stage, because this is the last checkpoint before it ships.

Stage 5: Review and deployment: where the agentic SDLC either works at scale or buckles

This is the stage that decides whether everything above actually pays off. AI-generated code shows up faster and in bigger batches. If the review process doesn't change to match, it buckles under the volume: more pull requests, more review load, and no gain in how fast code actually ships. This has already happened. The Faros AI data on 1,255 teams showed this dynamic playing out across a large population.

What do teams that avoid this do differently? A few things:

• They concentrate human review into a smaller number of higher-value checkpoints, rather than reviewing every single agent action
• They redesign review around risk instead of volume, triaging by blast radius and how reversible a change is, not treating every agent-generated diff the same
• They build shared orchestration infrastructure so multiple agents operate under one consistent policy, instead of running isolated agent sessions that no one else on the team can see

In deployment specifically, agents support rollout planning, run CI/CD pipelines, and write incident summaries that speed up resolution. PwC's seven-stage SDLC framework covers this under CI/CD: automating builds, integration, and updates for delivery that's both faster and more reliable.

Practitioners point to several capabilities agents need before their output can be trusted at enterprise scale: context across code, tickets, docs, and infrastructure; persistent knowledge of how the specific team works; the ability to collaborate with humans in shared tools like Slack, tickets, and review systems; and governance, meaning scoped access, role-based controls, and guardrails that can actually be audited. Miss any of those four, and what a team has falls short of an agentic SDLC. It's just faster, isolated coding assistance with extra steps.

Governance is also where model choice becomes a real decision, not an afterthought. Agents running in deployment pipelines should use whichever model fits the task best, rather than locking into one vendor at procurement time. Routing across models intelligently tends to beat a single-vendor approach on both quality and cost.

And here's the number that should give any engineering leader pause: Cycode's State of Product Security in the AI Era 2026 research found that 100% of surveyed organizations confirmed they have AI-generated code somewhere in their codebase. Yet 81% said they have no visibility into how AI is actually used across their development lifecycle. That gap, full adoption with almost no oversight, is exactly where deployment turns into a security and governance liability.

Stage 6: Monitoring and operations: agents that observe, summarize, and respond after code ships

Once code is live, the agentic SDLC doesn't stop. Agents shift into a watching role: observing system behavior, summarizing what's happening for the humans on call, and responding to routine issues without waiting for someone to get paged first.

This closes the loop that started back at Stage 1. Requirements set intent. Architecture and coding built toward it. Testing and review checked it. Monitoring is where a team finds out whether any of that actually held up in production, and where the next round of requirements often starts. An incident summary an agent writes today can become the input for a requirements agent tomorrow.

That's the shape of the agentic SDLC as it stands right now: not a replacement for the stages developers already know, but a redistribution of who does the work inside each one. Coding and testing are furthest along. Planning and architecture remain areas where human judgment plays a central role. Review and deployment are where the gains from earlier stages are either realized or lost, the place that decides whether all the speed gained earlier actually turns into software that ships faster, or just backs up somewhere else in the pipeline. Knowing which stage a team is actually operating in, and being honest about it, is most of what it takes to work well inside this model right now.