Build1 publisher3 min readPublished
Agent-written code moves the first human review to the engineer who opens the pull request
Engineers who review and own an agent-written change can count as a team's one required human approval, a dev.to essay argues. That puts the guarantee on the owner's own review, so teams need a record of what the owner checked before they cut approval counts.
The Engineer · Build desk
What happened
- The author says code review has always assumed another engineer wrote the code, and that this assumption is becoming less reliable.
- Agents can now implement a feature, run and fix tests, refactor and prepare the PR, leaving the engineer who opens it mostly reviewing and directing.
- For teams that required two human reviews, the essay suggests counting the owner's review plus one more human review after the PR is opened.
- The author treats agents as flawed peers: fast and knowledgeable, but inexperienced in a given system and prone to mistakes that look obvious in hindsight.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Teams with a one-approval rule now have to decide whether an owner's pre-PR review of agent output satisfies it, and the essay ties that call to each system's risk and the kind of change.
- exposure In an owner-only flow, an agent error the owner also misses reaches the main branch with no independent reader, and the essay's own model expects agents to make such errors.
- cost Dropping the second reviewer also drops the shared team knowledge the essay credits review with, leaving one person who has read the change.
The dev.to essay's case rests on a side-by-side of two pipelines. In the old one, Engineer A writes the code, Engineer B reviews it, and it merges. In the agentic one, an agent writes the code, Engineer A reviews it, Engineer A opens the PR, and it merges [3]. Under a one-approval rule, both pipelines put exactly one human in front of code that human did not write [1]. Opening the PR adds nothing, the author wrote: "The PR being opened does not magically make the code more trustworthy." [9]
I think the author has the count right. The author wants more checking, and wrote that "we need verification more than ever." [2] "The number of approval buttons pressed is not the same thing as the amount of verification performed," the author wrote [8]. A required-approval rule counts clicks and has never known who wrote the code. What it was meant to buy was one independent reader, and in the agentic pipeline the owner is that reader for the agent's output [1].
The weak point is the condition attached to the proposal. The author asks what a second generic review gains if Engineer A has "genuinely reviewed the implementation, understands the change, and is willing to take ownership of it" [4]. In the old pipeline, testing that condition was part of Engineer B's job. The essay's own list of what a reviewer does includes catching a missed bug, spotting a wrong abstraction, finding an edge case, questioning an architectural decision, and asking why something was built a particular way [10]. That last question is how a reviewer finds out whether the author understands the change. In an owner-only pipeline, the person who claims to understand the change is the same person who certifies it.
The essay's answer is cultural. When an experienced engineer opens an agent's PR and says "I am happy to own this", the author wrote, "I think we should take that statement seriously." [11] The author also argues that "ownership without trust is difficult to achieve." [17] Both are fair points about how teams work. A merge gate also needs something a teammate can inspect after the fact, and a statement of ownership leaves only the statement.
The essay already contains the parts that would fix this. Its model of agents as flawed peers comes with a workflow: review the work, give clear constraints, run automated checks, and send particularly important changes to another specialist [14]. Constraints, check results and specialist sign-off all leave records. In my view the owner's review should leave one too: which files were read, which tests were added or changed, which edge cases were tried. The author does not specify what an owner's review must contain. Until it produces that kind of record, I would keep a second human reviewer on any system where a missed edge case is expensive.
What to watch
- Defect rates on agent-written changes merged after one owner review compared with those that also got a second reviewer; that comparison would test the essay's claim directly.
- Whether teams adopting owner-counts-as-review policies define what the owner's review must record, such as files read and tests added, before an agent-written PR can merge.
- Whether review tooling starts recording that a change was agent-authored, so approval rules can treat those changes differently from human-written ones.