We may not need Code Reviews anymore

I understand this may sound very controversial, but there is a strong argument(s) that the way we do code reviews needs to change. Not because we stopped caring about quality - it’s the opposite. Traditional code review evolved in a world where virtually all production code was written by humans. The process, its expectations, and the amount of human attention we devoted to it were shaped around that assumption.

This assumption is no longer true.

A growing amount of code is now generated by AI, often at a speed and volume that humans cannot realistically review line by line. That doesn’t mean AI-generated code should be trusted blindly. It means that applying exactly the same verification process to a fundamentally different way of producing software may no longer make sense.

If the way we create code changes, the way we verify it should evolve as well.

Reviewing code manually isn’t the final form of verification and frankly never was. If we look historically, humans apply manual verification because that was the fastest and cheapest way of handling certain things. It was exactly the same with code review… up until some point. AI has changed the rules of the games so we have to change our approach.

In the 70s, code inspection was a crucial quality mechanism. Michael Fagan’s famous IBM work formalized sessions where software engineers systematically inspected designs and source code to find defects. That system worked because humans were essentially the best verification system available. Then we gradually automated one bottleneck after another:

And I cannot deny - introduction of AI into software development has become one of the biggest shifts I’ve ever seen in the entire industry.

It shouldn’t be anything new for anyone already using AI to write a code. The amount of code produced by AI is enormous. Code becomes cheap because it's easy to “write” it a lot. And it doesn't necessarily have to be necessarily bad things. Instead of complaining about how big is the amount of code written by AI, we can break it down and see what’s in scope.

Manual code review by humans is still expensive, and that hasn’t really changed. What has changed dramatically is the amount of code we can produce.

Before AI, implementation throughput and review throughput were relatively close because both depended heavily on human time. Now code can be generated far faster than humans can realistically read, understand, and review it.

That creates a new asymmetry: we can produce much more code than we can afford to inspect line by line.

But that doesn’t mean all of that generated code has to become production code. A large amount of it can exist only to explore an idea, test an assumption, verify behavior, generate data, challenge an implementation, or help us understand the code that actually matters.

These days many lines of code contribute to tests (or at least should as it’s cheap and significantly increase quality). Another reason for the code is, AI is covering many cases that are harder to spot for humans, and that is contributing to producing even more code. This is leading us to one of the most important things:

I’m not that old to remember the beginning of software development but still take a stab at saying it’s the biggest shift in software engineering. For 50, or even 70 years code generation was expensive. The cost of producing code is falling much faster than the cost of understanding and verifying it.

For decades, producing and maintaining software required a large amount of human effort. That shaped many of the practices we use today: abstraction, reuse, libraries, packages, design patterns, DRY, code review, and many others. They were not created simply because typing code was expensive, but because changing, understanding, validating, and maintaining software was expensive. AI dramatically reduces one part of that cost, producing code, while many of the other costs remain.

Modern code-review workflows evolved under the assumption that human implementation capacity and human review capacity were of roughly comparable scale. AI makes it no longer true and breaks that relationship.

But it isn’t anymore. So let’s not blindly apply practices applying to different situations.

Human understanding, judgement and attention remains expensive so the scarce resource increasingly becomes: human cognitive bandwidth - not code production. That changes what engineering should optimize for.

I’m not arguing for reviewing code by humans but it doesn’t make any sense to do it in the same form as we did when code was 100% hand-written. Stop reviewing code uniformly. The future of software development may not be “No code review” but it may instead be:

• Less line-by-line human review
• Much more automated/agent verification
• Human review concentrated on
  • architecture
  • interfaces
  • contracts
  • security
  • business logic
  • critical invariants

Historically we tended to think:

AI changed that. Code can exist for 30 seconds, one experiment, one PoC, one hypothesis, benchmark, you name it, but after that can be deleted. In fact, your harness is working the same way and we may not even be aware about that if not paying too much attention. They spawn scripts in the background to achieve some tasks and remove the script once this is done.

Some industries produce so important code that risking using AI to generate code may cost someone’s life. Example is code for medical tool and equipment. Another example is the driver (or any kind of software) for aircrafts.

If I have 100 lines of safety-critical code, the important question is not simply whether a human or AI wrote them. What matters is whether those lines can be rigorously specified, traced, tested, reviewed, and verified. That makes important code also expensive code to verify and own/maintain. Exactly for that reason I should write 10 000 lines of disposable code to challenge this important code, test from top to bottom and spawn as many experiments trying to break it as it’s possible. That being said, even if you think your industry produces too important (and therefore expensive) code, you should still benefit from cheap, disposable code produced by AI.

AI can also be surprisingly effective at broadening the set of cases we consider. There is plenty of justified criticism here: AI can miss obvious edge cases, generate tests that look convincing but are actually invalid, or reinforce the same incorrect assumption that already exists in the implementation.

At the same time, my own experience has often been more positive. When I ask AI to challenge an implementation, generate unusual scenarios, or think through edge cases, it frequently comes up with cases I would not have considered myself - or at least not as quickly.

The biggest advantage comes from combining both approaches. Humans bring context, judgment, domain knowledge, and the ability to recognize when the model is reasoning from a bad assumption. AI brings speed, breadth, and the ability to explore far more possibilities than a human would realistically have time to enumerate manually.

That means the strongest approach is neither to avoid AI nor to trust it completely. We get the most value when AI expands the search space and humans decide which findings are valid, relevant, and important.

That can include synthetic data generators, API contract validators, failure-injection scripts, migration dry-run utilities, permission scenario generators, data integrity checks, production-incident replay tools, and many other forms of disposable verification code.

Important production code should still be rigorously reviewed and verified, regardless of whether it was written by a human or generated by AI. The surrounding verification code doesn't necessarily need the same standard. By having that supporting code, we can increase the quality of the important/expensive code.

This could be wrapped up as linear dependency:

Let’s leave the surrounding verification code for a moment and focus on the code that actually becomes part of your product or business. As I mentioned earlier, the more serious the consequences of failure, the higher the verification burden should be. Safety-critical software should therefore be specified, tested, reviewed, and validated far more rigorously than a disposable internal tool.

But most software exists somewhere between these extremes. There is a whole spectrum of risk, and the way we use AI, and the amount of human scrutiny we apply, should depend on where a particular change sits on that spectrum.

Closer to the high-risk end are systems where failures may cause serious financial, legal, security, or operational consequences. Payments, authentication, access control, sensitive documents, financial systems, and core infrastructure are good examples. In these areas, AI can still be useful, but the verification burden should remain high and human judgment should stay deeply involved.

Further down the spectrum are ordinary production systems where failure matters, but the consequences are usually recoverable. A bug may cause an outage, inconvenience users, create support work, or temporarily affect revenue, but it is unlikely to cause catastrophic damage. Most business applications probably live somewhere around this part of the spectrum. Here, AI can take on much more implementation work as long as strong automated checks and targeted human review are in place.

Then there are early-stage products, prototypes, and experiments where learning speed may be more valuable than perfect reliability. In those situations, accepting some mistakes can be a reasonable trade-off if it allows the team to validate an idea much faster. This is where AI-generated code can be used much more aggressively.

At the low-risk end are one-time tools, exploratory scripts, temporary migrations, experiments, and disposable utilities. If the code will exist for a few minutes or hours and the consequences of failure are negligible, spending significant human time reviewing every line may provide almost no value.

These are not strict categories. They are points on a continuum, and the same engineer may move between them several times during a single day. The important thing is to adjust the level of AI autonomy and human verification to the consequences of getting something wrong.

The problem is that we often apply the same approach to very different situations. There should not be one universal “AI code policy” applied to every type of code. Even a single engineer may move between several levels of risk during the same day. What matters is understanding the consequences of failure and adjusting both AI autonomy and human scrutiny accordingly.

Reading every code, in the time when most of it is written by AI, is a waste of time. We, as software engineers, are starting to operate on one level higher. We may want to steer the architecture, plan how components are connected but not necessarily take care about how things are implemented underneath.

Every engineer should transit from code-line oriented engineer to contract-oriented engineer. Contract between other components of the system. Rather than know implementation of every function or class, you should ask yourself “Do I understand the contract this module exposes?” or “Can I verify its behavior?”.

Many of the things code related could be actually pre-reviewed before any human will look at that. AI should play key roles in pre-reviewing code to save human time. In many cases, depending on what your system is doing and in what industry you’re working in, after solid AI code verification and fortifying it quality checks, it may already be at a very high level of quality.

Otherwise, we no longer write code but only review code because there’s so much code produced by artificial intelligence. That approach significantly changes the human's position in the pipeline. With that we can still bring a lot of value, especially where it matters, with our judgements. And not enslave ourselves to only do manual review of the code generated by AI.

Well… at least, not in the form we are used to.

Code review was never the goal. The goal was confidence: confidence that a change is correct, safe, maintainable, and appropriate for the system it is entering.

For years, having another engineer read the diff was one of the best ways to build that confidence. But AI is changing the balance. Implementation can now be produced much faster than humans can realistically inspect it, and asking engineers to compensate by simply reading more generated code does not scale.

The answer is not to care less about quality. It is to build better ways of establishing confidence.

More of that confidence can come from automated tests, static analysis, contract validation, runtime evidence, generated experiments, AI reviewers, and other forms of automated verification. Human attention can then be concentrated where it creates the most value: architecture, business intent, security, ambiguity, trade-offs, and risk.

That changes the most important question we ask during review.

That doesn’t mean verification is disappearing. Quite the opposite. We may verify more than ever before.