Most teams introduce a coding agent backwards. They hand it a ticket, let it edit the repository, and only then ask a human to figure out whether the patch is correct.
The model gets the fun job. The reviewer pays the reverse-engineering tax.
Start with review instead. If an agent can find a concrete problem, attach evidence, expose its uncertainty, and give a human a cheap way to confirm the result, it has already created value. It can prove that value before the team makes code authorship its default role.
Review can pay before the agent writes code
A recent TechRadar report about Linux kernel work draws a useful line. It describes AI review and analysis agents surfacing actionable bug reports, while humans write the fixes and maintainers retain judgment over what lands.
That is one reported workflow, not proof that AI review is universally accurate or cheaper. The role split is still worth examining: the agent can reduce uncertainty without owning the patch.
Authorship bundles several questions together. Did the agent understand the bug? Did it choose the right fix? Did it preserve unrelated behavior? Did its tests prove what it says they proved? A generated patch forces the reviewer to answer all of them at once.
A review finding is narrower. The agent can point to one behavior and the evidence behind it. A human can confirm or reject that finding without first untangling a proposed implementation. False positives still cost time, but a compact, falsifiable report limits that cost.
The first test is whether the agent can make a decision easier before it starts changing code.
"Reviewer" is a workflow, not a prompt
Telling a model to "review this repository" is barely more specific than telling it to "write good code." Useful review needs a bounded surface, an environment that can produce evidence, and an output that another person can inspect.
Proliferate is a concrete product signal here. Its project documentation lists isolated worktrees or sandboxes, diff review, and reviewer agents as parts of the operating surface for multiple coding harnesses. The README does not prove that those reviewers are accurate or production-safe. It does show that review and isolation are becoming explicit product features rather than chores left outside the agent loop.
The surrounding controls matter as much as the reviewer model:
- Give it one commit, diff, subsystem, or execution path to inspect.
- Let it run named checks in an isolated environment when the finding depends on behavior.
- Preserve test output, traces, browser observations, and repository history with the report.
- Require it to stop when missing context prevents a defensible finding.
The same operational concerns appear in practitioner guidance about production coding agents: tests, Git history, prompts before destructive actions, explicit verification, and knowing when to stop. Those are not benchmark results, but they are better selection criteria than raw generation quality.
A reviewer with unlimited scope and no stop condition will produce commentary. A reviewer with a defined surface and inspectable evidence has a chance to produce a decision.
Require a review receipt
A confident paragraph is not a review artifact. "There may be a serious race condition" gives the next person a claim to investigate and no cheap way to investigate it.
Require a small receipt for every finding:
- Finding: one concrete issue rather than a broad quality opinion.
- Location: a file and line, execution path, or observable behavior.
- Evidence: a test, trace, command output, diff, or browser observation another person can inspect.
- Impact: what can fail and under which conditions, without inflating severity.
- Uncertainty: assumptions, missing context, and plausible alternative explanations.
- Next check: the smallest action that confirms or rejects the finding.
This is a proposed working format, not an industry standard. It makes a weak finding cheap to reject.
Consider a hypothetical service with a role-change endpoint and cached authorization. A useful agent report could look like this:
Finding: A removed project member can retain the previous permission until the cache entry expires.
Location: The role-update path returns before the existing authorization cache is invalidated.
Evidence: After a successful role removal, the named integration scenario still receives a 200 response for the protected project request. The trace and test output are attached.
Impact: Access may remain stale for the configured cache lifetime after this update path.
Uncertainty: The report has not established whether a background invalidation event is expected to close the gap.
Next check: Run the same scenario with the invalidation worker enabled and inspect whether it receives the role-change event.
The agent has not proved the architecture is insecure, and it has not earned permission to rewrite the cache layer. It has produced a specific claim with a short rejection path. A maintainer can inspect the trace, check the event flow, and decide whether a patch is needed.
A review that cannot fill the receipt should not silently graduate into an agent-authored fix. It should return the missing evidence or context.
Domain context belongs inside the evidence loop
Frontend review makes the weakness of vague judgment obvious. "This page looks wrong" is not a finding. Neither is "make it feel more polished."
The reviewer needs a selected reference for the intended interaction, a named design-system constraint, a browser observation under stated conditions, and a next check. For generated interfaces, a curated set of Generative UI cases can help a team choose relevant examples and translate them into its own observable criteria.
The examples are reference material, not proof and not an automated acceptance oracle. The team still has to state what matters in its product. That might be keyboard order, component usage, overflow at a named viewport, or the behavior of a streamed state transition. The agent's job is to compare the implementation with those declared constraints and show the mismatch.
This is why domain context should be attached to the review task instead of hidden in a prompt like "use good UX." References become useful only after the team turns them into checks that can fail.
Let the agent climb the role ladder
Authorship does not need to be the starting position. Increase the agent's ability to mutate the repository only after its output is useful at the previous step:
- Explain a bounded area of the code and cite the relevant paths.
- Reproduce one reported behavior without changing the repository.
- Review a selected diff or execution path and produce a receipt.
- Suggest a patch inside an isolated workspace, with the finding and evidence kept beside it.
- Author a bounded change when the team can evaluate both the diagnosis and the result.
Advancement should stay local to the workflow. An agent that reviews dependency updates well has not earned a global trust score for authentication changes. A good result on a backend test does not prove it can judge a generated interface.
Ask practical questions at each step. How many findings did maintainers confirm? How quickly could they reject the wrong ones? Did the report remove uncertainty, or did it create another document to decode? These are evaluation questions, not universal metrics. Teams can answer them with their own repository history instead of importing a multiplier claim.
Authorship then becomes a downstream privilege. The agent already knows how to locate evidence, state uncertainty, and stop when the task exceeds its context. The patch is connected to a diagnosis that survived review rather than appearing as the first artifact in the process.
More output will not repair expensive review
Current developer discussion is skeptical of generation volume without validation. A Hacker News thread built around the "2x, not 10x" framing pushes toward experiments, constraints, and review. A Reddit post describes spending more time tuning models, harnesses, MCP tools, and prompts than completing the work the stack was meant to help with. Both are community sentiment, not measured productivity evidence.
That frustration suggests a narrower move. Adding another authoring agent can increase the amount of code waiting for judgment. A focused reviewer can work on the expensive part directly by making one claim easier to inspect.
The team that started by granting write access needed a finding a human could confirm, not a patch the human had to decipher. Once the agent can repeatedly make review cheaper for a named workflow, letting it propose the fix becomes a smaller step.
If it cannot make review cheaper, letting it generate more code only increases the bill.
Top comments (0)