Code Review Is Becoming a Taste Problem

Code review is becoming a taste problem. AI agents can open a pull request in minutes. Humans still merge what the team must own for years.

That speed gap creates two bad options. Review every line and become the bottleneck. Or skim and ship AI slop.

There is a third path: automate what is deterministic, tier review by risk, and spend human attention on judgment.

I review agent-generated diffs on production work daily. This is how I think about review when implementation got cheap but understanding did not.

---

Why is code review different with AI-generated code?

AI makes implementation fast. It does not make understanding fast.

A diff can look clean. Tests can pass. Linters can stay green. The abstraction can still be wrong for where the codebase is going.

David Poll puts it well: review is shifting from "is this implementation good?" to "does this reflect the right decisions?"

When you did not write the code, the diff carries less implicit context. Someone has to supply the why. That is taste and judgment, not syntax.

---

Code review was never just about finding bugs

A pull request is not only code to inspect.

Reviewers also ask:

• Is this the right feature?
• Does it fit the architecture?
• Does it add complexity we will regret?
• What risks are we accepting?
• Would we maintain this in six months?

AI is strong at "can we build this?" Humans still own "should we?"

That is where engineering taste lives. Knowing what belongs in the product, not just what compiles.

---

The three jobs of modern code review

Move past line-by-line inspection. Three jobs remain.

1. Collaboration

A PR is a place to decide what belongs in the product.

Should we build this at all? Are we solving the user problem at the right layer? These are product and engineering calls, not nits on formatting.

2. Alignment and knowledge sharing

Codebases hold institutional memory. Why does this service work this way? Why is this field immutable?

Agents generate code without that history. Review becomes how humans and agents learn the rules: conventions, business constraints, past trade-offs.

Encode those rules in AGENTS.md, lint configs, and architecture docs. Agents read them before they edit.

3. Verification

Does it work? Do tests prove the requirement, not just the implementation?

CI, static analysis, and security scans handle much of the mechanical check. Verification also means risk: a CSS tweak is not a payment flow change.

---

Code is the medium. Judgment is the work.

Writing code used to be expensive. Teams organized around the artifact.

AI drops the cost of producing and modifying code. You can generate ten approaches, test them, and reject nine.

The scarce resource is no longer lines of code. It is good judgment.

The New Stack frames the same shift: code is the medium; review is where teams exercise taste.

---

Verification debt: when tests pass but trust fails

Verification debt is the gap between merged code and code the team understands.

Agents can outpace your review capacity. If you merge because CI is green, you inherit:

• hidden scope creep
• weakened tests
• architecture nobody can explain
• bugs that look correct until production load

Speed without review discipline is the same knowledge gap I describe in vibe coding vs agentic engineering. Fast output is not a workflow if nobody owns the result.

---

Risk-tiered code review (not one size fits all)

Uniform review fails in the agent era. Too slow for low risk. Too shallow for high risk.

Route PRs by blast radius, not by whether a human or agent wrote the diff.

agentpatterns.ai tiered review matches this pattern: AI on everything; humans on costly or irreversible mistakes.

Encode tiers in CODEOWNERS and branch protection. Critical paths always hit Tier 3, even for small diffs.

---

How to review an AI-generated pull request

Philosophy is not enough. Run a checklist tuned to agent failure modes.

GitHub's agent PR guide and practitioner checklists converge on the same order:

Step 1: Pin the scope

Read the file list before the diff. Does this PR touch only what was asked? Unexpected files are scope creep.

Step 2: Check the harness first

Did coverage thresholds drop? Were tests skipped or weakened? Did CI steps get gated away? Any harness change is a blocker until explained.

Step 3: Read deletions before additions

Agents delete guards quietly. Regressions hide in removed checks.

Step 4: Verify tests, do not trust claims

"Invert one assertion and re-run." If the test still passes, it may be decoration. Tests should fail when behavior breaks.

Step 5: Trace one critical path

Do not skim. Walk input → transforms → output. Check empty, max, and error branches manually.

Step 6: Audit imports and APIs

Hallucinated packages and wrong method signatures are common. Verify against docs or lockfiles.

Step 7: Judge fit, not just correctness

Is this a second way to solve a problem the codebase already solves? Is the abstraction right for the next year?

---

Three buckets of review feedback

Sort comments into three buckets. The New Stack cites a rough 45 / 30 / 25 split on real teams: deterministic, testable, pure judgment.

Most repetitive review should become institutional memory, not repeated comments.

---

Turn review comments into rules

When a senior engineer catches the same anti-pattern twice, codify it.

Human judgment
     ↓
Review comment
     ↓
Lint rule / CI check / AGENTS.md note
     ↓
Agent avoids it upstream
     ↓
Less repetitive human review

That loop beats a graveyard of PR comments nobody reads. Taste becomes enforceable defaults.

---

Where AI review tools fit

PR bots (CodeRabbit, Greptile, Copilot review, etc.) clear the floor. They catch style issues, obvious bugs, and missing error handling.

They do not replace senior judgment on:

• wrong abstraction in clean shape
• subtle architectural drift
• product fit and trade-offs

Use AI review before the human pass. Free humans for Tier 2 and Tier 3 judgment calls.

---

The senior engineer role is changing

AI may reduce how much code seniors write. It can increase their value.

Someone still decides:

• what should exist
• what risks are acceptable
• which direction the system takes

Seniors become stewards of engineering direction, not syntax gatekeepers. That pairs with agentic engineering: agents execute; humans set the quality bar.

---

The future of code review

Maybe "code review" becomes the wrong label. The practice is the process around the diff:

Intent → collaboration → verification → judgment → institutional memory

When code was expensive, the bottleneck was writing it. When code is cheap, the bottleneck is deciding what deserves to exist.

The goal is not to eliminate review. It is to eliminate unnecessary human review.

Automate deterministic checks. Delegate mechanical scans to tools. Reserve people for judgment.

That is why code review is becoming a taste problem, and why taste is worth encoding before the next agent PR lands.

---

Where to go next

• What Is Agentic Coding? — the agent loop and verification debt
• Vibe Coding vs Agentic Engineering — control when agents write the code
• How to Transition to AI Engineering — evals and production discipline
• Building Software vs Solving a Problem — product judgment alongside technical review