Agent software development lifecycle

An agent opens a pull request and reports that the work is done. The branch has a conflict. The checks ran on an earlier commit. No deployment contains the fix.

An agent software development lifecycle is the process that carries a task from intent to verified behavior in a running system. I use the term to include the handoffs around the coding agent: who assigns work, who can approve it, what each check proves, and what happens when a step fails.

The aim is to ship software with autonomous agents while keeping evidence at each handoff. Code generation is one stage of that process.

The delivery process#

Stage	Work	Evidence to keep
Define	Describe the user outcome and constraints	A task brief with acceptance examples
Inspect	Read the current code and its dependencies	Relevant files and the starting revision
Plan	Choose a bounded change and assign ownership	Changed interfaces and the checks to run
Implement	Edit code and the affected documentation	A reviewable diff
Verify	Exercise the new behavior and likely failures	Results tied to the current commit
Review	Inspect correctness and the limits of the evidence	Findings and their resolutions
Release	Merge and deploy through the project's process	The revision that reached the environment
Observe	Check the changed behavior in that environment	The outcome and a way to recover

A small text edit may pass through these stages quickly. A schema change needs more care because an older service may still read the old shape. The amount of work changes with risk; the meaning of done should stay clear.

Authority#

Give an agent the access needed for its task. Reading source, changing a branch, sending email, and deploying a service are different actions. The surrounding system should enforce those differences.

A task also needs a budget and a stop condition. An agent that cannot resolve a dependency should report the missing input. Repeating the same attempt can consume time and money without changing the result.

The field manual covers identity, authority, budgets, and records. The research on steering an unattended run examines why a long run needs more than an opening prompt.

Feedback#

A failed test should return the relevant assertion and enough context to reproduce the failure. A merge conflict should return the current base and the conflicting changes. A failed deployment should return the failing step and the environment.

Send the agent evidence it can act on. Do not reduce every failure to a new instruction to try harder. When the same cause recurs, change the code, the task, or the available tools.

The essay on processes built for people examines the delays that remain when coding gets faster. A team that speeds up implementation but leaves review and release unclear moves the queue rather than finishing more work.

Production checks#

A merged pull request proves that a branch entered the base branch. It does not prove a deployment completed. A healthy homepage does not prove that a changed payment or migration path works.

Check the specific behavior and the deployed revision. Keep a recovery path that matches the change: revert a code change, disable a feature, or restore compatible behavior. Data changes may need a forward fix instead of a rollback.

Measures#

Track accepted tasks, escaped defects, time spent waiting, and the cost of accepted work. Include retries and failed runs in the cost. Commit counts alone cannot tell you whether users received working software.

Start with the coding agent best practices for a single task. Then use the same acceptance rules at each stage, from the first patch to the behavior a user can see.

@online{anderson2026agentsoftwaredevelopment,
  author  = {Anderson, Mac},
  title   = {Agent software development lifecycle},
  year    = {2026},
  date    = {2026-10-28},
  url     = {https://macanderson.com/research/agent-software-development-lifecycle}
}