What every AI-authored change costs you in senior review hours, and how to buy that cost down.
Most organisations book a coding agent as a productivity gain and leave review as a background activity nobody owns a number for. This worksheet produces that number and then attacks it. Forward it to engineering, finance, or procurement as-is.
The percentage thresholds in this worksheet are author heuristics for discussion, not measured universal review-cost limits. This is a conceptual worksheet outside the runnable PAAN series; it has no assigned series slot.
Four inputs. You already have all of them.
| Input | Where to get it | |
|---|---|---|
| A | Agent-authored changes reaching review per week | Your PR tooling, filtered by agent author |
| B | Senior minutes spent approving each one | Ask three reviewers for an honest median, not an average |
| C | Loaded senior day rate | Finance already holds this |
| D | Agents planned in the next 12 months, as a multiple of today | Your own roadmap |
Weekly review cost = (A x B / 60) x (C / 8)
Annual = weekly x 52. Projected = annual x D.
If you cannot fill in B, that is the finding. It means approval work is real, is being done by your most expensive people, and has never been measured.
Review cost is downstream of one decision: how much the agent is allowed to express. A wider surface means more wrong things are possible, and every possible wrong thing is somebody's afternoon.
List every agent in your estate against this table.
| Write surface | What the agent can express | What reaches a human | Narrower option |
|---|---|---|---|
| Open shell, free file writes | Anything the filesystem allows | Every error class, plus the intent | Scope it to task specific commands |
| Free-text edits to source | Any change that is syntactically expressible | Stale edits, wrong symbol, broken syntax, plus the intent | Type-checked or structure-checked patches |
| Schema-validated config diff | Only configs that parse | Semantic intent only | Add a policy check on which keys may change |
| Typed migration command | Only the declared operations | Intent only | Already narrow, leave it |
The pattern: a gate judges output and a sandbox limits blast radius, but both run after the agent has written whatever it wanted, and both add a checkpoint you keep paying for. Narrowing the surface retires the checkpoint.
- Review cost under 5% of the team's loaded cost. Fine. Re-run when D changes.
- 5% to 15%. Your reviewers are the constraint on agent throughput. Adding agents will not add output. Narrow the two widest surfaces first.
- Above 15%. You are paying senior salaries to sort machine output. Treat write-surface reduction as a funded project, not a cleanup task.
- Cannot compute B at all. Start there. Instrument one team for two weeks before buying another agent.
The cheapest review is the one the write surface made unnecessary. Narrow what an agent can say, and you buy that cost down permanently, without hiring a single reviewer.
Companion to Zerolang: Vercel's Agent-First Language and Your Review Cost.
- Added explicit source/version/test scope; corrected the reviewed maintenance item.