AI Writes Code Faster Than You Can Read It. Line-by-Line Review Can't Keep Up.

As a programmer who embraces open source and has long believed that "code must be read by a human before it can be merged," I know exactly how much this statement goes against the ancestral creed.

When we used to talk about Code Review, the default picture was clear: a colleague finishes a change, another person opens the diff, reads it from beginning to end, points out problems, adds context, confirms the design, and clicks Approve. This process supported software engineering for years, and it genuinely worked. It was not just about finding bugs. It was about sharing context, passing down design judgment, and building trust within a team. In a healthy team, you can often see from the review history how the architecture evolved and who is responsible for which modules.

But AI is tearing down the premises of this process one by one.

The speed at which agents write code has already far exceeded the speed at which humans read code. In the past, one person might spend several days writing a change, and another person could still spend half an hour reviewing it carefully. Now an agent may generate a sizable change in minutes, and manual line-by-line review immediately becomes the slowest bottleneck in the entire development pipeline. What is more troublesome is that people are not only unable to finish reading; they may also be unable to understand. In the past, developers implemented features with their own hands, were familiar with technical details, and knew where trade-offs had been made, so they could spot risks from a few lines of change. As more code is handed to agents, people's familiarity with the code is inevitably weakened. The same change that could once be judged after a few glances may now require re-sorting the related logic. Even after reading every line, they may still be unable to judge the impact of the change.

So the question is not whether Code Review still has meaning, but whether we should still spend our scarcest human attention evenly, line by line, on every single change now that the speed and scale of code supply have changed by orders of magnitude.

The answer is clearly no.

Why the ancestral creed once held

Code Review has never been an isolated link. From the moment a change is written to the moment it is delivered to users, it usually goes through multiple layers of protection: Code Review, automated checks, testing and acceptance, and canary release. Code Review handles the part that depends on human experience, judgment, and contextual understanding: whether the implementation and design are reasonable, whether anything has been missed, whether enough context has been shared. Recurring problems can be turned into team conventions or automated checks.

It worked for a long time because several implicit premises held.

First, the person writing the code understood the requirements and implementation, and the reviewer could quickly reconstruct context through the diff.

Second, architectural boundaries were relatively clear, and the impact of a change could roughly be judged.

Third, testing, canary release, monitoring, and rollback could cover some of the post-launch problems.

Fourth, and most importantly: we trusted our colleagues. Not blindly, but because they had written the code with their own hands, understood the requirements, and were clear about the trade-offs. Long-term collaboration also let us understand their judgment and know what could safely be entrusted to them.

In the past, we dared to merge not only because someone had looked at it, but also because the writer understood, the reviewer could judge, and the system had fallbacks. Code Review was one link in this trust system, not the whole system.

AI has not suddenly made this link worthless, but it has weakened three pillars of this system at the same time.

Three simultaneous changes: can't finish reading, can't understand, and reading is not enough

First, can't finish reading.

The speed of agent code output far exceeds human reading speed. Manual line-by-line review has become a bottleneck, not because it is unimportant, but because it is too expensive. So expensive that if every change were reviewed at the same depth, teams would be overwhelmed. In the past, a team might have only a few diffs a day; now it may have dozens or hundreds. You can ask everyone to review carefully, but human attention does not automatically expand just because the tools become faster.

More realistically, review quality drops rapidly with fatigue. The first few diffs may still get careful design review. By the tenth or twentieth, it easily turns into a glance and an Approve. On the surface, coverage is still there, but the actual ability to control risk has already declined. The most dangerous thing about line-by-line review is not that it is slow. It is that under pressure it degenerates into a ritual: everyone thinks someone has looked at it, but no one truly understands it.

Second, can't understand.

The value of review comes from the reviewer's understanding of the code. In the past, that understanding came from hands-on implementation. Now that more code is generated by agents, people's familiarity with implementation details is weakened. Without this continuously accumulated understanding, even reading every line may not be enough to judge the impact of the change.

Reading code is not the same as understanding code, and understanding code is not the same as being able to judge system consequences. A change may be syntactically correct and pass tests, but it may alter an implicit assumption — such as the default value of a field, the call order of an interface, or the invalidation strategy of a cache. These risks often cannot be found by reading through the diff; they require long-term familiarity with the system and a grasp of business assumptions.

When people no longer write code with their own hands, this familiarity becomes thinner. This is not a personal capability problem, but a structural result of the changed division of labor. We cannot hand implementation to agents while assuming humans will still know every line as well as they did in the past.

Third, even having read the code is not enough to confirm the impact of the change.

Code Review has never been able to guarantee that all problems are found. In the past, we also could not confirm every detail; ultimately we still relied on trust in colleagues, a grasp of the architecture, and the results of testing and actual operation. But now, colleagues are still colleagues, yet they may no longer have a deep understanding of agent-generated code. The foundation of trust has been weakened.

Line-by-line review is becoming both uneconomical and unsustainable. It is not being replaced by some tool; it is being pushed into the bottleneck position by the new structure of productivity.

What really needs to be confirmed is not "whether the code has been read"

We need to complete a conceptual shift: the goal of Code Review is not to make every line of code read by a human, but to make the possible consequences of this change identified, verified, covered by fallbacks, and owned.

These two statements sound close, but the difference is significant.

The former equates quality with human reading coverage; the latter equates quality with risk-control capability. The former assumes human attention can be allocated indefinitely; the latter acknowledges that attention is limited and therefore must be layered.

A more reasonable quality assurance system in the future should be a layered system:

• Machines handle high-frequency, repetitive, verifiable checks. Lint, type checking, unit tests, end-to-end tests, build checks, and review agents with independent context. Recurring problems should not repeatedly consume human attention; they should be turned into tests, rules, repository conventions, or automated checks.

• Humans handle intent, architecture, business assumptions, and high-risk decisions. Is this feature necessary? Do the key business assumptions hold? Have system boundaries been changed? Who will be affected if something goes wrong, and how should it be recovered? When concurrency, complex state, or security boundaries are involved, deep reading of the specific implementation may still be necessary. What needs to be reduced is the same depth of manual checking applied to every change regardless of risk.

• Canary release, monitoring, and rollback handle the uncertainty that cannot be completely eliminated before launch. Feature flags, small-traffic canary releases, online monitoring, and fast rollback used to be costly, but with AI they can become cheaper and more automated. If data from all online links can be connected to agents, incidents and rollbacks can be converted more quickly into new tests, review rules, or evaluation cases.

• Incidents and defects continue to feed back into conventions, tests, and system design. Every online incident and rollback should not stop at a postmortem document; it should be fed back into the development Agent Loop and become a gate for the next round.

Machines manage what can be verified. Humans manage what is worth judging. Runtime systems manage what cannot be fully predicted.

Risk tiering is not an excuse for laziness; it is a budget for attention

Some people worry: will reducing manual review become an excuse for laziness?

It will. So risk tiering must be done seriously, not as a slogan.

Low-risk changes, such as copy changes, internal tools, and configuration adjustments with no behavioral change, may need no manual review or only light checks.

Medium-risk changes only need the relevant Owner to review the key code and intent, rather than a full line-by-line reading.

High-risk changes, such as billing, permissions, security, concurrency, and core paths, still require strict multi-person cross-review, and may even require deeper implementation reading and failure drills.

The difficulty here is not the word tiering, but the boundaries: who defines the risk level? What if a low-risk change is misclassified? Can a review agent's conclusion be used as the basis for merging? If test coverage is insufficient, can review still be downgraded?

So implementation must at least include three things: change risk labels, an auditable exception mechanism, and a clear human Owner. We can read less code, but we cannot lack a person who is responsible for the consequences of the change. Responsibility cannot be tiered away.

Risk tiering is attention budget management. Human attention is a limited resource. Spreading it evenly across every change is the same as having no focus. Concentrate attention where the cost of failure is highest.

Where human attention should go

If manual review no longer pursues reading every line, where should human attention be concentrated?

I think there are four types of questions.

1. Should this be done at all? Is this feature necessary? Does it align with the business direction? Does it introduce unnecessary complexity?

2. Do the key assumptions hold? What business assumptions, data assumptions, and capacity assumptions does this change rely on? What happens if they are wrong?

3. Have system boundaries been changed? Has it crossed module boundaries, permission boundaries, or data boundaries? Has it introduced new coupling?

4. Who is affected if something goes wrong, and how should it be recovered? How large is the blast radius? Can it be degraded? Can it be rolled back? Who is responsible?

Syntax, formatting, repetitive patterns, and known rules should be handed to machines. Human time should be spent on questions that require judgment combining business and system context. This is not lowering the standard; it is putting the standard in a more correct place.

Humans need to move from code inspectors to risk judges. The former looks at implementation details; the latter looks at the consequences of change. The latter will become increasingly valuable, because code itself is becoming cheaper, while judgment is becoming more expensive.

Two bottom lines that cannot be lost

First, the responsible subject cannot disappear.

We can read less code, but there must still be a human Owner responsible for the consequences of the change. AI can generate code, assist review, and perform risk assessment, but it cannot become the responsible subject. The organization must be clear: who approved this change, who is responsible, and who to go to when something goes wrong.

Second, the foundation of trust needs to be rebuilt.

In the past, trust came from colleagues writing code with their own hands; in the future, trust must come from verifiable test coverage, observability, agent evaluation records, change risk tiering, and runtime fallbacks. It is not I believe he has looked at it, but this system can prove that the risk has been identified, verified, and covered by fallbacks.

If these two bottom lines cannot be held, then so-called reducing manual review will degenerate into no one is responsible. That is not process optimization; it is quality out of control.

What can be done starting today

There is no need to wait for a perfect solution. We can start with a few small actions.

1. Turn recurring problems into rules. Every time a repeated problem is found in review, do not just fix the code. Ask: can it become a lint rule, a test case, a template, or an automated check?

2. Label changes with risk tags. Start with billing, permissions, security, and core paths. Define a high-risk list, and require multi-person cross-review for high-risk changes.

3. Introduce a review agent with independent context. Let it perform the first pass of high-frequency checks, but make it clear that it cannot replace human responsibility.

4. Fill in key tests and observability. The prerequisite for reducing manual review is that testing, canary release, and monitoring can truly provide fallbacks.

5. Feed incidents back into the Agent Loop. Every rollback and incident should be turned into new tests, review rules, or evaluation cases.

6. Audit low-risk review exemptions. The definition of low risk must be auditable and cannot become default approval.

These actions may not look radical, but they all point in the same direction: moving quality assurance from relying on individuals reading line by line to relying on a layered system and clear responsibility.

Conclusion

Code Review still has meaning, but the practice of relying on manual line-by-line review of every change is becoming both uneconomical and unsustainable. A major increase in productivity will inevitably drive changes in the division of labor and collaboration. Software development is no exception. Past tool and technology changes repeatedly changed how we develop, test, and deliver software; this time it is just faster and more dramatic.

The programmer's ancestral creed is not every line must be read by a human, but do not let risks that have not been understood enter production. AI is simply forcing us to move this sentence from relying on human flesh to relying on processes, tools, and accountability.

Code Review will not die. What dies is only the old habit of using line-by-line reading to pretend that risk has been controlled.

What we should pursue is not that every line of code has been read by a human, but that the team can more easily perceive: what is happening in the system, where the risks are, whether problems can be discovered and handled in time, and who is responsible for them.