AI Agents for Software Development: A Team You Can Manage
AI agents for software development, run as a team an engineering leader can manage: six named Agents, fixed checkpoints, a record per ticket, one meter.
Search “ai agents for software development” and the first page is a buyer’s guide to a category nobody has defined. Index.dev ranks ten agents with a SWE-bench table and a hiring funnel underneath. Prismetric ranks fifteen, mixing autocomplete, research projects, and static analysis under one heading. Graphite lists the free ones and its own. GitHub’s explainer defines agents from the textbook taxonomy and ends on Copilot. Gartner’s article for CIOs describes them as a step beyond code assistants, autonomous autopilots for development and testing tasks, and adds that they will likely bring new security risks.
Every one of them answers “which agent”. None answers the question an engineering leader is actually typing: “how do I run these as part of my engineering team”. Who owns the work an agent does? What does a person look at before it merges? What may run on its own, and who decides? What does the record show six weeks later, and what did it cost?
This is the guide to that question. It defines the category, explains why rollouts stall after the pilot, and shows the arrangement that gets past it: six named Agents, managed the way an engineering team is managed. That arrangement is a YAGNI Team, and it is also a usable design for anyone running agents on their own.
What are AI agents for software development?
An AI agent for software development is a program that takes a unit of engineering work and carries it through several steps on its own, choosing the next step from the result of the last. It reads a ticket, looks at the repository, decides which files to touch, writes the change, runs the tests, reads the failures, and tries again. The loop is what makes it an agent. Code completion suggests the next line while a developer types; an agent is handed a goal and comes back with a result.
That one definition covers three different things, and most of the first page mixes them.
Assistants in the editor. Copilot in its original form, Cursor’s tab completion, the chat panel beside the code. A developer stays at the keyboard and reviews every suggestion as it appears.
Coding agents in the terminal. Claude Code, Codex, Cursor’s agent mode, YAGNI Code. A developer gives the agent a task, it works for minutes in the repository, and the developer reviews the diff at the end. It has changed how developers work, and it is still the developer’s own work: one person, one task, one review. What is the best coding agent? is this series’ answer to the ranking question for this kind.
Agents that carry a ticket. The kind that takes work the org delegates rather than work a developer is already doing: reads the backlog, proposes what is next, plans it, builds it to a pull request, reviews it, tests it, and reports on it. This is the kind the listicles call “autonomous” and the kind an engineering leader has to manage, because nobody is at the keyboard while it works.
The rest of this guide is about the third kind and the arrangement that makes it manageable. Everything in it is additive: a YAGNI Team reads the GitHub, Jira, Linear, Slack, and Confluence your engineers already keep and ships approved work back into them, and the terminal agents your developers run keep running.
Why do most agent rollouts stall after the pilot?
Because the pilot is run as a demo and the rollout as a tool purchase, and neither is how an engineering org gets work done. Three failures account for almost every stalled rollout, and they are the three pains this series is built around.
Nobody can trust the agent with real work. The pilot impresses for an afternoon. Then the agent opens a pull request that touches a payment path the team had ruled out, and the team learns to babysit it. Within a month it is used for throwaway scripts. The missing piece is not a better model. It is ownership: a named person the agent’s work reports to, a checkpoint before the work starts, and a review a person can read before it merges. How to manage AI coding agents and keep them accountable is the long version.
The agent does not know the codebase or the company. It writes a retry loop where the team decided last quarter never to retry. It guesses at product intent because the ticket did not say and the decision lives in a Slack thread from March. Every retry costs money and trust. Context engineering for coding agents covers where the why lives and how an Agent reads it before it guesses.
The bill arrives as one number. Frontier agent usage is metered per token and billed per month, and no one can say what a ticket cost or which agent spent it. A tooling line nobody can explain gets cut at the next budget review. The cost section further down this page takes it apart.
None of the three is a capability problem. The agents on the first page can all write a working change to a well-specified ticket. What stalls is the management around them, so the fix is a management frame, not a model upgrade.
What does it mean to manage AI agents like an engineering team?
It means doing for Agents what an engineering manager already does for people, with one improvement: the record is written down.
An engineering team works because of a few plain mechanisms. Someone owns a scope and reports to an accountable lead. Work is delegated with the approach agreed before it starts. A reviewer who reads intent signs off before anything merges. A senior engineer earns more rope after being watched. Corrections become how the team does things. Someone reports what shipped and someone owns the budget.
A YAGNI Team is those mechanisms applied to Agents. A Team mirrors one of your engineering teams, never a repository: it attaches that team’s repositories, works from its Jira project or Linear team, posts to its Slack channel, and reports to one owner, a named person. On the Team are six named Agents, each with a job. Each job runs as a line with an autonomy setting a person controls. Every consequential act is a Decision addressed to a named person, and every result leaves a Receipt. Over time, corrections become Playbook rules and product-intent calls land in a decision ledger every Agent reads.
The one-liner is “agent teams, managed like your engineering team”. The manager’s job does not change. Its objects do. AI for engineering managers walks a manager’s morning on one of these Teams, twenty minutes and four asks, with no terminal and no prompt.
Who are the six Agents, and what does each one own?
Named for the job, in the order a ticket meets them. “Agents handle implementation and testing” is true of every vendor diagram and useful to nobody. A name on a Team page is something a manager can hold to account.
| Agent | Role | What it owns | What it never does | What a person decides |
|---|---|---|---|---|
| Bailey | Product Manager | Reads the Team’s Jira or Linear backlog and proposes the next ticket, with the evidence for it and a spec the later stages read as context | Never ships anything; a proposal always waits | Accept the proposal, or say it does not need work |
| Reeve | Staff Engineer | Plans accepted work against the real repository: files, approach, tests, what it is leaving alone. Checks its own plan in rounds before the gate opens | Never builds | Approve the plan, or send it back with a note |
| Wright | Builder | Implements the approved plan on a branch in a sandbox, writes and runs the tests, opens a draft pull request through the GitHub App | Never touches the trunk, never merges | Nothing, unless the build line is supervised, in which case one click starts it |
| Proctor | Reviewer | Reads the pull request through its checks (deep review, business fit, database, security, tests) and posts one review with a verdict; follows up per commit | Never blocks a merge, never merges | Read the review before merging |
| Fletcher (beta) | QA | Boots the Team’s repository environment at that revision, writes a test plan from the change, walks it in a browser, attaches video and screenshots with a verdict | Never edits application code | Read the evidence |
| Harper | Chronicler | Runs the reporting jobs a person sets, such as the Daily Brief to Slack: what shipped, what is in flight, what needs a person, each line with its Receipt | Never does engineering work | Nothing; read it |
Three things to notice. There is one Agent per stage, so “who planned this” has one answer. The “never does” column is as fixed as the “owns” column, and no setting changes it. And the person’s column is short: three decisions on a supervised ticket, the same three every time.
Each Agent has its own post in this series: Bailey on the backlog, Reeve and spec-driven development, Proctor among the AI code review tools, Fletcher and AI QA testing, and Harper’s async standup. Wright’s job, the middle of the ticket, is the subject of what autonomous coding agents should be allowed to own.
How does a ticket move through a Team?
Through six stages, each owned by one Agent, with a person deciding between them. The stage words are Proposed, Plan, Build, Review, QA, and Done, and they are the only stage words anywhere a ticket is shown: on Work, on the Team page, in Slack, and in the record.
| Stage | What is happening | Who moves it on, and how |
|---|---|---|
| Proposed | Bailey has proposed the ticket with evidence; it is waiting for a person | A person clicks Start plan (or starts a ticket from the tracker, which lands in Plan already accepted) |
| Plan | Reeve is drafting the plan, or the plan is waiting for approval | A person clicks Approve plan |
| Build | Wright is implementing the approved plan in a sandbox | Wright opens the draft pull request on GitHub |
| Review | Proctor is reviewing; Wright answers findings with follow-up commits | Proctor’s approving verdict marks the pull request ready |
| QA | Fletcher (beta) is walking the change in a browser | Fletcher attaches its evidence and verdict |
| Done | Merged on GitHub, by a person | The merge webhook arrives naming who merged and the commit |
The rule behind the last row is the rule behind all of them: a ticket moves because something happened that the record can show, never because an Agent said it was finished. Done means merged on GitHub, by a person, with the webhook as proof.
Beside the stage, one state says what the ticket is doing there: waiting on a named person, working, stopped with the reason, queued, or settled. So “where are we on this” has an answer that is not a meeting. The agentic software development lifecycle walks the six stages in detail, and how to track engineering progress without a project manager covers what that does to the status meeting.
Where do people stay in the loop, and what may run on its own?
At three fixed points on a supervised ticket, plus whatever else a person chooses to keep supervised. The first page answers this with “humans should oversee consequential actions”, which is advice. Here is the design.
The three fixed points are accept the proposal, approve the plan, and merge. Each is a Decision addressed to a named member of the Team, by default the owner, and it resolves in one place, the case file or the Slack message that carries the same ask. An open ask reminds its addressee each morning, so a ticket cannot wait quietly.
Why these three? A checkpoint belongs where the cost of being wrong is high and the cost of deciding is low. A plan sent back costs one more draft; the same mistake caught at review costs a build, and after merge it costs an incident. So the design spends a person’s attention before any code exists and at the moment the change becomes real.
Everything else is set per line by the Ladder, which has two rungs. Supervised means the act waits as a gate addressed to a named person, and the copy reads “supervised by Priya” wherever the line appears. Autonomous means the act dispatches on its own and leaves a Receipt. A new Team starts conservative: the plan and build lines supervised, the review line autonomous because a review is advice and cannot merge anything, Fletcher off until the repository environment is ready.
Beside each line sits its track record: accepted as proposed, edited, sent back, auto-shipped, reversed, over time. A person moves a line between the rungs with one explicit act, with that record beside it. Nothing moves a rung on its own, and a reversed autonomous act is one more count on the record.
Two things never move. Deploys and data migrations cap at supervised on every Team, permanently. And merge is always a person’s click: there is no merge line to set to autonomous. Proctor’s approving verdict marks the pull request ready, and a person merges on GitHub. If a Team needs to stop, Pause stops every line at once. Human in the loop AI agents walks each click and what a person reads before it.
How do the Agents know your codebase and your company?
By reading what your engineers already keep, and by remembering what people decide as the work happens. The agents on the first page start every task from the repository and the prompt, which is enough for a well-specified ticket and not for the fourth ticket in a service with history.
Four sources, in the order an Agent consults them:
- The connected tools. A Team reads the GitHub repositories attached to it, the Jira project or Linear team it works from, the Confluence or Notion pages the team keeps, and the Slack channel it posts to. Bailey’s proposal cites the ticket’s history and the threads linked to it; Reeve’s plan cites the design page. The GitHub App is the only door into a repository.
- The decision ledger. Product-intent calls people make as the work happens, such as “webhook payloads are never retried after 24 hours”, recorded as Decisions a person can confirm or supersede, never edit. Every Agent reads the ledger before it guesses. When Reeve cannot answer a question from it, the question goes to the member named as the Team’s answerer for that kind, by name, and the answer lands in the ledger for next time.
- The Playbook. Rules the Team learned from corrections. When a person sends a plan back or overturns a verdict, the Team proposes a rule and a person adopts or dismisses it. A send-back on one ticket is a rule the next plan already follows.
- Earlier work. When a person starts a ticket over, Reeve’s plan must not repeat what the discarded work was thrown away for.
This is what “trained, not bought” means on a Team: it learns the way a new hire learns, by being corrected on real work, and the receipt is the track record beside each line and the ledger entry beside each decision. Context engineering for coding agents covers the ledger and the Playbook, and what should a Jira AI agent do with an engineering ticket walks one ticket through Jira and Confluence as grounding.
What record does a ticket leave?
A case file, the ticket’s whole history and the reason the three clicks are cheap. Every entry is an artifact a person already read once, at a gate.
- Bailey’s proposal, its evidence, and who accepted it.
- Reeve’s plan and its self-review, the questions it asked and the answers it got, 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 to walk.
- The clicks a person made, by name and time.
- What each run cost.
Six weeks later, “why did this ship, who said yes, and what did it cost” is answered in one place. AI agent audit trail walks one ticket’s record end to end and sets it against the “log everything” advice that ranks for the term.
What do AI agents for software development cost?
Two things, and the first page conflates them: what the vendor charges, and what a ticket costs you.
What vendors charge. As of October 2026, most coding agents bill a seat per developer plus metered usage above an allowance, and the usage is where the money goes once a team uses agents for real work. The seat is easy to budget and the usage is not: it arrives as one monthly number, with no line for which developer, agent, or ticket spent it. Check each vendor’s pricing page for current numbers; they change too often to print here.
What a ticket costs. Token price is not task cost. A cheaper model that retries three times costs more than a dearer one that lands the change first, and an agent that does not know the codebase retries more. The levers that lower task cost are the ones above: a plan a person approves before any code is written, a ledger that stops the guess, and a Playbook that stops the repeat correction. The plan checkpoint saves money as well as risk, because a plan sent back costs a draft and a build sent back costs a build.
YAGNI’s answer sits on both sides. The Agents run on 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, and hard tasks can still go to a stronger lane when the cheaper one would not hold. Developers using YAGNI Code, or Claude Code and Codex routed through it, and the Agents on Teams bill on one usage-based rate card with no seats: a developer with no usage costs nothing. The rate card itself is shared on a call, not published.
What that buys an engineering leader is the Usage page: spend and savings per developer and per Agent, each Agent’s spend broken out by the line that spent it, and every run’s cost on the ticket’s case file. The questions a budget review asks, what did the propose line cost last month, what did this ticket cost end to end, have answers. What is agentic engineering covers what this does to the vibe-coding bill, and the cost posts in this blog’s next series take the arithmetic further.
How do AI agents for software development compare?
By the criteria an engineering leader cares about, which are not the ones the listicles rank on. A SWE-bench score says how an agent does on a benchmark’s tickets, not who is accountable when it opens a pull request on yours.
| Kind of agent | Examples | Who is accountable | Where the checkpoints are | What the record shows | How it knows your company | Pricing unit |
|---|---|---|---|---|---|---|
| A YAGNI Agent Team | Bailey, Reeve, Wright, Proctor, Fletcher (beta), Harper | The Team’s owner, with a named supervisor per line | Fixed: accept the proposal, approve the plan, merge; the Ladder per line; deploys and migrations supervised permanently | The case file per ticket, the decision ledger, the Playbook, the track record per line, the cost per run | Reads GitHub, Jira, Linear, Slack, Confluence, and Notion; the ledger and the Playbook | Usage on one rate card, no seats, per developer and per Agent |
| Assistants in the editor | Copilot completions, Cursor tab | The developer typing | Continuous; the developer reads every suggestion | The commit | The open files and whatever the developer pastes | Seat per developer |
| Coding agents in the terminal | Claude Code, Codex, Cursor agent mode, YAGNI Code | The developer who ran it | At the end: the diff | The commit, and a session log if kept | The repository, a CLAUDE.md or AGENTS.md, whatever MCP servers are wired in | Seat plus metered usage, or usage alone through YAGNI |
| Background coding agents | Copilot coding agent, Codex cloud tasks, Jules | Whoever assigned the issue, in practice | At the end: the pull request | The pull request and its thread | The repository and the issue text | Seat plus usage, or credits per task |
Two notes on the table. The terminal agents are not competitors to a Team: a YAGNI Team opens pull requests on the same GitHub a developer’s Claude Code session commits to, and YAGNI fronts Claude Code and Codex on the same meter. The background agents are the closest thing on the market to the third kind, so read their row carefully: the checkpoint is at the end, the accountable person is whoever assigned the issue, and the record is the pull request thread. That is an agent with a long leash, and it is the arrangement that stalls after the pilot.
What does one ticket look like, end to end?
A Team mirrors the Notifications team at a company that sells scheduling software. It attaches acme/notifications, works from the Notifications team in Linear, and posts to that team’s Slack channel. Its owner is Priya, the engineering manager. The plan and build lines are supervised by Priya; Proctor’s review line is autonomous; Fletcher is on.
| When | What happens | Who acted |
|---|---|---|
| Mon 09:10 | Bailey proposes NOT-388, “Stop sending reminder emails for cancelled appointments”, with the evidence: three support threads linked in Linear and a Slack thread from the on-call engineer. Priya reads it in Waiting on you and clicks Start plan. | Bailey, then Priya |
| Mon 09:40 | Reeve plans against the repository: check the appointment’s status at send time rather than at enqueue time, add tests for cancelled, rescheduled, and deleted appointments, leave the enqueue path alone. It cites a Decision from August (reminders are never sent twice per appointment) and a Playbook rule (sender changes ship behind a flag). One question goes to Priya as the product answerer: does a rescheduled appointment get a fresh reminder? Priya answers yes, recorded as a Decision. Reeve’s self-review catches a bypassed status helper and redrafts. Priya reads the plan and clicks Approve plan. | Reeve, then Priya |
| Mon 10:05 | The build line is supervised, so the build waits for Priya’s click. Wright clones the repository into a sandbox, implements the plan behind the flag, writes the three tests, runs the suite, and opens a draft pull request with the plan linked. Each run lands on the case file with its output and cost. | Priya, then Wright |
| Mon 11:20 | Proctor posts one review: changes requested. Deep review: the status check reads from a cache that can be stale for up to a minute after a cancellation. Tests: the cancelled case asserts the email was not enqueued, not that it was not sent. One finding weighed and set aside with its reason, a naming convention the Playbook already covers. | Proctor |
| Mon 11:55 | Wright addresses both findings on a follow-up commit. Proctor follows up: resolved. Verdict: approve. The draft is marked ready with no click, because the review line is autonomous. | Wright, then Proctor |
| Mon 12:30 | Fletcher (beta) boots the repository environment at that revision, writes a test plan from the change, cancels an appointment in the browser, advances the clock past the reminder window, and attaches the video and a verdict: no email sent. | Fletcher |
| Mon 14:00 | Priya opens the case file, reads the plan, the review, the runs, and Fletcher’s evidence, and merges on GitHub. The webhook moves NOT-388 to Done with a Receipt, and Linear closes the ticket because GitHub says the pull request merged. | Priya |
| Tue 06:00 | Harper’s Daily Brief posts to the channel with NOT-388 under “shipped” and the pull request number beside it. | Harper |
Four clicks of Priya’s: the three 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. Priya did not open a terminal, read a transcript, or write a prompt.
How do you roll out AI agents across an engineering org?
One team at a time, with the consequential lines supervised, and let the track record make the case for the next team. These are the steps as we run them on the first call.
- Pick one team. The one with a backlog that has been ready for months and a lead who will read plans. Not the team in the middle of a migration.
- Mirror it as a Team. Attach the repositories that team owns, point the Team at the Jira project or Linear team it already works from, connect the Slack channel it already posts in, and name the engineering manager as owner. The GitHub App installs with your security lead in the room.
- Start conservative. Reeve’s plan line and Wright’s build line supervised, so each waits for a click; a proposal from Bailey always waits for a person. Proctor’s review line starts autonomous because a review cannot merge anything. Turn Fletcher on once the repository environment boots.
- Run two or three weeks of mornings. The owner opens Waiting on you, reads the proposals and the plans, merges what passes, and sends back what does not. Watch the Playbook pick up the reasons for each send-back.
- Read the track record and move one line. Open the record beside Wright’s build line. If it reads 22 of the last 25 merged without a send-back, decide with that in view whether the build line has earned autonomous, so Wright starts an approved plan without a click. Never the merge, because there is no merge line to move.
- Read the Usage page before the next team. Spend per Agent, per line, and per ticket is the case you take to the second team’s lead.
That is the whole rollout. It is how a manager already extends trust to a new senior engineer, with the record written down, and why the second team is easier.
Where does each post in this series go deeper?
This is the hub for the series on Agent Teams for software development. Each post takes one of the questions above further.
- What is the agentic software development lifecycle? The six stages in detail, the three clicks, and what a ticket is doing while it waits.
- What is agentic engineering, and how is it not vibe coding? Managed versus unmanaged agent work, and what the difference costs.
- What is spec-driven development with AI coding agents? The Plan stage: Reeve’s plan, a person’s approval, before a line is written.
- What should a Jira AI agent do with an engineering ticket? One ticket from Jira through the six stages and back, with Confluence as grounding.
- What is AI QA testing, and what should a testing agent do? Fletcher (beta): a test plan from the change, walked in a browser, with the video attached.
- Human in the loop AI agents: where the person actually sits The three clicks, the Ladder, and the floor that never moves.
- Async standup: build it from GitHub and Jira, not forms Harper’s Daily Brief, with a Receipt on every line.
- AI backlog management: propose, don’t auto-prioritize Bailey’s job, and why a proposal always waits for a person.
- Context engineering for coding agents: where the why lives The decision ledger, the connected tools, and the Playbook.
- AI agent audit trail: what the record should show The case file, end to end, against the “log everything” advice.
- AI for engineering managers: manage agents like a team The buyer’s page: a manager’s morning, the autonomy decision, and the budget.
- How to manage AI coding agents and keep them accountable The management frame, starting from the agents your developers already run.
- How to track engineering progress without a project manager Work as the map, the queue, and the log.
Where to start
Keep the agents your developers already run; a terminal agent is the right tool for a developer’s own work. Then bring this guide’s questions to any agent you are considering for delegated work, including a YAGNI Team. Who owns what it does, by name? What does a person read before the work starts, and before it merges? What may it do on its own, and who decided that? What does the record show six weeks later, and what did the ticket cost? If the answers are a named owner, a plan and a review a person can read, a Ladder with a floor, a case file, and a cost per run, you have a team you can manage. If the answers are a pull request thread and a monthly bill, you have an agent with a long leash and a pilot that will stall.
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 in a browser, and Harper reports to Slack, with one accountable owner, every gate addressed to a named person, and merge always a person’s click. The Agents run on vetted US-hosted open-weight models at 60% or more under comparable frontier API rates, on the same meter as your developers, and the Usage page shows what each ticket cost. See how Agent Teams work, or book 30 minutes and we will mirror one of your engineering teams as a Team on the call.