Last night, forty agent runs finished across six repositories. This morning somebody has to decide what to do about them. That sentence is the whole change, and almost nothing in your project management tooling was built for it.

A quick bit of context, in case you have not met the term. AI-DLC — the AI-Driven Development Life Cycle — is a way of running delivery where AI agents do the producing inside a defined process, with humans at fixed decision points. You describe an intent; the system breaks it into units of work; agents build them in parallel; people answer questions and approve things along the way. I have written about what it is and how to secure it before.

This post is about the part nobody warned me about: what happens to project management once that is running. Not governance architecture, not tooling procurement — just the daily business of knowing what is happening and deciding what to do.

The short version is that your board is now measuring the wrong half of the work.

40agent runs overnight
1person deciding about them
0fields in your tracker for that

What every tracker quietly assumes

Jira, and everything descended from it, is built on one assumption so basic it never appears in the documentation: the expensive thing is writing the software.

Once you see it, you see it everywhere. Estimation exists because building is slow and somebody needs a forecast. Assignment exists because building is done by one identifiable person. Velocity exists because building is the bottleneck and you want to know your rate.

All three are answers to the same question — how much can we produce? — and that question has gone quiet.

Left: the old unit of work as one ticket, one engineer, one pull request, one review, producing one unit and one human decision over days. Right: one intent fanning out into four units of work, each an agent run, with still only one human decision but hours rather than days of slack.
The green half multiplied. The violet half did not — and the violet half is the one with a person in it.

Look at the two columns. On the left, one ticket produced one thing and needed roughly one human decision, and there were days of slack around it. On the right, one intent produces four things in parallel, still needs a human decision, and the slack has collapsed to hours.

Producing got cheap. Deciding did not. And your tracker has a field for story points and no field at all for “how much judgement did this consume”, because until recently nobody needed one.

This is also why bolting AI onto a tracker feels helpful but does not move the needle. Atlassian is doing exactly that — a Jira coding agent that turns work items into pull requests, agents wired into the board. It is a sensible product and it will sell. It also speeds up the half that was already fast.

So the backlog becomes a queue of decisions

Here is the reframe that made everything else click for me. Stop thinking of the backlog as a list of work to be done. It is now a list of decisions to be made, and the person running it is not chasing progress — they are adjudicating.

Left: the queue a human works, mixing gates that cannot be undone in red, blocking clarifying questions in amber and reviewer objections in blue, each with an age. Right: old metrics — velocity, story points, cycle time, WIP limit, burndown — struck through and replaced by decision latency, reversal rate, unattended-merge ratio, gate-override count and evidence completeness.
Colour here is consequence, not category. Red cannot be undone. That distinction is the one the queue has to make for you.

Every item in that left-hand column is a person standing in front of several agent runs that cannot continue. The interesting column is the age. A parked run is the new work-in-progress, and unlike the old kind it costs you nothing to store and everything to ignore.

The numbers worth putting on a wall

Velocity tells you very little once you can simply add more agents. Five replacements, in plain terms:

  • Decision latency — how long a stopped run waits for a human. This is your real cycle time now, and the only part of it you actually control.
  • Reversal rate — how often something approved gets undone later. If this is near zero and you have lots of approval gates, nobody is really reading them.
  • Unattended-merge ratio — how much shipped with no person in the path. Not a number to push down. A number to choose on purpose, and then keep an eye on.
  • Gate-override count — how often somebody went round a gate, and who.
  • Evidence completeness — what share of merged work could produce a full record of who allowed it, if asked. Nobody measures this until the first audit, after which it is the only question.

Watch reversal rate first. It is the only one that tells you whether the humans in the loop are doing anything at all.

Four jobs worth hiring for

The clean way to work out which roles survive is to ask what genuinely cannot be handed to a machine. Three things: deciding what should be built, judging the things you cannot take back, and being answerable for the record afterwards.

Four role cards in violet — intent owner, sensor author, adjudicator of record, evidence owner — with the sensor author highlighted in green. Below, a strip of activities that go away: status chasing, estimation, sprint mechanics, manual triage, the standup as a way of reporting.
The strip along the bottom is not a redundancy list. Those activities existed to move information between people who each held one piece of the picture.

The one I want to argue hardest for is the sensor author, because it is the highest-leverage job here and I have almost never seen it staffed.

A sensor, in this world, is just an automatic check that runs at a fixed point and either passes or fails. The sensor author’s job is to take a review somebody keeps doing by hand and turn it into one of those.

The economics are not subtle. A reviewer who catches a class of mistake costs you their attention on every single run, forever. An engineer who converts that review into a check pays once, and the check costs the same whether you run it four times a night or four hundred. Yet the org chart still has reviewers and does not have sensor authors, because “writing the tests the AI has to pass” does not map onto a job family anyone has invented.

That is the hire I would make first, and I would take your best reviewer to do it. (What that person actually writes turns out to be a deep and rather elegant topic, which is its own post.)

The screen is part of the control

Now the bit that surprised me, and the reason a post about project management ends up being about security.

The platforms doing this well already stop an agent run when something is ambiguous and ask a person. Good. But every one of those questions looks identical on screen. A query about whether to call something an invoice or a billing document turns up in the same list, at the same size, with the same button, as an approval that merges to main and hands an agent write access to the billing service.

Left: today's queue, five identical rows each with the same Approve button. Right: the same queue ranked by cost to undo — a red item that cannot be undone showing blast radius and requiring a typed confirmation and second approver, an amber item undone by one commit, and a green item with no consequence and a single click.
Three different levels of consequence, three different amounts of effort to approve. If they all took one click, the ranking would be decoration.

This matters more than it sounds. Attention is a budget with a hard ceiling and no overdraft. A uniform list is, reliably, a uniform-response generator — by the fortieth item a careful, competent person is clicking. That is not a discipline problem you can fix with training. It is what the design produces.

What the screen has to do instead, in six short rules:

  • Sort by what it costs to undo, not by what arrived first.
  • Show the consequence, not the artefact. “Stage 6 requires approval” tells a human nothing. “Merges to main, grants write to billing, touches payments” is a decision.
  • Put the reach of the change on screen at the moment of deciding — which repositories, which secrets, which systems.
  • Make the effort match the stakes. One click for the harmless. A typed confirmation and a second person for the irreversible.
  • Show what changed since the last time they approved something like this. People are poor at absolute judgement and excellent at spotting a difference.
  • Show what is waiting behind it. Someone who knows three lanes are blocked decides differently, and should.

Where this costs you

Decision-queue metrics are unfamiliar and easy to game. Reversal rate especially punishes honesty: a team that reverts a bad change quickly looks worse than one that leaves it in place. Show it next to incident counts or it will teach precisely the wrong lesson.

“Sensor author” is a re-skilling problem wearing an automation problem’s clothes. You are asking your best reviewer to stop doing the thing they are known for. Some will love it. Some will read it as being moved away from the interesting work, and they are not entirely wrong on a bad week.

A criticality banner is only as trustworthy as the model behind it. A confidently wrong “this is irreversible” is worse than no banner, because it spends the credibility you need for the one that matters. Build the inventory of what each step can reach before you build the traffic light.

And if your team ships slowly, none of this applies. If a human still reviews everything and has time to do it properly, your board is fine and I would talk you out of changing it. This whole design is a response to volume you may not have.

What I would do on Monday

  1. Count the decisions, not the tickets. For one week, log every time an agent run stopped and waited for a person. That list is your real backlog, and most teams have never seen it written down.
  2. Run the approval audit. Take the last twenty approvals someone clicked and ask them, without warning, what three of them actually permitted. Twenty minutes. I have never seen this go well the first time, including on systems I designed.
  3. Name the sensor author. One person, by name. Give them your best reviewer’s time and let them turn repeated reviews into checks.

None of those needs a budget, a vendor, or a reorganisation.

The short version

The instruments we built for Agile were answers to one question: can we produce enough? They were good answers. That question has been settled by machines, and the question underneath it — can we decide well enough, fast enough, about things we cannot take back? — has no instruments at all yet.

Building those is the interesting work of the next couple of years, and it starts with something unglamorous: looking at your board and admitting it is measuring the easy half.

I write about this work as it develops. If you are running one of these programmes, I am reachable on LinkedIn, and the tooling I maintain lives under shenril and BlueSquadron.