Will Humans Still Review Code?

February 17, 2026

We are living through a strange moment in the software industry.

If you look at the changes we are seeing in development technology, we are certainly living in the future: shipping features from a Slack message, generating entire applications from a spec, writing 20 PRs in a day without opening an IDE. Increasingly, the engineers I work with and know report that they no longer write code. The technology is genuinely unprecedented.

And yet. If you step outside the demos and the Twitter threads and look at what’s actually happening inside software companies, you’ll find something embarrassing: not much has changed in terms of productivity. Yes, there are big claims, and yes, there is more code than ever. However, most companies still appear to be delivering value at a pace similar to that of one year ago.

What is exciting, though, is that this situation is evolving week by week. We seem to be at a strategic crossroads, where companies that correctly diagnose the why and make the right strategic technical moves will significantly outpace others. And the companies that get ahead will be the ones that correctly answer one question: “Will humans still be reviewing code in the next few years?”

Coding was Never the Bottleneck

The reason most companies are running but staying in place is straightforward, if uncomfortable: coding was never the real bottleneck to value delivery in software.

While having an engineer write code surely takes time, it is only one part of the value delivery chain that starts with an idea and culminates in a feature in production. Even if you focus on the engineering aspects of it, when you look at most enterprise companies, you will find that engineering work is usually stuck in reviews, deployment, testing, and different levels of rework.

Writing code is one of many steps in delivering value with software

This is not a new discovery, but what is new is how AI-assisted development made this situation extremely obvious. There is no way to examine the current state of the industry without recognizing that the bottleneck lies elsewhere.

We can also see how this is not new given every innovation on how to accelerate delivery seems like a deja vu of twenty years ago:

We have rebranded TDD (Test-Driven Development) as Spec-Driven Development.
We have different versions of a red-green-refactor cycle to maintain agent oversight.
We are talking about moving away from PR requests or adopting Trunk-Based Development.

And this is the right move. It feels the same because iterative methodologies from the Agile era were based on the same principle: writing code is not the primary problem to solve; rather, it is ensuring that we write the right code to deliver value.

Enterprise Software State of the Union

I’m not a researcher, so this is not a study. However, I have insight into a number of enterprise software companies through my work and connections with people across different areas.

I think this is a good summary of what is happening today:

Every company has implemented AI v0, which means giving engineers unlimited access to AI tooling.
Software organizations are drowning in PRs, for obvious reasons. In the past, if I wanted to write 10k lines of code, I needed to write them. Now I can do it with a few prompts.
Maintaining quality is a challenge. There is too much code to review, authors often don’t review their own code, and the pressure naturally leads to mistakes.
There is a consistent effort in further automating parts of the work. That looks like bugs, small issues, and review comments being automatically addressed by agents.
There is a strong effort to solve the PR review bottleneck, with automated reviews and tooling to assist engineers.

And that is a logical move. If AI v0 was access to tooling, AI v1 means acting on the new bottleneck. Given that it shifted entirely from writing code to reviewing PRs, the natural way for companies to deal with it is what they are doing: make reviews easier and free engineering capacity from development to devote to code review.

If the bottleneck is in code reviews, it is natural to optimize code reviews

However, optimizing PR reviews means iterating in a process that might be broken. For example, using PRs assumes two people (the author and the reviewer) will review the code, but the author’s relationship with their code has completely changed. After all, they are no longer writing it.

Beyond reduced attention, if agents continue to evolve, it doesn’t matter how many people review code. It won’t be enough. The natural path to AI v2 will be to rethink the process, making the full SDLC agent-adapted, a move that some companies are already trying.

What if we can bypass these steps altogether?

And that creates a meaningful risk for enterprises, where a change like that would take months or maybe years. What if another company could do it faster than you?

The Fork on the Road

It is clear that for greenfield software, v2 is already here. Most startups starting a codebase now will reduce their reliance on PR reviews. That is a different problem for the enterprise, though. By that, I mean companies with hundreds or thousands of engineers, a large and established codebase, and significant revenue.

For these companies, the situation is:

They own a complex brownfield codebase with varied levels of quality, and code reviews are a critical step to avoiding production issues.
A production issue results in revenue loss and deterioration in sentiment. If you want an example of that, as of today, GitHub had 24 status page updates in 17 days in February 2026.
Changing how hundreds/thousands of people work requires a concerted effort over a long period. Implementing technical changes to reimagine the SDLC might require even longer.
If you clear all of that, you may still need compliance, which often requires human review.

Although the future appears to be here, it is also not guaranteed. Agents might not evolve as much as the optimists expect. The startups building in this new way might struggle when their codebases actually grow. The cost of AI tooling may be a barrier to the most ambitious expectations.

There is no obvious answer: enterprise software companies in 2026 might actually be facing a hard technical strategy choice they will regret getting wrong.

The Conservative Option

The easier option is to follow this trend one step at a time, assuming that while AI coding is here to stay, the shape of the SDLC will not change. We will still require humans to oversee all code going to production for complex applications, much as we do now.

In that case, the path is indeed to optimize the code review process. We already have some tools to support reviews and are likely to have more. Team processes will be changed to focus on code reviews. Agent development will be constrained, maybe with WIP limits on code or open PRs, to balance the system.

The result in this situation will be positive, but likely not mind-blowing. While it should lead to a real increase in value delivery (more than we have now), it won’t change it by an order of magnitude. However, if you follow this path, you are leaving a big option open.

Let Agents Own the Code

A progressive view would involve removing humans from the review loop, allowing agents to drive code delivery. This is not a complete AI takeover. It’s pragmatic. Something like:

An engineer drives a feature, prompting agents to implement it with the necessary constraints. The engineer has enough understanding to probe implementation and guide architecture, but doesn’t need to review every line.
Teams can still test features end-to-end, ensuring behavior is as expected.
Code is deployed to production without review, and quality is guaranteed through test automation, monitoring, and different types of automated verification (agentic or deterministic).

This is not far-fetched. However, if a company can implement it at scale, it would likely deliver value many times what it does today. But it requires substantial technical, people, and legal investment.

To be practical, your code needs to be modularized enough so that parts of it can fit in an agent’s context. Your test automation needs to be strong enough that it replaces human review. Your monitoring must be effective, and your response must be timely enough to address potential issues. And the roles played by engineers will meaningfully change (together with how we hire, reward, and assess performance).

If you are an engineering leader, here are the questions I am asking myself:

Are code reviews a permanent part of how we build software, or a constraint we can eventually remove?
What would it take to remove code reviews from part of our technical stack?
What kind of tooling would we need to make deployments much safer?
Could we practically build the necessary tooling, given that coding is cheaper?
How would our engineering roles need to change if code review was no longer the primary quality gate?

While challenging, a move toward agent-driven coding is certainly feasible over the medium to long term. More importantly, if you don’t do it but your competitor does, any technical moat your company has will likely disappear.

Choosing your path is not an easy decision. But it’s one that will matter.