I do code reviews almost every day. Sometimes I’m reviewing other people’s code, sometimes mine is being reviewed. After years of this across multiple platforms, I have strong opinions about which code review tools actually work well and which ones just get in the way.

Here’s what I’ve learned from real usage, not from reading marketing material or feature comparison charts.

GitHub Pull Requests: The Standard

GitHub Pull Requests have become the default code review experience for most developers. They’re familiar, reasonably functional, and integrated with where code already lives.

The basics work well enough. You can see diffs, comment on specific lines, have threaded discussions, approve or request changes. The UI isn’t amazing but it’s usable once you learn the quirks.

What works: The integration with the broader GitHub ecosystem is valuable. Issues, projects, actions, all tie together reasonably well. The mobile app exists and while not great, it’s functional for quick reviews on the go. The draft PR feature is useful for early feedback.

What doesn’t: The review experience hasn’t meaningfully improved in years. Comparing multiple commits is awkward. Large PRs with lots of files become difficult to navigate. The suggestion feature exists but isn’t as smooth as it should be. Resolving conversations requires too many clicks.

GitHub’s main advantage is momentum. Most open source and many companies use it, so there’s massive familiarity. Learning a new code review system just to use a different platform is friction many teams aren’t willing to accept.

GitLab Merge Requests: The Alternative

GitLab Merge Requests are similar to GitHub PRs in concept but different enough in execution that switching between them regularly is annoying.

GitLab’s review features are generally more sophisticated than GitHub’s. The approval workflow is more flexible. The integration with CI/CD pipelines is tighter. For teams using GitLab as their full platform, the cohesion is valuable.

The suggestion system in GitLab is genuinely better than GitHub’s. Suggesting multi-line changes and batch-applying suggestions works more smoothly. This is a small thing but if you review code daily, small improvements compound.

The UI is busier and more complex than GitHub. There are more options, more configuration, more features. For power users, this is good. For casual users or new team members, it can be overwhelming.

GitLab’s self-hosted option is attractive to organizations with security or compliance needs that prevent using cloud services. This is a legitimate advantage over GitHub in certain contexts.

Gerrit: For the Masochistic

Gerrit is what you use when you work at Google or on projects like Android or Chromium. It’s powerful, conceptually different from PR-based review, and has a learning curve like a brick wall.

Gerrit uses a different model: every commit is reviewed individually rather than reviewing a branch of commits together. This creates different workflows and different challenges.

The advantages are real for certain types of projects. Granular per-commit review, sophisticated approval workflows, tight integration with particular development models. For projects that match Gerrit’s model, it works well.

For most teams, Gerrit is overkill with a terrible cost-benefit ratio. The learning curve is brutal, the UI looks like it’s from 2005, and the workflows are alien to developers used to GitHub/GitLab. Unless you have specific needs that Gerrit solves, there are better options.

Phabricator/Crucible/Other Legacy Tools

Some organizations use older code review tools like Phabricator or Atlassian Crucible. These were fine for their time but feel dated compared to modern alternatives.

The main reason to use these is organizational inertia. Switching code review tools is disruptive, requires migration of history and workflows, and has training costs. So teams stick with what they have even when better options exist.

If you’re choosing a code review tool today, there’s almost no reason to choose these legacy options over GitHub, GitLab, or modern alternatives. But if you’re already using them and they work, the cost of switching might not be worth it.

The AI-Enhanced Tools

We’re starting to see AI-enhanced code review tools that promise to automate review work. Some analyze code for bugs, security issues, or style problems. Others try to understand context and suggest improvements.

These work to varying degrees. Static analysis tools that check for specific patterns or anti-patterns are useful and have been for years. More ambitious AI tools that try to understand what code should do and whether it does it correctly are still pretty hit-or-miss.

The best use of AI in code review currently is automating the mechanical parts: style checking, detecting common bugs, flagging security issues. This frees human reviewers to focus on logic, architecture, and design. Tools that try to replace human review entirely aren’t there yet.

What Actually Matters in Code Review Tools

After using various platforms, here’s what I think actually matters:

Performance is crucial. If reviewing code is slow, people will avoid it or rush through it. Fast diff loading, quick navigation between files, responsive commenting, these seemingly small things make a big difference to actual review quality.

Inline commenting needs to work smoothly. This is the core interaction: select code, write comment, submit. Any friction here multiplies across every review.

Conversation threading and resolution should be clear. Which comments are addressed, which need attention, what’s still under discussion? This should be obvious at a glance.

Integration with CI/CD is increasingly important. Seeing test results, linting output, coverage changes inline with the code review streamlines the feedback loop.

Suggestion application should be easy. If a reviewer suggests a change, applying it should be simple. GitHub and GitLab both support this but with different levels of smoothness.

Mobile experience matters more than it used to. Developers sometimes review code outside normal work hours or while traveling. A functional mobile app or responsive web interface makes this possible.

The Process Matters More Than The Tool

Here’s the thing: code review effectiveness depends much more on team culture and process than on tool choice. I’ve seen excellent code reviews using basic GitHub PRs and terrible reviews using sophisticated enterprise tools.

What makes code review effective:

• Reviews happening promptly so they don’t block work
• Reviewers actually reading and thinking about the code rather than rubber-stamping
• Authors writing clear descriptions explaining what changed and why
• Constructive feedback focused on improvement rather than criticism
• Automated checks handling mechanical issues so humans focus on logic
• Clear team standards about what to review for and how detailed to be

The tool can support these things or hinder them, but it can’t create good review culture where one doesn’t exist.

My Recommendations

For most teams: Use GitHub if you’re already there, GitLab if you prefer self-hosted or value its additional features. The differences aren’t large enough to justify switching if you’re happy with either.

For open source: GitHub, purely for network effects. Potential contributors are most likely familiar with GitHub PRs.

For enterprises with specific compliance needs: GitLab self-hosted or GitHub Enterprise, depending on your broader tooling choices.

For teams using Atlassian suite: Probably Bitbucket despite its weaknesses, because integration with Jira and other Atlassian tools has value.

For teams wanting maximum review sophistication and willing to pay learning curve costs: Gerrit, but only if you have specific needs it solves.

The Real Work

Code review tools are important, but they’re still just tools. The real work of code review—reading code carefully, understanding changes, providing useful feedback, having constructive discussions about technical decisions—that work happens regardless of platform.

Choose a tool that doesn’t get in the way, then focus on doing good reviews. Clear PR descriptions, timely feedback, constructive suggestions, willingness to discuss and learn. Those habits matter more than whether you’re using GitHub or GitLab or anything else.

And please, for the love of everything, keep your PRs small and focused. No tool makes reviewing a 2000-line PR pleasant. That’s not a tool problem, that’s a process problem.

Now if you’ll excuse me, I have fourteen pull requests waiting for review, and I’m pretty sure at least three of them are going to be way too large. The tools won’t fix that, but a good diff viewer will at least make it less painful.