Good code review advice doesn't come from threads with 🚀 in them

Code reviews used to be a quiet, dignified affair—an async ritual where you thoughtfully (or passive aggressively) gave feedback and occasionally dropped a “nit: maybe rename this var?” comment to feel alive. But then social media got involved. Now, developers are sharing hot takes about code reviews, many of which sound like they were written by someone who’s never met another human being.

In one corner, we have Twitter influencers claiming you should “just merge it and fix it later” because iteration (and downtime) is life, apparently? In another, LinkedIn grindset bros are insisting that real devs don’t need code reviews because “you should trust your team.”

And then there’s the advice that seems like trauma disguised as tradition: “Our team just roasts each other’s code live on Fridays. It builds character.” Or: “We only do in-person code reviews, it keeps people honest.” Translation: we’ve replaced the comments section with live humiliation. Bold strategy.

To illustrate the impact of influencers on development cycles, we created a comic. The Battle of the Bathrobe Influencers playfully pokes fun at some of our favorite influencers and how many different code review takes there are on the timeline right now and how that might affect individual developers if teams actually listened to and followed all the competing takes. No influencers were harmed in the making of this comic… we hope.

At CodeRabbit, we love a good code review etiquette debate but we also like shipping code and keeping our coworkers emotionally intact. So, we’ve put together a list of some code review bad takes we’ve seen floating around the timeline—and what to do instead if you don’t want your team quietly scheming your removal from the repo.

Bad code review trend #1: The “Just merge it” mentality

If you've ever seen a pull request titled “WIP – just gonna merge this for now,” you’ve met a ‘Just merge it” dev. They’re disciples of the “move fast and break literally everything” school of development. They believe in shipping code quickly no matter how bad is a strength and fixing things later is part of the agile lifestyle.

But here’s what actually happens when you merge bad code to “fix later”: you don’t fix it later. No one does. It goes to production. It breaks. Now your teammate is debugging a mystery bug on a Sunday night and slowly whispering your name like it’s part of a ritual curse.

If you’re trying to speed things up, here’s a radical idea that’s better than just merging it: review your own code before you ask someone else to. Give it a read with fresh eyes. Clean up nonsense logic, remove dead code, and maybe run it through an AI reviewer like CodeRabbit in your IDE so you don’t miss something humiliating (like importing a library you’re not even using. Again).

Bad code review trend #2: “Code reviews are for juniors”

Another fun trend: the belief that once you hit “Staff Engineer IV (Ascended Form),” code reviews are beneath you. You’ve achieved such enlightenment that no mortal can possibly understand your code.

This mindset turns senior devs into unreviewable wizards who vanish into architectural side quests and return weeks later with 2,000-line PRs and the words “don’t worry, I tested it.”

Here’s the truth: the more senior you are, the more important it is to have your code reviewed. Not because you don’t know what you’re doing but because your work is more impactful, more complex, and more likely to become the terrifying foundation for everything built after it. If that code is flawed, future developers will suffer.

Plus, code reviews are a two-way street. Senior engineers can model how to give constructive feedback, share architectural context, and mentor others by writing thoughtful comments. They can also learn from junior devs who ask great questions or spot something weird because they’re not desensitized to your obscure variable naming scheme yet. So, don’t skip reviews. Normalize them at every level.

Bad code review trend #3: “Nitpicks are toxic”

There’s a growing movement online that says nitpicky comments in code reviews are basically microaggressions. That if you suggest someone rename a variable or break up a 30-line function, you’re stifling creativity and slowing down development for no good reason. Look, we get it. No one wants to receive 14 comments about whitespace and whether it’s “utils” or “helpers.” But not all nitpicks are created equal.

The truth is, a lot of “tiny” things in code aren’t actually tiny. They’re death by a thousand readability cuts. Codebases rot from the inside out when no one sweeps up the small stuff. Confusing names, inconsistent structure, or one-off edge case handling eventually add up to a debugging experience best described as “psychological horror.”

That said, nit-level feedback shouldn’t feel like an attack. The goal isn’t to flex your encyclopedic knowledge of the company style guide—it’s to help your teammate write code the next person (and the next-next person) can understand. You can do that without sounding like a passive-aggressive linter.

Start by offloading the basics to, well… actual linters. CodeRabbit, for example, comes with 30+ linters built in, so you don’t have to waste brain cells correcting indentation or lecturing someone about semicolons. That frees you up to focus on logic, clarity, and architecture—things humans are best at.

Bad code review trend #4: Frequently turning code reviews into a performance (aka the live review trap)

You know what’s great about pull requests? You can review them in sweatpants at 10pm, covered in crumbs, muttering to yourself in peace if you want. You know what’s not great? Being called into a surprise Zoom meeting where your manager shares their screen and says, “Let’s walk through your code together... as a team.”

Live code reviews are the latest workplace horror disguised as collaboration and “context sharing.” And sometimes they are! But often they’re just a weird hybrid of interrogation and performance art. You sit there while someone scrolls through your functions like they’re auctioning off your dignity and other devs chime in with helpful thoughts like, “Yeah, I had questions about that, too.”

These sessions are especially rough for junior devs, introverts, or literally anyone who doesn’t enjoy public code autopsies. They discourage honest feedback (because who wants to be the one to say “this is confusing” in front of the CTO?) and eat up everyone’s calendars. What could’ve been solved with three async comments now requires a 45-minute meeting and an existential crisis.

There is a place for live code reviews—but it’s not “every sprint, all the time.” Use them intentionally: for onboarding, gnarly architectural changes, or postmortems. And if you’re going to do one, give people a heads up.

Bad code review trend #5: Not reading through your AI-code first

As if things weren’t chaotic enough in development, we now have AI entering the scene like a caffeinated intern who means well but keeps hallucinating entire modules. AI coding tools are powerful – but also deeply chaotic. They’ll give you working code and sprinkle in a few imaginary functions for flavor.

We’ve seen it all: five-thousand-line PRs with variables named foo7, random timeouts, and logic that reads like someone asked ChatGPT to explain taxes using only metaphors. Sometimes it even compiles! But that doesn’t mean your AI sidekick didn’t also sneak in a few logic bugs, duplicate code blocks, or functions that only make sense if you’re a large language model yourself.

AI tools are here to help – not replace critical thinking. If your workflow is “vibe prompt, commit code, start lunch,” then yes: you’re part of the problem. Review what your AI assistant wrote. Refactor. Sanity check. And for the love of merge conflicts, run a local AI review before unleashing it on your team.

CodeRabbit’s AI reviewer in your IDE can catch a lot of issues before your teammates have to. It’s like having a robot tell you your fly’s down before you walk into a meeting – deeply appreciated and MUCH less awkward than your boss doing it.

Code review etiquette: How to be a code reviewer people want to work with

Let’s say you’ve made it through this blog post without recognizing yourself in any of these horror stories. You win! Now, let’s level up: how do you become the kind of reviewer people actually like getting feedback from?

• Start by being human. Leave thoughtful comments that explain the why, not just the what.

• Ask questions when something’s unclear instead of assuming malice or incompetence.

• If something’s genuinely clever or elegant? Say so! A simple “nice work” in a PR can be a game-changer—especially when the rest of the comments feel like homework corrections.

• It also helps to not sound like a compiler error in human skin. Use a friendly tone. Emojis are fine in moderation (a well-placed 👀 or 🎉 goes a long way).

• You can even sprinkle in a bit of humor, assuming your teammate isn’t currently crying over merge conflicts – or maybe because they are and you want to make them laugh.

The golden rule of code review etiquette is simple: give the kind of feedback you’d want to receive. And maybe don’t reply to every comment with a Notion doc defending your variable naming philosophy. Life’s too short.

Want an AI reviewer that won’t give bad advice? Try CodeRabbit in your IDE and git-platform.