Why Skipping Code Reviews Might Enhance Productivity

I discovered Raycast recently, and it’s been the single biggest boost to my daily productivity in years. A launcher that actually works the way a developer thinks - fast, extensible, and beautifully designed.

What surprised me more than the product itself was learning how their team works. Raycast doesn’t do code reviews by default. In a world where code reviews are treated as a non-negotiable best practice, that’s a bold stance.

How It Works at Raycast

Their approach, detailed in this blog post, boils down to a few key ideas:

Trust over process. They hire experienced engineers and trust them to ship quality code. Reviews happen when the author requests them - for complex changes, unfamiliar areas, or when they want a second opinion. But it’s opt-in, not mandatory.

Speed compounds. Removing the review bottleneck means PRs don’t sit idle for hours or days waiting for someone to look at them. Engineers stay in flow. Features ship faster. The feedback loop between writing code and seeing it in production gets shorter.

Ownership replaces gatekeeping. When you know nobody is going to catch your mistakes, you write more carefully. You test more thoroughly. You take full responsibility for what you ship.

Would This Work Everywhere?

Probably not. Raycast has a small, senior team working on a focused product. That’s a different context than a 50-person team with varying experience levels working on a complex enterprise system.

But the underlying question is worth asking: are your code reviews actually catching meaningful issues, or are they mostly a ritual? If reviews in your team have devolved into style nitpicks and rubber-stamping, the overhead might not be worth it.

The lesson isn’t "stop doing code reviews." It’s that every process should earn its place. If a practice isn’t delivering clear value for your team, it’s worth questioning - even the ones everyone assumes are essential.