I have been saying for a while that the scarce skill was never typing the code. My career is not writing software . Agents have now made that obvious. They can implement a feature, write the tests, search the repo, evaluate a diff, and propose a fix faster than a team can line up pull requests. That changes the economics of code. It does not change accountability.

I ended the spec-first post by asking who really wrote the requirement , because that person — not the agent — decided what got built. This is the rest of that answer. One named human owns a meaningful feature, system boundary, or release. They may not write every line. They should not need to. They set the spec, keep the agents inside it, look at independent evidence, and own what ships.

Why Review Exists

Code review did not begin with pull requests.

The earliest documented practice I can verify comes from the mid-1960s CTSS and Multics community, a collaboration involving MIT, General Electric, and Bell Telephone Laboratories. Developers described reading one another’s code, openly reviewing designs, and later auditing source changes before installation. Their culture treated the system as a shared responsibility rather than the private property of its original author. Multics development process

That is the principle that still matters: software must be understandable, maintainable, and safe to change by people other than its author.

The first widely published and rigorously studied formal review method came in 1976, when IBM’s Michael Fagan published Design and Code Inspections to Reduce Errors in Program Development. Fagan inspection introduced explicit roles, preparation, meetings, rework, follow-up, and defect data. Its purpose was clear: find errors early, fix them closer to their origin, and use the findings to improve the development process. Fagan, 1976

So code review was absolutely designed to find bugs. But it also forced code to communicate. When another engineer has to understand a change, names matter. Boundaries matter. Tests matter. A shortcut that only makes sense to its author becomes visible as future maintenance risk.

Review turned private implementation into a shared engineering decision.

Review Becomes an Agent System

In the workshop I run, the human sits at two checkpoints: is this the right spec? and is this the right code? Everything between those checkpoints is crank-turning. Agents can now do more of the reading that used to wait for a pull request. One compares the implementation to the spec. Another looks for security and authorization failures. Another inspects tests and regression risk. Another checks architectural boundaries, dependency policy, and whether the change is operable.

They can review the work of implementation agents, send specific findings back, and do it continuously. That is still code review. An implementation agent should not certify its own work. The checks have to be independent, and they have to be allowed to reject the change.

I do not need to duplicate those passes. I need to know they ran, that they were the right ones, and that I am looking at the artifacts that actually matter: the wording of the requirement, the red bar, the diff after green, and whether the change weakens a control I already decided the system must have. Where security starts was about recognizing insecure code before it becomes production code. That question does not disappear because an agent wrote the patch.

The owner is not a ceremonial approver, and they are not an isolated hero. They decide what the agents are allowed to do, what they must prove, and what does not enter the system. For high-consequence changes I still want another human — security, privacy, operations, or a domain specialist. Naming one owner is not a claim that one person knows everything. It is a claim that someone can be named when the result is wrong.

Approval is no longer “I read every line.”

It is: I understand the intended outcome, I know the boundaries this change must respect, I have looked at credible evidence from independent checks, and I own the result.

Bugs Are Feedback About the Delivery System

No review process eliminates every defect. Fagan measured defects found during inspection and defects that still escaped. The goal has never been perfection. The goal is to reduce risk early and learn before failures repeat.

A bug found before release is not proof that the system failed. It is evidence that a control worked.

A significant defect that escapes to production is a signal to examine the delivery system. Was the spec unclear? Was a test missing? Did an agent lack a constraint the review never asked it to prove?

The response should not merely be a patch. It should strengthen the system that produced the patch: a clearer specification, a better test, a tighter agent guardrail, or a review mandate aimed at the risk that actually escaped.

Agents can find issues and correct code. They cannot own the decision that the evidence was sufficient and the system was ready to operate.

The old model of code review asked whether another developer could understand a change well enough to approve it and help repair it later. That still matters. Agents now let much of the mechanical reading happen continuously, in parallel, and with specialized focus.

Code may now be generated, tested, and reviewed by agents.

Accountability cannot be.