When Agents Write the Code, the Approval Button Stops Meaning Anything

The assumption that quietly broke

Code review rests on a premise so old nobody says it out loud: another engineer wrote the code. An essay published on DEV.to argues that premise is no longer reliable. A coding agent can now implement a feature, run the tests, fix the failures, refactor the result and prepare the pull request. The human who opens that PR may have spent their time directing and reviewing the agent rather than typing anything.

The author's conclusion is not that review is obsolete. It is the reverse — verification matters more than ever. What has broken is the accounting. In the old flow, Engineer A writes, Engineer B reviews, the change merges. In the agentic flow, the agent writes, Engineer A reviews, Engineer A opens the PR. If Engineer A genuinely examined the change and is willing to own it, the essay asks what a second generic human approval actually adds. Opening a PR does not make code more trustworthy. The meaningful event happened before the button existed.

What the review was actually buying

Review has always done two jobs at once. The first is defect-finding: a second person catches a bug, spots a wrong abstraction, questions an architectural call. The second is social — shared ownership and distributed knowledge, so the code does not belong to one person. The essay grants both remain valuable. But it argues they are not equally served when the author is a machine.

The mental model it offers is the flawed peer: imagine a colleague who is extremely fast, knows an enormous amount about software, and is inexperienced in your particular system, occasionally making mistakes that look obvious in hindsight. You would not merge their work blind. You would set constraints, run automated checks, and pull in a specialist for the changes that matter. That, the author notes, is already what agentic workflows look like.

Hence the line that should make engineering managers uncomfortable: the number of approval buttons pressed is not the same thing as the amount of verification performed. Teams that required one review might reasonably treat a thoroughly reviewed agent change as complete. Teams requiring two might keep one post-PR reviewer. The policy should track risk — a database migration, an authentication change or a payments workflow is not a button label.

The bottleneck moves; it does not vanish

The larger stake is volume. Generating code has become dramatically cheaper. Reviewing it has not. If an agent produces ten times more code and the answer is to have humans inspect ten times more code, the constraint simply relocates from writing software to verifying it. Human attention is the scarce input, and it cannot be bought at agent prices.

The essay's answer is to shrink what needs human eyes at all. Some bug classes should not depend on a reviewer noticing them — they should be impossible to express. A database constraint enforces a rule so no developer has to remember it. A workflow that can only move from Pending to Approved or Rejected should be modelled as explicit states, not arbitrary strings that every code path hopes to handle. Finite state machines, types, contracts, API boundaries, static analysis and generated code all do the same work: the goal is not to make developers more careful, it is to make certain mistakes impossible.

On top of that sits automated verification, then the engineer who takes ownership, then an optional layer the author calls adversarial agents — specialists whose job is not to say LGTM but to attack. A security agent hunting for authorisation bypasses and injection paths. A performance agent looking for N+1 queries, contention and excessive network calls. Others for reliability, backwards compatibility, API design, testing, accessibility. They prove nothing; they are flawed peers too. What they offer is another independent attempt to find a problem, assembled per change rather than applied uniformly. Verification becomes composable: more scrutiny without a longer delivery cycle or more humans in the queue.

Who is exposed by this? Any team whose quality story is really a compliance story — two approvals on every PR, regardless of risk. That policy will keep producing green checkmarks while the volume of unexamined code underneath it grows. And the social function of review, the knowledge-spreading part the essay explicitly says still matters, has no obvious replacement if the second reviewer is removed for efficiency and nothing is put in its place.

Questions You Should Be Asking

• When your engineer opens a PR for agent-written code, can they explain why the implementation is shaped that way — or only that the tests passed?
• Which of your current review rules exist because they catch defects, and which exist because an auditor or an incident report demanded a number?
• How much of what your reviewers check by eye could be enforced by a schema constraint, a type, or an explicit state machine instead — and who owns that work?
• If you drop the second human reviewer, what replaces the knowledge-sharing that review was quietly doing for your team?
• When an adversarial security or performance agent says nothing is wrong, what does your team believe that means — and is that belief written down anywhere?

What To Watch Next

Watch whether teams start differentiating their review policy by change type rather than applying one approval count to everything. The tell is a migration, an auth change or a payments path getting a visibly heavier verification pipeline than a UI tweak. If approval counts stay flat while merge volume climbs, the policy has become theatre — and the first incident traced to code nobody actually read will be the one that proves it.