AI for Engineering Managers: Manage Agents Like a Team
AI for engineering managers: run coding agents the way you run people, with ownership, review, and a record, what to check each morning, and what it costs.
Search “ai for engineering managers” and the first page splits three ways. Vendor guides from Jama Software (June 2026) and Zenhub, which list the manager’s chores AI can take on and end on a product demo. LeadDev how-tos, the most concrete of them a Databricks manager’s account of boosting management impact with AI tools (September 2025), full of good anecdotes about performance reviews and hiring feedback. And a third of the page is degrees and courses. Search “ai tools for engineering managers” and the vendor pitches thin out and the listicles take over: trackers, notetakers, schedulers, analytics.
All of it treats AI as something that helps the manager with the manager’s own paperwork. Useful, and not the hard question. The hard question arrives the week an agent on your team opens its first pull request. Who owns it? What do you look at each morning? What may it do without asking, and how do you decide? What does it show you when it went wrong, and what did it cost?
This post is for the engineering manager asking that question, with a YAGNI Team as the worked example.
What does AI for engineering managers actually mean?
Three different things, and the first page mixes them.
AI for your own work. Drafting the performance review from the pull request history, summarizing the incident thread, turning the planning doc into a proposal. This is what most of the ranking pages mean, and the advice is fine: it saves hours, the judgment stays yours, and you should think twice before feeding a 1:1 transcript to a model nobody on your team agreed to.
The AI inside the tools you already run. As of October 2026, Atlassian’s Jira AI breaks work down and summarizes issues, and Linear’s AI suggests assignees, projects, and labels based on how your team already works. Both are useful inside the tracker, and neither does engineering work.
Agents that do engineering work. Coding agents your developers run in the terminal, such as Claude Code and Codex, and agent Teams that take a ticket from proposal to a pull request on their own. This is the one that changes your job, because now something on the team that is not a person is proposing, planning, building, and reviewing, and nobody has told you how to manage it.
The rest of this post is about the third thing. Everything in it is additive: a YAGNI Team reads the GitHub, Jira, Linear, Slack, and Confluence your team already pays for and ships approved work back into them, and the coding agents your developers already run keep running.
What changes for an engineering manager when agents join the team?
Less than the vendor pages suggest, and in a more specific place. The management job does not change. Its objects do.
The failure mode you are managing against is the unmanaged agent: the pilot that impresses for an afternoon and decays into babysitting because nothing put the agent on the hook.
The cure is the thing you already do for people. An engineering manager runs a team through three mechanisms, and each one has a direct counterpart on a Team of Agents.
| What you do for people | What it is | What it is on a YAGNI Team |
|---|---|---|
| Ownership | A team owns a scope and reports to one accountable lead | A Team mirrors one of your engineering teams, attaches its repositories, works from its Jira project or Linear team, and reports to one owner. That owner is a named person, and every supervised line’s gate is addressed to them by default |
| Delegation | Assign a ticket, agree the approach before the work starts | Bailey, the Product Manager, proposes the next ticket from the backlog with evidence; a person accepts. Reeve, the Staff Engineer, plans it against the real repository; a person approves the plan before a line of code is written |
| Review | Review norms, a reviewer who reads intent, merge by someone accountable | Wright, the Builder, builds the approved plan in a sandbox to a draft pull request. Proctor, the Reviewer, posts one review with a verdict. Fletcher, QA (in beta), walks the change in a browser and attaches the video. A person merges |
| Autonomy | Give a senior engineer more rope, in a scope, after watching them | The Ladder: two rungs, supervised or autonomous, set per line by a person who has read that line’s track record |
| Feedback | Corrections in review, decisions in the planning doc | Corrections become Playbook rules the Team follows next time; product-intent calls land in the decision ledger every Agent reads before it guesses |
| Reporting | The standup, the status update, the Friday summary | Harper, the Chronicler, posts the Daily Brief to Slack: what shipped, what is in flight, what needs a person, with the Receipts attached |
| Budget | The staffing plan, the tooling line, the cloud bill | Usage: spend per developer and per Agent on one rate card, each Agent’s spend broken out by the line that spent it |
Read down the right-hand column and notice what is missing: a new skill. You are doing ownership, review, and a record, as you already do, on a Team whose members happen to be Agents. How to manage AI coding agents makes the same argument from the other direction, starting with the agents your developers already run.
What does the manager’s morning look like?
This is the part no ranking page shows, so here is one morning in detail.
Dana manages the Payments team, six engineers, and owns the Payments Team in YAGNI, which attaches acme/payments and reads the Payments project in Linear. The plan and build lines are supervised by Dana. Proctor’s review line is autonomous, because a review is advice and cannot merge anything. Fletcher is on.
At 8:45 Dana opens Waiting on you. It is the signed-in home: every ask addressed to Dana across the Teams Dana can see, oldest first. There is nothing to scroll and nothing to triage; if it is on the list, it is waiting on Dana. This morning it holds four items.
| Ask | What Dana reads | What Dana does |
|---|---|---|
| A proposal from Bailey | “Retry failed webhook deliveries with backoff”, the oldest urgent ticket in Linear, two customer threads linked, blocked a reconciliation job twice last week | Start plan. The ticket moves to Plan and Reeve picks it up |
| A plan from Reeve, with one question | The plan for PAY-212, citing a confirmed decision from September (webhook payloads are never retried after 24 hours) and a Playbook rule (every retry path ships behind a flag). The question: cap retries at five, or make it configurable? | Answers “five, hard-coded, revisit if a customer asks”, which is recorded as a Decision. Approve plan. Wright starts building |
| A review from Proctor on PAY-207 | One review on the draft pull request, approving, with one finding Wright already corrected in a second commit. Fletcher’s test plan and a two-minute browser video sit beside it | Reads the review, watches the video at the one place Dana was unsure, merges on GitHub. Done means merged, and Linear closes the ticket on GitHub’s say-so |
| A question Reeve routed to Dana as the product answerer | “The retry job needs an idempotency key; the existing payment-intent key is per attempt, not per order. Which should it use?” | Answers in place. The answer lands on the case file and in the ledger, and the plan continues |
Twenty minutes. Three of those asks were the three clicks a supervised ticket takes on a YAGNI Team, accept the proposal, approve the plan, and merge, spread across three tickets at different stages. Human in the loop AI agents walks each click and what a person reads before it.
Then Dana opens Work for the map rather than the queue: By stage lists every ticket in pipeline order with anything waiting on a person first, and Latest is the log, newest event first. At 6 the previous evening Harper had already posted the Daily Brief to the team’s Slack channel, so Dana’s engineers read what shipped and what is in flight before the standup. Async standup covers what that Brief holds and why every line carries its Receipt.
What Dana did not do: read a transcript, open a terminal, or write a prompt.
How do you decide what an Agent may do on its own?
The same way you decide it for a person, with one improvement: the record is written down.
On a YAGNI Team autonomy is set per line, not per Team and not per Agent. The Ladder has two rungs. Supervised means the act waits as a gate addressed to a named person; the copy reads “supervised by Dana” on Work, on the Team page, and in Slack, and any member of the Team may answer, with the record saying who did. Autonomous means the act dispatches on its own and leaves a Receipt.
A new Team starts conservative. Reeve’s plan line is supervised, so each plan waits for its supervisor. Wright’s build line is supervised. Proctor’s review line is autonomous, because its review posts on GitHub as advice and nothing merges because of it. Fletcher is off until the Team’s repository environment is ready.
Beside each line sits its track record: accepted as proposed, edited, sent back, auto-shipped, and reversed, over time. When Dana is deciding whether Bailey’s propose line should run autonomous, the line reads something like “22 of the last 25 accepted as proposed”, and Dana decides with that in view. Nothing moves a rung on its own: a person moves a line with one explicit act, with the record beside it. If an autonomous act is reversed later, that is one more count on the record.
Two things never move. A permanent floor keeps irreversible and high-blast acts supervised at every level: deploys and data migrations cap at supervised, full stop. And merge is always a person’s click. There is no merge line and no autonomous merge; 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 on it at once. That is the brake.
What does the record show when something goes wrong?
The manager’s question six weeks later is “why did this ship, who said yes, and what did it cost”.
On a YAGNI Team every ticket has a case file, and the case file is the record: Bailey’s proposal and the click that accepted it, Reeve’s plan with the decisions it cited and the question it asked, each of Wright’s runs with its cost, Proctor’s review with the findings it set aside and why, Fletcher’s test plan and video, and the merge Receipt with the person’s name on it. Each entry is an artifact a person already read once, at the gate, so it is readable later for free.
Two records sit beside the ticket. The decision ledger holds the product-intent calls people made as the work happened, confirmed or superseded rather than edited, and every Agent reads it before it guesses. The Playbook holds the rules the Team learned from corrections: a send-back on one ticket is a rule the next plan already follows. AI agent audit trail walks one ticket’s record end to end, including the row that answers the question.
What does it cost, and how do you see it?
Not one of the ranking pages answers this, and for a manager who has to defend a tooling line it is half the point.
A YAGNI Team’s Agents are metered on one rate card, the same one your developers use for YAGNI Code, or for Claude Code and Codex routed through it. There are no seats: a person with no usage costs nothing, and the only cost claim YAGNI makes in public is the floor, vetted US-hosted open-weight models at 60% or more under comparable frontier API rates. The rate card itself is shared on a call.
What that buys a manager is the Usage page: spend, the parked-at-frontier benchmark, and savings, per developer and per Agent, with each Agent’s spend broken out by the line that spent it. Dana can answer the questions a budget review actually asks. What did the propose line cost last month? What did PAY-212 cost end to end? Was the plan send-back cheaper than the build it prevented? A daily spend ceiling sits in Workspace settings for the month the answer is “too much”.
That is the difference between a bill with one line on it and a cost a manager can manage. AI backlog management shows the same per-line view on Bailey’s work.
Which AI tools should an engineering manager look at?
Judge each kind by the criteria a manager cares about, not by the demo.
| Kind of tool | Who is accountable | What the record shows | What stays gated | How cost shows up |
|---|---|---|---|---|
| A writing assistant for your own drafts | You, for every word you send | Nothing, unless you keep it | Everything; it is a draft | A subscription, per person |
| The AI inside Jira or Linear | The ticket’s assignee | The tracker’s history | Edits to tickets | Bundled with the plan, or credits |
| Coding agents your developers run (Claude Code, Codex, Cursor) | The developer at the keyboard | The commit, if it is written up | Whatever the developer gates | A seat plus metered usage, hard to see per person |
| A YAGNI Agent Team | The Team’s owner, with a named supervisor per line | The case file per ticket, the decision ledger, the Playbook, the track record | A person accepts, approves, and merges; the floor keeps deploys and migrations supervised | Usage per developer and per Agent, on one rate card |
Keep the first three. A YAGNI Team replaces none of them: it reads the same tracker, opens pull requests on the same GitHub, posts to the same Slack, and adds the fourth row, the management frame around agents doing engineering work.
Where do you start?
Pick one team, the one with a backlog that has been ready for months. Mirror it as a Team: attach its repository, point it at the Linear team or Jira project it already works from, name yourself the owner, and leave every line supervised. For two or three weeks, do the morning above. Read the plans. Merge what passes. Send back what does not, and watch the Playbook pick up the reason.
Then open the track record beside the propose line and decide, with the numbers in view, whether Bailey has earned autonomous. You will have made that call a hundred times for people. It is the same call.
YAGNI runs agent teams, managed like your engineering team: Bailey proposes, Reeve plans, Wright builds to a draft pull request, Proctor reviews, Fletcher (beta) tests 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. See how Agent Teams work, or book 30 minutes and we will build the first Team with you on the call, mirrored on one of your own engineering teams. The guide to AI agents for software development is the long version of this page’s argument, with the six Agents and the comparison table.