Code Review Culture in the AI Era: When Your PR Becomes an AI Prompt

What Code Review Used to Be

Not long ago, a code review was a conversation between two humans. The author had thought through a problem, written code that reflected specific decisions, and submitted it for peer evaluation. The reviewer could see the reasoning embedded in the diff — not just the conclusion. You could ask, "Why did you approach it this way?" and get an answer that revealed something worth knowing.

Code review served multiple functions simultaneously: quality control, knowledge transfer, collective ownership, and the slow, invisible work of building shared standards. A good reviewer wasn't just checking for bugs. They were reading someone's thinking.

That relationship is now strained. The "someone" at the other end of the review is increasingly a language model that made decisions the author is now being asked to defend — or that the author doesn't fully understand.

What AI Actually Changed

It's not just that code review got harder. It's that several distinct things changed simultaneously, and each one added friction:

The Six New Review Frictions

These aren't hypothetical. Engineers across the industry are reporting these specific frictions in their day-to-day review experience. If you've felt them but couldn't name them, you're not imagining it.

1. The Explanation Gap

You request a review. The reviewer asks why the code does X. You generated X with AI. You don't fully know why X works, only that it does. You either say so honestly ("the AI generated it, I'm not entirely sure why it's structured this way") — which undermines your credibility — or you construct a post-hoc explanation you hope is accurate. Neither option is satisfying.

2. The Context Vacuum

Human PRs come with context. The author knows the operational constraints, the user's needs, the business urgency. They wrote the commit messages and PR description with that context in mind. AI-generated PRs often lack that narrative. The diff tells you what changed; it doesn't tell you why the change mattered.

3. The Premature Optimization Trap

AI tools tend toward sophisticated solutions. If you ask a human junior engineer to solve a problem, they'll often reach for a simple, readable solution. If you ask an AI, it tends toward the comprehensive, architecturally correct, slightly over-engineered answer. Reviewers end up reviewing solutions to problems that didn't need such complex answers — and pushing back requires understanding why the simpler approach was rejected.

4. The "Looks Fine to Me" Trap

Reviewers, overwhelmed by diff size and lacking context, often give AI-assisted PRs a lighter review than they would a human-authored PR of the same size. The risk: subtle bugs, security issues, or architectural mismatches slip through. The reviewer felt they couldn't evaluate it properly but approved it anyway rather than block it.

5. The Backwards Tool Problem

Some teams now have a dynamic where the author used AI to write the code, and the reviewer uses AI to review it. Two language models in a loop, with humans as the intermediaries. The review becomes a negotiation between two AI outputs mediated by humans who may not fully understand either one.

6. The Attribution Dilemma

What do you comment when you find a real problem in AI-generated code? "This looks like an AI hallucination" feels pointed. "The edge case here isn't handled" feels insufficient. Reviewers don't have good language for flagging AI-generated issues without implicating the author, which creates a new class of unsaid things in review culture.

Why Senior Engineers Feel This Most

Here's the counterintuitive dynamic: the engineers who are most qualified to review AI-generated code are often the ones who feel most drained by it.

Senior engineers carry the most review responsibility. They're the ones who get tagged when a PR needs architectural sign-off, when there's a debate about approach, when the team needs someone who can evaluate tradeoffs. In many teams, senior engineers spend 30–50% of their technical time on code review.

That was sustainable when review meant reading a colleague's reasoning. Now it means:

• Understanding a solution the author didn't design, presented by the author who doesn't fully own it
• Evaluating architectural decisions made by a training dataset rather than a human brain
• Carrying the knowledge of why the team's systems work the way they do, and identifying where AI-generated code violates those patterns
• Being the last line of quality defense when everyone else is moving fast

Senior engineers aren't just reviewing code anymore. They're reviewing an AI's approximation of code — and then defending the team's architectural integrity against that approximation in a velocity-pressured environment where "move faster" is the loudest signal.

There's a term forming for this: reviewer fatigue. It shows up as dreading the review queue, giving lighter reviews than you know you should, or procrastinating on reviews because they feel like a second job on top of your actual job.

The Authorship Problem Nobody Is Talking About

Code review assumes clear authorship. Someone wrote this. That person is accountable. That person can answer questions. That person has skin in the game.

AI-assisted PRs don't have clear authorship. The engineer pressed a button. The AI produced something. The engineer reviewed it, modified it, and submitted it. At what point did the engineer become the author? At what point did the AI stop being responsible?

This isn't just a philosophical question. It has real consequences for how teams function:

The authorship problem compounds over time. As teams use more AI assistance, the codebase accumulates decisions that no human fully made or can fully explain. Future engineers — who may be reviewing or maintaining code they didn't author and don't understand — will face an ever-growing layer of AI decisions embedded in the system.

What Teams Are Doing About It

No single solution has emerged as the standard. Different teams are trying different things, with varying degrees of success. Here's what's showing up in teams that are navigating this well:

AI Contribution Notes

Some teams have started requiring an "AI Contribution Note" in every PR description that used AI assistance. It doesn't have to be confessional. Something as simple as: "Used AI to generate the initial implementation of the email validation logic. Modified the error handling pattern and added the rate-limit consideration myself." This is honest, specific, and gives the reviewer something to work with.

Explanation Requirements

Teams using The Clearing's Explanation Requirement framework have extended it to code review: before submitting an AI-assisted PR, the author must be able to explain the code in their own words. If you can't explain what the AI wrote, you can't submit it. This simple gate has dramatically reduced low-understanding AI submissions in teams that have adopted it.

Review Depth Tiers

Some teams have formalized review depth categories: "standard review" for routine changes, "deep review" for architectural decisions or security-sensitive areas, and "expedited review" for clearly bounded, low-risk changes. AI-generated code in architectural or security areas gets deep review. This manages reviewer load while maintaining quality where it matters most.

No-AI Zones

A few teams have designated specific areas of the codebase — usually the core domain logic, security-critical paths, or performance-sensitive code — as no-AI zones. The rationale: code that requires deep understanding to maintain should be written with deep understanding. AI can assist research, testing, documentation, and boilerplate; it doesn't get to own the hardest parts.

Pre-Review Pairing

More teams are scheduling 15-minute pre-review pairing sessions for complex changes. The author walks a reviewer through the AI-generated solution before the formal review starts. This replaces asynchronous confusion with synchronous understanding — and often surfaces issues before they become review comments.

What Individual Engineers Can Do

If your team hasn't established norms yet — and most haven't — here are practices that individual engineers have found helpful, even in the absence of team-level change:

Before requesting review on AI-assisted code

• Read your AI output like a stranger's code. Would you approve this if a colleague submitted it? Does it make sense? Can you explain it?
• Add context to your PR description that a human wrote: what problem you were solving, what you considered and rejected, what you're uncertain about.
• Mark what the AI did and what you did. You don't need to apologize for using AI. You do need to give reviewers the information they need to evaluate your work.
• Test the AI's assumptions. If the AI generated code based on an assumption about the system, verify that assumption before review. Nothing burns a reviewer faster than being the first to discover the assumption was wrong.

When you're the reviewer

• Be honest about what you can and can't evaluate. If a PR is large and you're not sure about the AI-generated approach, say so. "I'm not sure this architectural direction is right, can we pair on it?" is a valid review comment.
• Don't give AI-generated PRs a pass. If you would flag this in a human-authored PR, flag it here. The AI's output deserves the same scrutiny — arguably more, because the accountability is weaker.
• Ask questions instead of making judgments. "Where did this approach come from?" and "What were the alternatives considered?" are more useful than "This looks wrong."
• Protect your own time. If a PR is unreasonably large — AI-generated or otherwise — it's reasonable to ask for it to be split. This isn't a punishment; it's sustainable review practice.

Frequently Asked Questions

Continue Reading