Simple rules to fix code reviews

In a software development landscape increasingly augmented by AI-generated code, code reviews remain a critical safeguard for quality, collaboration, and team coherence. Yet despite decades of collective experience, code reviews often become inefficient bottlenecks. Sergey Tselovalnikov, a seasoned engineer, proposes that we don’t need more checklists or “best practices” to fix the problem, we just need two simple but consistently applied rules.

Two simple rules that can transform code reviews

These rules are not revolutionary in theory, but their consistent application can deeply impact the cadence and quality of engineering output. They are aimed not at optimizing the value of code reviews (a separate topic) but at minimizing their cost, specifically the delays and inefficiencies that reviews inject into the development process.

Why code reviews need fixing

Tselovalnikov’s career has involved thousands of pull requests across numerous teams and projects. From that experience, he observes the same recurring pain points, slowness, ambiguity, friction. These issues don’t arise due to lack of knowledge or intention but from failure to apply two key principles consistently.

Today, as large language models and automated tools generate increasingly large portions of our codebase, it might seem that human code review would diminish in importance. In reality, the opposite is true. Human review is still essential for things that AI struggles with, intentionality, long-term maintainability, domain understanding, and nuanced team conventions. And when a team’s code review practices are broken, they slow everything down.

Tselovalnikov avoids retreading common advice like “keep diffs small” or “avoid personal language.” Those are useful tips, but they are symptoms, not causes. His solution cuts deeper, right to the habits of the reviewer.

Rule 1: Minimize response time

This rule seems deceptively simple, but it carries enormous weight. When a reviewer receives a pull request, their instinct might be to defer, “I’ll do it tomorrow,” “this one looks big,” “I’m busy now.” From their point of view, the delay doesn’t feel costly. The diff will still be there tomorrow.

But for the author, the cost is immediate and heavy.

Once a change enters review, their progress is frozen. They can’t merge, ship, or even confidently move on to adjacent tasks because any future work might depend on the code in review. Context switching to unrelated work eats cognitive energy. Momentum is lost.

Tselovalnikov breaks it down like this:

If the delay is just one hour, little context is lost.

After a day, the author starts forgetting specific change rationale and needs to rebuild the mental model.

After a week, it’s like starting over entirely.

This means a long review delay doesn’t just cost time, it dramatically inflates the cost of regaining productive flow. Worse, it often leads to “zombie PRs”, those forgotten, half-resurrected branches that rot in the codebase or require a painful resurrection effort.

It’s crucial to emphasize: minimizing response time does not mean approving quickly or superficially. You don’t have to rubber-stamp changes you don’t agree with. What you do have to do is respond, ask clarifying questions, flag concerns, sketch an initial reaction. Silence is the real killer.

This is especially important in team environments with fast iteration cycles. When one reviewer delays feedback for days, it creates cascading slowdowns for everyone waiting on that change.

Rule 2: Every comment must include a "Because"

If the first rule accelerates the beginning of a review, the second rule accelerates the end. Many reviews stretch out not because of disagreement, but because of vagueness.

Consider a typical reviewer comment:

"Can you rename this function?"

Without any further context, the author is left to guess the rationale. Is it a naming convention? Personal preference? A misunderstood dependency?

Now consider the same comment with a "because":

"Can you rename this function because it violates our camelCase convention?"

Or better yet:

"Please rename this to getUserId() because we use camelCase for all accessors, and this will improve consistency with the rest of the module."

This not only makes the comment more actionable, but also reveals the reviewer’s thinking. It opens the door for meaningful discussion if the author disagrees. And if the reviewer can’t provide a good “because,” they are forced to reconsider if the comment is truly worth making.

This technique provides:

• Clarity - Reduces ambiguity.
• Justification - Anchors review comments in objective reasoning.
• Trust - Helps authors see that comments are about code, not preferences.
• Efficiency - Prevents drawn-out back-and-forth over misunderstandings.
   

Tselovalnikov urges that every single comment, without exception, should include a “because” clause. If you can’t formulate one, then the comment likely isn’t important enough to block the PR.

The hidden cost of ignoring the rules

It’s tempting to break these rules, especially as a senior engineer. You’re overbooked, or the code needs a lot of work, or the author is someone new. But this is exactly when discipline matters most.

Why? Because senior engineers set the tone for team culture. If you delay reviews, others will follow. If you leave vague or abrupt feedback, junior team members will imitate it. Code review culture isn’t defined by the official checklist in the onboarding docs, it’s defined by daily behavior.

One of the most insidious traps is normalizing delay. If a senior staff engineer takes two days to start reviewing a big change, the team learns that such latency is acceptable. Soon, even trivial PRs take days to move forward. And the development process calcifies.

On the flip side, consistent use of these two rules has a powerful cultural effect. Fast, thoughtful reviews raise the energy and pace of the team. Explicit reasoning in comments raises the bar for communication. The cumulative effect is a culture where code review feels like a productive collaboration, not a bureaucratic gate.

When the Rules Don’t Apply

Tselovalnikov is careful to note that these rules are best suited for collaborative teams working toward a shared goal, like a product team at a company or a student project group. In open source or highly asynchronous environments, things are different.

In those cases, contributors and reviewers may not share context or priorities. Reviewers are often volunteers, and the cost of accepting poor changes can be very high. In that case, minimizing review time isn’t the most important priority, rigor and risk mitigation might be.

But even in open source, the spirit of the rules can help. Thoughtful comments with clear reasoning are appreciated universally. And prompt responses, even if they aren’t approvals, help contributors feel heard.

The beauty of Tselovalnikov’s guidance is its simplicity. No giant framework. No meetings. Just two rules:

• Minimize response time - Don’t wait. Respond now.
• Include “because” in every comment - Be specific and clear.
   

These rules work because they aren’t about tools or process, they’re about habits. And habits are what shape engineering culture over time.

By embracing these rules, engineering teams can remove unnecessary friction from code reviews, accelerate iteration, and build a culture of fast feedback and mutual respect. These are not just practices for better pull requests, they are practices for better teams.