Code Review Is Becoming a Taste Problem

Code review is becoming a taste problem. AI-assisted software development has fundamentally changed the economics of writing code.

Generating code is becoming cheaper and faster. A developer can describe a feature, ask an AI coding agent to implement it, run tests, make a few adjustments, and produce a pull request in a fraction of the time it once took.

But this creates a new problem:

If AI can generate code faster than humans can review it, what exactly should code review become?

The obvious answers are not particularly appealing.

We could review every line as we always have, turning senior engineers into a permanent bottleneck.

Or we could reduce review and accept the risk of shipping low-quality code, hidden complexity, and what many teams now call "AI slop."

But perhaps the problem is not AI.

Perhaps we have misunderstood what code review was supposed to accomplish in the first place.

Code Review Was Never Just About Finding Bugs

It is easy to think of a pull request as a piece of code that needs to be inspected.

Does this function work?

Is there a bug?

Is this implementation efficient?

Does it follow our coding standards?

Those questions matter, but they are only part of the picture.

The deeper purpose of review is judgment.

A reviewer is not simply asking:

"Is this code correct?"

They are also asking:

• Is this the right feature?
• Is this the right way to solve the problem?
• Does this fit the architecture?
• Does it introduce unnecessary complexity?
• Does it align with the product's goals?
• What assumptions are we making?
• What risks are we accepting?
• Would we want to maintain this six months from now?

This is where "taste" enters the discussion.

Good engineering requires knowing not only what can be built, but what should be built.

AI is getting increasingly good at the first question.

The second remains a human responsibility.

The Three Jobs of Modern Code Review

Once we move away from treating review as line-by-line inspection, three important responsibilities remain.

1. Collaboration

A pull request creates a place where engineers can discuss what belongs in the product.

The discussion isn't necessarily about whether a particular line should use one implementation or another.

It can be about whether the feature itself makes sense.

Should we build this?

Does it solve the actual user problem?

Are we solving the problem at the correct layer?

These are product and engineering decisions, not merely code-quality checks.

2. Alignment and Knowledge Sharing

Software systems contain enormous amounts of institutional knowledge.

Why does this service work this way?

Why can't we change this database field?

Why does this component have this constraint?

Why was this architectural decision made?

Code review has traditionally been one of the places where that knowledge gets transferred between engineers.

In an AI-assisted environment, this becomes even more important.

AI agents can generate code, but they don't automatically possess the complete context of your organization.

They need to understand:

• architectural conventions
• business rules
• product constraints
• historical decisions
• operational risks
• organizational preferences

Review therefore becomes part of the mechanism through which both humans and AI systems learn how a particular codebase should evolve.

3. Verification

The final responsibility is still straightforward:

Does it actually work?

Tests, static analysis, CI pipelines, observability, security checks, and automated validation can handle much of this.

But verification also involves understanding risk.

A small UI change and a change to payment processing should not receive the same level of scrutiny.

The important question becomes:

Where should human attention be spent?

Code Is the Medium, Judgment Is the Work

This may be the most important shift.

Historically, writing code was expensive.

Because engineering time was expensive, the code itself became the primary artifact around which development was organized.

Today, AI is rapidly reducing the cost of producing and modifying code.

That changes the economics.

If generating ten implementations costs almost nothing, we don't necessarily need to spend hours debating which implementation should be written before seeing any of them.

We can generate several possibilities.

We can test them.

We can compare them.

We can reject them.

And we can merge the one that best satisfies the actual intent.

The scarce resource is no longer necessarily code.

The scarce resource is good judgment.

Planning and Review Are Starting to Merge

Traditional software development often separates planning from implementation.

First we write requirements.

Then architecture documents.

Then tickets.

Then developers implement.

Then reviewers inspect the result.

AI changes the cost structure of this process.

When implementation becomes cheap, some planning activities may move closer to the point of execution.

Instead of spending a significant amount of time trying to perfectly specify an implementation before writing it, teams can generate implementations and use review to evaluate them.

This could eventually lead to an interesting workflow:

Generate more → review more selectively → merge less.

Imagine a team producing many candidate pull requests.

Most are rejected.

Some are modified.

A few are merged.

The pull request becomes less of a record of "what the developer decided to build" and more of a proposal:

"Here is an implementation of this intent. Does it belong in the product?"

That is a fundamentally different role for code review.

We Don't Have to Stop Reading Code

There is an important nuance here.

"AI means developers shouldn't read code anymore" is an oversimplification.

The real question is not:

Should humans read code?

It is:

Which code deserves human attention?

Not every change carries the same risk.

An internal admin dashboard is not the same as financial infrastructure.

A marketing website is not the same as medical-device firmware.

A small UI refactor is not the same as a change to authentication or authorization.

The appropriate review process should reflect those differences.

For low-risk changes, automated validation and high-level intent review may be enough.

For high-risk systems, engineers may still need to inspect implementation details carefully.

So the future isn't "humans don't read code."

It is:

Humans read the code where human judgment provides the most value.

Turning Review Comments Into Institutional Memory

There is another opportunity created by AI-assisted development.

Consider how code review works today.

A senior engineer notices the same problem repeatedly:

Don't introduce this pattern.

A few weeks later, they see it again.

They leave another comment.

Then another.

Eventually, someone writes a lint rule.

This is exactly the direction we should take more often.

If a reviewer repeatedly identifies a deterministic problem, that knowledge should stop depending on the reviewer being present.

It should become an automated rule.

The review process can therefore become a feedback loop:

Human judgment → review feedback → rule → automated detection → less repetitive human review

This creates something much more valuable than a collection of comments.

It creates institutional memory for the codebase.

Over time, the codebase can encode the organization's accumulated engineering taste.

AI systems can then use those rules before producing code, while CI systems can enforce them after code is generated.

That means the best codebases may eventually become increasingly self-governing.

Not Every Review Comment Requires a Human

This leads to an important distinction.

Some review feedback is deterministic.

For example:

• This API must not be called directly from the client.
• This dependency is prohibited.
• This function must have a test.
• This component should use the shared design system.
• This database operation requires a transaction.

These are excellent candidates for automation.

Other feedback can be tested through execution.

For example:

• Does the feature work?
• Do the tests pass?
• Does the API return the expected response?
• Does the application crash?
• Does performance remain within acceptable limits?

Then there is the final category:

Judgment.

Questions such as:

• Is this the right abstraction?
• Are we solving the right problem?
• Is this complexity justified?
• Does this product behavior make sense?
• Is this architectural direction appropriate?

These are much harder to automate because there may not be a universally correct answer.

And that is exactly where senior engineers become more valuable.

The Senior Engineer's Role Is Changing

AI may reduce the amount of code senior engineers need to write.

But that doesn't necessarily reduce the value of senior engineers.

It can increase it.

When implementation becomes abundant, someone still needs to determine:

What should exist?

What shouldn't exist?

What risks are acceptable?

What trade-offs are worth making?

What direction should the system take?

This moves senior engineering closer to architecture, product thinking, system design, risk management, and organizational knowledge.

The senior engineer becomes less of a gatekeeper for syntax and more of a steward of engineering direction.

This is the same split I wrote about in vibe coding vs agentic engineering: speed without control is not a workflow — it is a knowledge gap.

The Future of Code Review

Maybe "code review" will eventually become the wrong name.

The important practice isn't the act of staring at a diff.

It is the process surrounding the diff:

Intent → collaboration → verification → judgment → institutional memory

AI changes how we produce code, but it doesn't eliminate the need for those activities.

In fact, it makes them more important.

When code is expensive to produce, the bottleneck is writing it.

When code becomes cheap to produce, the bottleneck moves somewhere else.

It moves toward deciding what deserves to exist.

That is why the future of software engineering may not be about reviewing more code.

It may be about developing better taste, encoding that taste into our tools, and reserving human attention for decisions that actually require it.

The goal shouldn't be to eliminate code review.

The goal should be to eliminate unnecessary human code review.

Let automation handle what can be automated.

Let AI handle what can be delegated.

And let experienced engineers spend their time on the one thing that remains difficult to automate:

judgment.