The Agentic Software Development Lifecycle (ASDLC) is a framework that governs how software is planned, built, validated, deployed, and operated when AI agents are actors in the process alongside humans. It describes how work moves through an Agentic Development Platform (ADP), who or what initiates each stage, and what the platform must do to keep the loop safe and productive. The role of the human across the lifecycle is not fixed. It shifts from executor to validator to orchestrator to constraint-setter as the platform matures.
The ASDLC amends the Software Development Lifecycle (SDLC), the framework that has organized software engineering for decades. The SDLC assumed a human at every stage, including writing, reviewing, validating, and deploying. That assumption is no longer valid. When agents retrieve context, implement changes, validate output, and respond to signals, the sequencing changes. The triggers change, and the platform requirements change. The ASDLC is the framework that accounts for this.
What the SDLC assumed
The SDLC was designed around human bandwidth as the primary constraint. A developer writes code, a reviewer reads it. A pipeline validates it, and then an operator deploys it. At every stage, a human initiates the next step. The platform's job was to support that flow, reducing friction and enforcing standards while making the repetitive parts fast and safe.
This worked well because humans were the only actors. The platform could assume work moved at human speed. It also assumed that each stage had a person responsible for it, and that exceptions would be caught somewhere in the chain.
None of those assumptions holds when agents are in the loop.
What changes with agents
Coding agents are not a new tool in the developer's editor. They are becoming actors across the entire software development lifecycle. When that happens, the lifecycle itself changes shape. Work is no longer driven solely by human actions. As agents retrieve context, implement changes, validate outputs, and respond to signals, the sequencing, triggers, and platform requirements all change. It is even fair to speak about agents as platform users.
Agents act fast and in parallel. They do not tire or exercise judgment the way humans do. An agent that generates fifty pull requests in an afternoon across parallel work streams has no natural stopping point. An agent that merges code without validation introduces defects at a rate no human team could match.
But agents also offer something the SDLC never had: the ability to run every stage of the lifecycle faster than any human, and to run multiple stages simultaneously across multiple work items. So rather than human bandwidth, the constraint is the quality of the platform governing those agents.
This is what makes the ASDLC distinct. In the SDLC, the human is the engine. In the ASDLC, the human's role shifts from executor to validator to orchestrator, to constraint-setter, depending on the platform maturity: The lifecycle stages do not disappear. What changes is who initiates and executes them, and what governs the handoffs between them.
The paths of the ASDLC
In the SDLC, work moves through pipeline stages. In the ASDLC, work moves through paths. A path is a valuable way for a user, human or agent, to achieve an outcome and progress along a value stream.
The feature development value stream is the clearest illustration. A piece of work enters the lifecycle as a ticket or a signal. It moves through context retrieval, implementation, validation, promotion, deployment, observation, and remediation. Each of those stages is a path. Each path has a definition: what inputs it expects, what the platform does when invoked, what output it must produce before work can continue.
In the SDLC, every path was initiated and executed by a human, with a CI pipeline handling the deterministic steps. In the ASDLC, paths come in three types.
Probabilistic paths are agent-driven. The agents do the work, and outcomes are verified by evals and humans. Reviewing a pull request, drafting a spec from a ticket, generating release notes from merged changes. The path definition specifies the LLM-driven steps and eval criteria, along with the human verification points.
Deterministic paths are pipeline-driven, repeatable, gated, and codified. CI builds, security scans, deployments, policy gates, and promotions are exactly the paths the Internal Developer Platform (IDP) already ran. They predate agents and continue to operate independently of them.
Hybrid paths combine the two in a loop. A probabilistic step produces a candidate. A deterministic gate evaluates it, and the loop continues until the gate passes. The agent proposes a change, the pipeline validates it, failures route back to the agent with updated context, and the agent retries. This loop pattern is where the real productivity gains emerge. The mistake is to treat first-pass agent failure as a problem, rather than structuring the platform so that repeated runs against error-updated context converge on the correct result. This defining structural feature of the ASDLC has no equivalent in the SDLC, and is the most underestimated shift for organizations making the transition.
How the ASDLC evolves across levels
The ASDLC is not a single fixed shape. It has four versions, each defined by a different role for the human across the lifecycle. The four levels of agentic development are, in effect, four versions of the ASDLC.
At level 1, the ASDLC looks like the SDLC with AI assistance layered on top. Agents suggest, humans approve line by line. The developer remains the execution engine. Most paths are still deterministic, with a handful of experimental probabilistic paths appearing at the edges. The lifecycle stages are the same. The human initiates and completes every one of them.
By level 2, the ASDLC gains its first structural difference from the SDLC. Agents generate pull requests in parallel. Humans trigger the work and verify behavior rather than inspect every diff. A new path appears that has no SDLC equivalent: the mechanism that converts a human-directed assignment into a governed agent work item with identity, context, and scope. Validation becomes a loop rather than a gate. The human is no longer inside every stage. They are above the loop, reviewing aggregate results rather than individual diffs.
By level 3, the ASDLC becomes signal-driven. Agents execute long-running paths in the background. The platform generates work from observed signals including a failing dependency check, a security advisory, or a pattern in production telemetry. The human defines the rules and reviews exceptions. Promotion becomes rule-based for low-risk changes. The observability plane stops being a read-only dashboard and becomes the primary input to the lifecycle. The constraint shifts from review bandwidth to architectural maturity and the economics of running agents at scale.
Level 4 is the horizon. Paths respond to environmental signals without human triggers. A vulnerability is detected and automatically remediated. A customer call transcript mentioning a frontend bug is automatically fixed and shipped. The human's role is to define the boundaries and set the escalation rules, adjusting the constraints. The lifecycle runs itself within those boundaries. Although we see early signals of this in production today, full level 4 across an organization is still an outlook rather than a standard.
What the ASDLC requires from the platform
The SDLC could run on an IDP, which is a platform organized around paths for human users, backed by CI/CD pipelines and five planes of tooling. The ASDLC cannot. It requires an Agentic Development Platform (ADP).
The ADP adds what the IDP was never designed to provide. With non-human identity and scope enforcement, the platform can reason about which agent is acting and what it is allowed to touch. With context packaging, agents have what they need to act correctly rather than proceeding on incomplete assumptions. Workspace provisioning prevents parallel agent sessions from colliding. Evaluation infrastructure enables probabilistic output to be checked against a definition of done before it proceeds. Security guardrails mean the volume of agent-generated changes does not outpace the organization's ability to govern them. The ADP also adds observability as a signal source rather than a dashboard, because at level 3 and above, the lifecycle is triggered by what the platform sees.
None of these are optional. Without them, agents amplify whatever already exists in the platform. If the platform is solid, agents multiply throughput. If it is not, agents multiply chaos. There is no neutral.
The ASDLC also requires a written definition of done for every path, for which there is no infrastructure equivalent. In the SDLC, that definition lived in the heads of senior engineers. This tribal knowledge was applied by humans at review time. In the ASDLC, agents need an explicit definition to converge on such as functional correctness, architectural alignment, policy compliance, and operational characteristics. Without it, the hybrid loop has nothing to optimize against and no way of knowing when to stop.
Why this matters for platform engineers
The SDLC gave platform engineers a stable target. The stages were known, the actors were human. The tooling categories were well understood. The IDP reference architecture has been downloaded over 250,000 times because it captured that stable target well.
The ASDLC is less stable, and that is the point. It is a lifecycle in transition, moving from human-driven to signal-driven as platform maturity increases. And the platform engineering team's job is no longer just to serve the current stage of that lifecycle. It is to build the substrate that allows the lifecycle to advance safely.
That means defining done in places where it has never been written down. Building evaluation as first-class infrastructure, versioned and reviewed like production code. Designing paths that route candidates through gates and route failure back as enriched context. Governing agent identity, cost, and scope at a level the SDLC never required.
The organizations that get this right will operate the ASDLC at a level their competitors cannot match, because the platform quality required to make the loop safe is not something that can be bought off the shelf. It must be built, owned, and operated. That is the work of the next decade, and it belongs to platform engineers.