# Agent software development lifecycle

> How to build software with AI agents: define the task, prepare context, implement, verify, review, deploy, and check the result in production.

Published 2026-10-28 by Mac Anderson. Canonical page: https://macanderson.com/research/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](/manual) covers identity, authority, budgets, and records. The research on [steering an unattended run](/research/steering-a-run-you-are-not-watching) 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](/research/agents-are-waiting-on-a-process-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](/research/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.