What Is the Agentic Software Development Lifecycle?

Search “agentic software development lifecycle” and every page that ranks draws the same picture: five or six stages, Plan through Operate, with agents doing more of the work in each one and a line somewhere near the end that says consequential steps still need a human. Cycode’s version puts a sign-off before implementation. CodeRabbit’s puts it at the pull request. AWS’s AI-DLC, which Jellyfish summarizes well, says it most clearly: “AI proposes, humans decide.” Then every one of them stops, because the next sentence would have to say which human, deciding on what, at which fixed point, and what the work is doing while it waits.

That next sentence is the whole lifecycle. Here is one that has it: six stages, a named Agent owning the work of each, three decisions that belong to a person, and a record that shows what happened in between. It is the lifecycle a YAGNI Team runs, and it is also a usable definition of the term for anyone running agents on their own.

What is the agentic software development lifecycle?

The agentic software development lifecycle is the path a unit of engineering work takes when agents do the work of each phase and people make the decisions between phases. It is the ordinary software development lifecycle with two things made explicit that the ordinary one leaves to culture: who owns the work at each stage, and which artifact a person approves before the next stage may start.

That second part is what separates an agentic lifecycle from an agent with a long leash. A coding agent that takes a ticket and comes back with a pull request has a lifecycle too, but all of it happens inside the agent, and the only checkpoint is the diff at the end. By then the cheapest moment to say no, before any code was written, has already passed. An agentic lifecycle puts the checkpoints where they are cheap and names what is being approved at each one.

The word “agentic” means the agent runs the loop. The lifecycle is about the other half: a person runs the agent, and managing AI coding agents without watching every step is what the stages and checkpoints are for.

How does it map onto the lifecycle you already run?

Every engineering org already has these phases. The agentic version keeps them, changes who does the work in each, and names a fixed checkpoint where one used to be a habit.

Phase your org runs today	Stage on an agentic Team	Who does the work	What a person decides
Backlog grooming, prioritization	Proposed	Bailey, the Product Manager, proposes the next ticket from the Jira or Linear backlog with evidence	Accept it, or say it does not need work
Design, technical planning	Plan	Reeve, the Staff Engineer, plans it against the real repository	Approve the plan, or send it back with a note
Implementation	Build	Wright implements the approved plan on a branch, in a sandbox, with tests, and opens a draft pull request	Nothing, unless the line is supervised, in which case the build waits for one click to start
Code review	Review	Proctor reads the pull request through its checks and posts one review with a verdict	Read the review before merging; confirm the verdict if Proctor’s line is supervised
QA, acceptance testing	QA	Fletcher (beta) boots the repository environment, writes a test plan from the change, walks it in a browser, and attaches video and screenshots	Read the evidence
Release	Done	A person merges; the merge webhook moves the ticket to Done with a Receipt	Merge
Status, reporting	Any time	Harper, the Chronicler, posts the Daily Brief to Slack with the receipts attached	Nothing; read it

Two things stand out against the pages that rank. The first is that the roles have names. “Agents handle implementation and testing” is true of every vendor’s diagram and useful to nobody; “Wright builds, Proctor reviews, Fletcher walks it” is something a manager can put on a Team page and hold to account. The second is that the person’s column is short and fixed. Three decisions on a supervised ticket, and they are the same three on every ticket: accept, approve, merge.

What are the six stages, and who owns each?

The stage words are Proposed, Plan, Build, Review, QA, and Done. They are the only stage words, on the Work view, on the Team page, in Slack, and in the record, so a ticket means the same thing wherever a person reads it.

Proposed is waiting for a person to say yes. Bailey reads the Team’s backlog, ranks what is ready, and proposes the next ticket with the evidence for it: the support threads, the failing metric, the dependency that blocks two other tickets. Bailey never ships anything. A proposal always waits for a person, and “Start plan” is the first click. A ticket a person starts themselves from the tracker skips this stage and lands in Plan, already accepted.

Plan means someone said yes and the plan is being drafted or is waiting for approval. Reeve, the Staff Engineer, drafts it in a sandbox against the real repository: the files it expects to touch, the approach, the tests it will add, what it is leaving alone. Reeve answers what it can from the Team’s decision ledger and asks what it cannot, as questions on the case file. It plans with the hard-to-reverse risks in hand and checks its own plan before the gate opens, for the module it missed or the simpler path it walked past. Reeve never builds. A person reads the plan and makes the second click: “Approve plan” or “Send back”.

Build is an approved plan being implemented on a branch. Wright clones the repository into a sandbox, implements the plan, writes the tests, runs them, and opens a draft pull request on GitHub through the workspace’s GitHub App. Nothing touches the trunk. This is the stage everyone wants to make autonomous first, and on a new Team it starts supervised: Wright waits for one click before it begins, until the person who owns the line has read enough of its track record to move it.

Review is a pull request open and under review. Proctor reads it through its checks (deep review, business fit, database, security, tests) and posts one review with a verdict. Wright answers each finding with follow-up commits, up to the rounds the Team allows. An approving verdict marks the pull request ready with no click from anyone, because Proctor’s line starts autonomous. Proctor never blocks a merge and never merges.

QA is the change being walked in a browser. Fletcher, in beta, boots the Team’s repository environment at that revision, writes a test plan from the change, walks it, and attaches the video, the screenshots, and a verdict to the ticket. Fletcher never edits application code. Where a change has no surface to walk, the stage is short.

Done means merged. Not “the agent finished,” not “the pull request was approved,” but merged on GitHub, by a person, with the webhook as proof. That is the third click and the only one that has no autonomous setting at all.

Harper sits outside the six. Its lines run on their own clock, reading what the Team shipped and posting an Update to Slack with the receipts beside each line. It is the stage the lifecycle pages call Operate or Monitor, done as reporting rather than as a seventh gate.

Where exactly is the person in the loop?

At three fixed points, on three artifacts, with three verbs. This is the question the ranking pages answer with “human oversight must be redesigned, not eliminated,” which is advice, not a design.

Checkpoint	What the person reads	The verbs
Accept the proposal	Bailey’s proposal and its evidence	Start plan, or Doesn’t need work
Approve the plan	Reeve’s plan and its check, with the open questions answered	Approve plan, or Send back
Merge	The approved plan, the test runs, Proctor’s review with the findings it set aside and why, Fletcher’s evidence	Merge

Each checkpoint is a Decision addressed to a named member of the Team, by default the Team’s owner, and it resolves in one place: the ticket’s case file, or the Slack message that carries the same ask. There is no second approvals queue. Every open decision older than a day reminds its addressee each morning, so a ticket cannot wait quietly.

Why these three and not more? Because a checkpoint is worth having where the cost of being wrong is high and the cost of deciding is low. The plan is the cheapest place in the ticket to say no: a plan sent back costs one more draft. The same mistake caught at review costs a build. Caught after merge it costs an incident. So the lifecycle spends the person’s attention before the code exists and at the moment it becomes real, and lets the Agents carry the middle.

Why not fewer? Because merge is the act that makes everything before it real, and the company needs a named person who decided it should be. On a YAGNI Team there is no merge line to set to autonomous. Deploy and data-migration lines cap at supervised on every Team, permanently. The Ladder has two rungs, supervised and autonomous, set per line by a person with the track record beside it, and the Ladder lesson walks through moving one. The three clicks are the floor the Ladder stands on.

What is the ticket doing while it waits?

This is the part no lifecycle diagram shows, and it is the part a manager looks at every day. A stage says where the ticket is in the lifecycle. One state beside the stage says what is happening there:

• waiting: a decision is addressed to a person and nothing moves until they answer it.
• working: a run is live, and the row names the Agent and what it is doing in that stage (“Plan · Wright is drafting the plan”, “Review · Proctor is reviewing”, “QA · Fletcher is testing”).
• stopped: the last run ended badly and nothing replaced it. Nobody is working on it and nobody has been asked, so it stays that way until a person or a scheduled line picks it back up, and the row says why (“Build · stopped: build timed out”).
• queued: nobody is working on it and nobody has been asked anything. It is honestly waiting its turn, and the row says so rather than looking busy.
• settled: the ticket is finished, merged or closed with no work landed, and reads its outcome.

An open ask decides the stage over anything else. A ticket whose plan is waiting for approval reads “Plan, waiting on Priya” even if Wright finished drafting an hour ago. An accepted ticket that nothing on the Team will start says so, rather than sitting in Plan looking busy. The Work view groups these three ways: by stage, which is the map; waiting on you, which is the queue a person actually works; and latest, which is the log. The Work lesson covers the three views.

The practical effect is that “where are we on this” has an answer that is not a meeting. Tracking engineering progress without a project manager is the longer version of that argument.

What moves a ticket from one stage to the next?

An event with a record, never an Agent’s own say-so. The lifecycle pages describe stages as things an agent progresses through. On a Team, a ticket moves because something happened that the record can show:

1. Proposed to Plan: a person clicked Start plan, or started the ticket from the tracker.
2. Plan to Build: a person clicked Approve plan.
3. Build to Review: Wright opened the draft pull request on GitHub.
4. Review to QA: Proctor’s approving verdict marked the pull request ready.
5. QA to Done: the merge webhook arrived from GitHub naming who merged and the commit.

The last one is the rule for all of them. YAGNI never says “done” on its own say-so, only on the source’s. The pull request merged on GitHub, the ticket closed in Jira or Linear, the message landed in Slack: each is a Receipt, and a Receipt is what moves the stage. Shipped is not Done. The Receipt is.

What does one ticket look like, stage by stage?

A Team works on an inventory service, reads a Jira project, and posts to a channel in Slack. Its build line is still supervised; the person who owns the Team, Dana, has not moved it yet.

Proposed. Bailey proposes INV-412, “Reject negative stock adjustments at the API, not in the nightly job,” with the evidence: four adjustments last week that the nightly job caught and two it did not. Dana reads it on the case file and clicks Start plan. One click.

Plan. Reeve drafts a plan: validate at the adjustment endpoint, return a 422 with the reason, add tests for the three negative cases, leave the nightly job as a safety net. One open question comes back as a tap: should an adjustment that nets to zero across a batch be allowed? Dana answers yes. Reeve’s own check notes the endpoint already has a validation layer the first draft was about to bypass, and the plan is redrafted to use it. Dana reads the plan and clicks Approve plan. Two clicks.

Build. Because the line is supervised, the build waits as a decision addressed to Dana, who clicks it. Wright clones the repository into the sandbox, implements the validation, writes the tests, runs the suite, and opens a draft pull request with the plan linked. The runs land on the case file with their output.

Review. Proctor posts one review: an approving verdict, one finding fixed in a follow-up commit from Wright (a missing index on the query the validation added), and one finding set aside with the reason (a naming convention the Team’s Playbook already covers). The verdict marks the pull request ready.

QA. Fletcher (beta) boots the environment, writes a test plan from the change, walks the adjustment form in a browser with a negative value, and attaches the video and a verdict.

Done. Dana opens the Review case file, reads the plan, the review, the runs, and Fletcher’s evidence, and merges on GitHub. The webhook moves INV-412 to Done with a Receipt. Jira closes the ticket because GitHub says the pull request merged. Harper’s Daily Brief names it the next morning, with the pull request number beside it.

Four clicks of Dana’s, three of them the fixed checkpoints and one because the build line is supervised. Move that line to autonomous after enough tickets like this one and it is three. Your first ticket walks the same path on a fresh Team.

What does the lifecycle cost, stage by stage?

This is the question only two of the ranking pages touch and none answers per stage, because most agent tooling bills as one monthly number with no line items. A lifecycle with stages should have a cost per stage, or the stages are decoration.

On a YAGNI ticket, every run on the case file shows what the workspace was charged for it, and the case file totals the ticket. Usage adds them up per Agent and per developer, broken out by the job that spent it, on the one rate card that YAGNI Code developers and Agent Teams share. The models under the Agents are vetted US-hosted open-weight models at 60% or more under comparable frontier API rates, with a router that places each step on the cheapest lane that holds quality.

Two things fall out of per-stage cost that a monthly bill hides. The first is that the plan checkpoint is where money is saved, not just risk: a plan sent back costs a draft, while a build sent back costs a build. The second is that a Team’s spend becomes something an engineering manager can read beside the work it produced, which is how a manager already thinks about a team’s time. Pricing has the rate-card shape; the numbers are shared on a call.

What does the record show when the ticket is Done?

The case file, which is the ticket’s whole record and the reason the three clicks are cheap:

• The proposal, its evidence, and who accepted it.
• Reeve’s plan and its check, the questions asked and answered, and who approved it.
• Every run in the sandbox, with the tests that ran and what they returned.
• The pull request, as a draft and then as ready.
• Proctor’s review, the verdict, and the findings it set aside with the reasons.
• Fletcher’s test plan, video, and screenshots where the change had a surface.
• The clicks a person made, by name, and when.
• What each run cost.

Corrections leave the record and change the Team. When Dana sends a plan back or overturns a verdict, the Team proposes a Playbook rule, and a person adopts it or dismisses it. Product-intent calls, like the zero-net batch question above, land in the decision ledger, which every Agent reads before it guesses on the next ticket. The lifecycle is how a Team gets trained, in the earned sense: it learns the way a new hire learns, by being corrected on real work with the record beside it. Managing AI coding agents covers why the record matters more than the streak, and what autonomous coding agents should own draws the line between an Agent’s work and a person’s decision at each act.

So what is the agentic software development lifecycle, in practice?

Six stages a ticket moves through, Proposed, Plan, Build, Review, QA, Done, each owned by a named Agent, with a person accepting the proposal, approving the plan, and merging, and a record that shows what happened between those clicks. The stages map onto the lifecycle an engineering org already runs. What changes is that the owners are named, the checkpoints are fixed, and the ticket always says what it is waiting on.

The pages that rank for this term are right that humans decide and agents propose. The lifecycle is what you get when you finish the sentence.

---

YAGNI runs agent teams, managed like your engineering team: Bailey proposes, Reeve plans, Wright builds to a draft pull request, Proctor reviews, Fletcher (beta) walks the change, and Harper reports, with merge always a person’s click. See how agent teams work, or book 30 minutes to map the six stages onto your own backlog.