What is the agentic development lifecycle (ADLC)?
Published August 22, 2026 · by the AQ team
The agentic development lifecycle (ADLC) is a software development lifecycle in which AI coding agents execute the work of each phase (planning, implementation, testing, delivery) while humans set intent, define boundaries, and review outcomes. The traditional SDLC's phases do not disappear. What changes is who performs each one: human effort concentrates at two points, specifying what should be built and judging what the agents actually built. As of August 2026 the term appears in vendor guides, consultancy frameworks, community manifestos, and practitioner writing, and the definitions converge on one inversion: agents do, humans direct and review.
One acronym, two different terms
Before comparing definitions, separate two things that share the abbreviation. The agentic development lifecycle, this page's subject, is about agents building your software: the same repositories, tickets, and releases you already ship, with coding agents doing more of the execution. The agent development lifecycle is about building agents as products: platform vendors such as IBM and Arthur use ADLC for the process of planning, building, testing, deploying, and monitoring AI agents themselves, a discipline closer to MLOps than to shipping application code. Both usages are live as of August 2026, so check which lifecycle a vendor page means. This page covers the first sense, the one reshaping how ordinary software teams work.
What actually changes from the SDLC
The ADLC is best understood as a change of executor, not a change of phases. The table shows where the work moves:
| Phase | Traditional SDLC | Agentic development lifecycle | What the human still owns |
|---|---|---|---|
| Planning | Humans write tickets and specs | Agents draft plans and break down work from stated intent | The intent itself, priorities, and approval of the plan |
| Implementation | Humans type code in an editor | Agents edit files, run commands, and iterate toward the goal | Boundaries: which repos, which dependencies, what is off limits |
| Testing | Humans write tests, CI runs them | Agents generate and run tests inside their own loop | Deciding what must be proven before merge, and checking it actually ran |
| Review | A teammate reads the diff | The volume multiplies: sessions, diffs, and agent self-reports all need judgment | All of it. Review is the phase that does not delegate |
| Delivery and maintenance | Humans deploy and watch dashboards | Agents open pull requests, fix CI, and propose follow-ups | The merge decision, release authorization, and accountability for production |
Every serious treatment of the term lands on the same asymmetry: four of the five phases delegate well, and one concentrates. That is the defining property of the lifecycle.
Why review becomes the load-bearing phase
When generation gets cheap, judgment becomes the constraint. An agent produces a plausible pull request in minutes; deciding whether that pull request is correct, safe, and wanted still takes a human who understands the system. Practitioner accounts keep converging on this: an August 2026 AI SDLC explainer summarizes the principle as "AI generates, humans judge" and reports teams seeing review cycles take twice as long and post-merge bug fixes triple where that judgment was skipped.
The uncomfortable part is who does the judging today. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. In lifecycle terms: the phase the ADLC most depends on is, in most teams, a single person grading work they supervised themselves. That is the self-review problem, and it is why the review phase deserves more design attention than the generation phases that get most of the tooling.
What humans own in an ADLC
Human judgment does not disappear from an agentic lifecycle; it relocates. Three responsibilities stay human no matter how capable the agents get:
- Intent and specification. Agents amplify whatever they are pointed at. Teams that do well in this lifecycle invest in making intent checkable: written specs, acceptance criteria, and executable specs and tests the agent can run against its own work while it iterates.
- Boundaries and guardrails. Which credentials an agent holds, which repositories it can touch, what runs in its loop before a change is proposed. Martin Fowler's writing on agentic programming, as of mid 2026, describes the shift in exactly these terms: humans overseeing agents that generate the code. The oversight works when it is a designed system, not a vibe.
- Review of outcomes. Not one artifact but three. The session shows how the agent got there: which commands ran, what the test output actually said, where it went down a dead end (see how to review an AI coding session). The diff shows what changed. The running behavior shows whether the result works, which is what previews and staging exist for. An agent's own summary of its work belongs to none of these: it is a claim, and verification means checking the artifact behind the claim.
Accountability threads through all three: a human approves requirements, authorizes the release, and answers for what reaches production. The lifecycle changes who types, not who is responsible.
Adopting the lifecycle without new vocabulary
A team can run an agentic development lifecycle with nothing but the tools it already has. The practices that matter, vendor-neutral:
- Write intent down where the agent can read it, and encode as much of it as possible into tests the agent runs in its own loop.
- Keep the transcript. A session log that shows the real test run and the real command output turns "the agent says it passed" into evidence.
- Review sessions, not just diffs, for consequential changes. The diff shows the destination; the session shows the route, and the route is where wrong assumptions are visible.
- Get a second human into the loop for changes that matter. The LeadDev numbers above are the default outcome when nobody designs for this: the operator becomes the only reviewer.
- Treat review capacity as the budget. "How much can we generate?" matters less than "how much can we responsibly judge?", and throughput in this lifecycle is set by the second number.
ADLC, ADE, harness: related, not interchangeable
The ADLC is a process. An agentic development environment (ADE) is a place: the workspace product where delegated agent runs are started, supervised, and reviewed. A coding harness is the software layer that turns a model into a working agent and gives it somewhere real to execute. And multiplayer agents describe who is in the room: multiple humans sharing visibility into the same agent sessions. They relate without being synonyms: a team practicing the ADLC runs its agents through some harness, usually inside some environment, and the multiplayer question decides whether the lifecycle's review phase falls on one person or a team.
Where AQ fits
AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this page's terms, AQ is infrastructure for the phase the ADLC concentrates on: review of outcomes, by more than one human. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser, so the session itself, the ground truth of what the agent did, survives a closed laptop and stays open to the team. Teammates open the same workspace and watch the same live session rather than meeting the work for the first time as a finished pull request; typing into someone else's terminal is delegated, with the owner approving a control request in one click.
The rest of the lifecycle's artifacts live in the same place. Each workspace gets one isolated git worktree, agents commit, push, and open pull requests with per-user GitHub auth, and PRs are tracked per workspace. Live dev-server previews put the running behavior next to the diff, with shareable links that work without an account for viewing, and comments pinned on the preview can be sent to the agent as prompts. Intake fits the lifecycle's front end too: label a Linear issue ai-task and a workspace appears, with status syncing both ways and a human, never an automation, starting the agent. Each engineer signs in with their own Claude or OpenAI account, so AQ never marks up model usage.
Plainly: the ADLC is a way of working, not a product you buy, and a team can practice it with a VM, tmux, and discipline. AQ earns its place when the review phase outgrows one person: when the team wants agent sessions visible, durable, and reviewable together, on infrastructure it owns. The Free plan is a personal sandbox for one person (AQ creates a private machine in an isolated network, nothing to install, no time limit); the Team plan is $50 per user per month in early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM, with the rate locked for your first 12 months.
Frequently asked questions
What is the difference between the ADLC and the SDLC?
The phases are the same: planning, implementation, testing, review, delivery. The difference is the executor. In the agentic development lifecycle, AI coding agents perform most of the execution inside each phase, and human effort concentrates on stating intent, setting boundaries, and reviewing outcomes. Review is the one phase that does not delegate, which is why it becomes the constraint on throughput.
Is ADLC the same as the agent development lifecycle?
No, and the collision is worth knowing about. The agentic development lifecycle (this page) is about agents building your software. The agent development lifecycle, the sense used by platform vendors such as IBM and Arthur as of August 2026, is about building and operating AI agents themselves: planning, building, evaluating, deploying, and monitoring an agent as a product. Same acronym, different lifecycle.
Does code review go away in an agentic development lifecycle?
The opposite: review becomes the load-bearing phase. Agents make generation cheap, so the volume of changes needing judgment goes up while the humans able to judge stay constant. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, which means most teams are running the lifecycle's most important phase as a one-person self-check.
What should a human actually review in an ADLC?
Three artifacts, not one. The session transcript shows how the agent got to the result: real commands, real test output, dead ends. The diff shows what changed. The running application shows whether it works. An agent's own summary of its work is not one of the three; it is a claim to verify against them. For consequential changes, teams also add a second human, so the review is not performed solely by the person who supervised the agent.
How does the ADLC relate to an agentic development environment (ADE)?
The ADLC is the process; an ADE is a place where the process runs. An agentic development environment is a workspace product built around delegating tasks to agents and reviewing their output. A team can practice the agentic development lifecycle in an ADE, in a plain terminal on a VM, or in a harness like AQ. The lifecycle describes how work flows and who judges it, whatever surface it happens on.