More PRs can tell you the agents are busy. They don't tell you whether more software made it through review.
A study of engineering activity at 718 firms through March 2026 looked at agent adoption, coding activity, review, and completed work. The associated Ars Technica report describes more code, commits, and PRs alongside a 49% rise in review time and nearly twice as many requested changes. It reports no statistically significant increase in issue or epic completion. That's an observational finding at the firm level, not evidence that agents caused every extra review minute or that your team's output went down. The report and the paper describe the same study, not two independent tests.
Code generation can get cheaper while review still takes time. A prettier stream of generated code won't fix that.
Make the task, not the transcript, the unit of review
A live transcript shows what the agent is doing. A reviewer needs to know which task the change belongs to, what it touched, which checks ran, and what decision is waiting on them.
Imagine a frontend agent asked to change the empty state of a billing screen. The review card shouldn't lead with tokens produced or a cheerful "done" badge. It should lead with the branch or worktree, the changed route, a diff, the checks required for this kind of change, and the result of each check. A screenshot of the empty state is useful. It doesn't show whether the keyboard can reach the retry button or whether the loading state regressed.
I'd model the card as a projection of a small task record, not as an agent-written summary:
Task: Billing empty state | worktree: billing-empty-state
Change: billing route + empty-state component
Checks: typecheck PASS; UI test FAIL; keyboard check NOT RUN
Evidence: diff, test output, preview of empty state
Approval: not requested
Disposition: blocked; reviewer has not accepted this change
That is an illustrative design, not a tested product. The important detail is that FAIL and NOT RUN come from check records, not the agent's confidence. A preview should point to an artifact tied to this revision; if the branch changes, the old screenshot should not silently pass for current evidence.
Status should follow evidence
One DEV.to proposal describes an IDE as a control tower for agents in separate worktrees, with visible active, blocked, approval, and review states. That's a useful UI hypothesis, not proof that a dashboard improves throughput.
The smallest useful contract beneath such a UI might record a task ID, revision, worktree, required checks, check-run results, evidence pointers, pending approvals, and the human disposition. Then the interface can derive states without turning the agent's prose into authority:
- A required check fails: show blocked, the failing output, and the revision that produced it.
- A privileged action needs permission: show awaiting approval, with the exact action and scope. Don't treat permission to run a command as acceptance of the resulting PR.
- Required checks pass and evidence is attached: show ready for review, not "shipped." A person can still request changes.
For the billing example, a failed UI test should send the session back to repair or to a reviewer who can diagnose it. If the test cannot run, preserve NOT RUN and the reason. If an agent wants to retry with a different package or permission, that is a new approval question. If the diff drifts beyond the task, stop the run or revert the branch rather than blessing the old review card.
On a blocked task, show the failing check first. On an approval request, show the permission scope first. Keep the underlying event and check records stable so a rendered card cannot rewrite what happened. If you're comparing presentation patterns for agent-facing products, Generative UI interface examples offer design references; they aren't evidence that generated UI makes a review process reliable.
Count verified delivery, not typing speed
A review surface may not shrink review time. It might reveal checks you've been quietly skipping, which is more useful than a board full of green "completed" cards whose checks never ran.
Track each task through proposal, evidence, human review, and accepted delivery. Keep failed and unrun checks visible. Then measure how many tasks made it through that sequence and how much reviewer time they took. Typing speed can wait.
Source notes
- Software-production bottlenecks study — observational firm-level analysis; it does not test the proposed review UI.
- Ars Technica's report on the study — source of the reported review-time and change-request figures; coverage of the same study.
- DEV.to control-tower proposal — product/workflow perspective, not measured effectiveness.
- Hacker News discussion of the study — practitioner reactions, not independent productivity data.
Top comments (0)