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 was how the team works. Raycast doesn’t do code reviews by default. Most teams treat review as non-negotiable, so that stood out.

How it works at Raycast

Their reasoning, laid out in this blog post, comes down to trust. They hire experienced engineers and let them ship without a mandatory gate. Reviews still happen - for a complex change, an unfamiliar part of the codebase, or just a second opinion - but the author asks for them. They’re opt-in.

The payoff is speed. PRs don’t sit for hours waiting on someone, so engineers stay in flow and the loop between writing code and seeing it in production stays short. And there’s a quieter effect: when you know nobody’s behind you to catch a mistake, you’re more careful. You test more. You own what you ship instead of leaning on the reviewer to flag what you missed.

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.