500 hours of engineering. Done in 10.

A product team we work with had been carrying the same backlog for months. Not because the bugs were hard — because the bugs were slow. Every single one had to be read, reproduced, prioritised, fixed, reviewed, security-checked and visually verified before anyone could merge it. Eight steps, each with a queue in front of it.

Today we pointed a fleet of agents at that backlog. Ten hours later, 50 issues were fixed, reviewed and sitting in merge-ready pull requests.

It started as a spreadsheet

The issues did not arrive in a tracker. They arrived in a spreadsheet: 150 rows, inconsistent severity labels, the same bug filed three times by three different people, and a "Notes" column quietly doing the work of six proper fields.

The usual advice here is a cleanup sprint — normalise the data, migrate to a real tracker, agree on a taxonomy, then start work. That advice costs a fortnight before a single bug gets fixed.

We imported all 150 rows as they were. No cleanup sprint, no schema migration, no new tool for the team to learn. Deduplication and severity became the first agent's problem, which is exactly the kind of judgement work it is good at.

Then it became a line

What we deployed is not one agent with a big prompt. It is a line — eight gates, each owned by a specialist that does one job and hands the work forward with something the next gate can use. An agent that only reproduces bugs gets very good at reproducing bugs.

Why two gates stay human

The obvious next move is to automate the two ends as well. We deliberately did not.

Reporting stays human because a bug report is a claim about what the product was supposed to do. That is a judgement about intent, and intent lives with the people who use and build the thing.

Merging stays human because someone has to own what lands on the main branch. An agent that can both write a change and merge it has no gate left above it.

Everything between those two points is mechanical. Mechanical work is exactly what the fleet is for.

Three agents sit beside the line

Not every agent belongs in the sequence. Three of them work alongside it and get called on demand, which keeps the line itself simple.

• Coordinator

  Routes work between gates, notices when something has stalled, and decides what the fleet picks up next.

• Product Help

  Answers the question that stops most triage cold: is this a bug, or is it the intended behaviour? Reads the product docs so the line does not have to guess.

• Tech Help

  Knows the codebase — architecture, conventions, the reason that odd module exists. Keeps fixes idiomatic instead of merely correct.

What ten hours bought

• 150

  issues imported straight out of a messy spreadsheet

• 50

  of them fixed, reviewed and PR-ready inside day 1

• 500hrs

  of engineering work, delivered in 10h on the clock

That 500-hour figure is the team's own estimate of what those 50 issues would have taken them, at their historical pace, through their normal review process. It is the backlog they had been carrying for months.

What it did not do

The honest part. 100 issues are still moving through the line — day one cleared a third of the import, not all of it.

Several fixes bounced at PR Review more than once, which is the gate doing its job rather than failing at it. A handful went back to the human reporter untouched, because the report itself was ambiguous: the fleet is good at fixing bugs and deliberately bad at guessing what someone meant.

And nothing reached the main branch without a person reading it first. That was true at hour one and it is still true now.

The part worth repeating

The team did not change tools, did not clean their data first, and did not restructure how they work. They kept filing bugs the way they always had and kept merging them the way they always had.

The eight steps in between stopped being a queue.