AI agents can now implement features, write tests, search a repository, evaluate a diff, run checks, identify regressions, and propose fixes faster than a traditional development team can coordinate a sequence of pull requests. That changes the economics of code. It does not change accountability.

The central question for modern software delivery is no longer, “Which developers approved this code?” It is: “Which human understands the outcome end to end, directed the right agents and controls, evaluated the evidence, and owns the result in production?”

That person is the lead, architect, or senior practitioner accountable for the feature or system boundary.

A Short History of 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

I would not call Multics the unquestionable origin of code review. Informal practices are difficult to date. But it is early evidence of 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.

The Human in the Loop Is Now the Accountable Owner

In an agent-assisted team, there should be one named human accountable for a meaningful feature, system boundary, or release decision.

That person may not write every line of code. They should not need to.

Their responsibility is to understand the end-to-end behavior, establish the design and acceptance criteria, keep agents within explicit scope, permissions, architectural boundaries, and operational guardrails, evaluate the evidence, decide whether the remaining risk is acceptable, and own the production outcome.

The accountable human is not a ceremonial approver. They are the person who decides what the agents are allowed to do, what they must prove, what risks require more investigation, and what must not enter the system.

This does not mean one person must personally inspect every file or become an isolated hero. It means one person owns the final engineering judgment. For high-consequence changes, that person may still require security, privacy, operations, or domain specialists to provide independent human approval. Accountability can be clear without pretending that one person knows everything.

Code Review Becomes an Agent System

Code review remains necessary, but it no longer has to be a slow, generic human ritual.

Agents can perform specialized review work. One can compare implementation against the specification. Another can search for security and authorization failures. Another can inspect tests and regression risk. Another can check architectural boundaries, dependency policy, documentation, performance, or operational readiness.

These agents can review the work of implementation agents, provide specific findings, and send the change back for correction. They can do that continuously and at a scale that traditional human-only review cannot match.

That is still code review. It is simply code review delivered as a set of specialized controls.

The accountable human does not need to duplicate what these agents do well. Their role is to ensure the checks are appropriate, independent, and credible. An implementation agent should not merely certify its own work. The review system must challenge the assumptions that produced the change.

Approval therefore no longer means, “I read every line.”

It means, “I understand the intended outcome, I know the boundaries this change must respect, I have reviewed credible evidence from independent checks, I accept the remaining risk, and I own the result.”

Bugs Are Feedback About the Delivery System

No review process eliminates every defect. Fagan’s work 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 requirement unclear? Was the design incomplete? Was a test missing? Did an agent lack a constraint? Did the review focus on the wrong risk? Was the system difficult to observe, diagnose, or roll back?

The response should not merely be a patch. It should strengthen the system that produced the patch: a clearer specification, a better test, a more explicit agent guardrail, an improved review mandate, stronger observability, or a tighter release control.

This is why the accountable human matters. Agents can find issues and correct code. They cannot own the organizational decision that the evidence was sufficient, the risk was acceptable, and the system was ready to operate.

The New Meaning of Code Review

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 remains valuable. But agents now allow much of the mechanical analysis to happen continuously, in parallel, and with specialized focus.

The modern model asks a different question:

Is there a named human who understands this change end to end, has kept the agents on the intended path, has directed the right review controls, has evaluated the evidence, and is prepared to own the outcome?

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

Accountability cannot be.