Why I continue to review code

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Fri, 01 May 2026 10:01:00 +0800

Given the increase in velocity from coding assistants such as Claude Code and Copilot, automated review had become a necessity. Since we rolled out Coderabbit on our project, almost everybody stopped reviewing code. It didn’t happen immediately, but organically.

As it turns out, Coderabbit is a formidable reviewer: with only a bit of context in the commit messages and a well-written AGENTS.md, Coderabbit will often be more thorough in reviews than most of my colleagues. And if that wasn’t enough, Coderabbit is almost always available—98.3% of the time in the last 30 days, not good for typical SLA targets but much better than colleagues—and a fraction of their cost.

Eventually everybody stopped reviewing code… Save for me.

For one thing, coding assistants can hallucinate blunders that neither humans—regrettably—nor Coderabbit will catch:

const NON_EDITABLE_BOOKING_STATUSES = new Set([
 'cancelled',
 'canceled',
 'declined',
 'withdrawn',
]);

I took that snippet from a merge request submitted yesterday. We do not have any declined or canceled statuses in our entire domain model—they simply don’t exist. I chose this example because it’s one of the simplest. The day before, a merge request had a complete re-implementation of a 200+ lines utility we already had. This happens all the time.

But most importantly, if the phone rings because of an issue on the system, I need to get on the call and fix the issue. When my work has potential to impact my personal life and my weekends with family, there’s no AI that I will trust enough. And every alert, whether it fires on the job or not, still costs the whole team velocity when we scramble for unplanned work.

Ultimately, our customers don’t care who wrote the code: “We’re sorry, Claude wrote that line and Coderabbit didn’t catch the problem” is not a good look. No matter how powerful our tools have become, responsibility is still mine. So I’ll keep on reviewing code.

AI exacerbated the divide between engineers

sylvain.bougerel@gmail.com (Sylvain Bougerel) — Sat, 25 Apr 2026 22:12:00 +0800

Any complex product requires deep context about the product’s domains, architecture, implementation. And if you want to make effective use of AI to solve a problem, you need to inject the right subset of that entire context into the prompt, or that smart auto-complete will spit out costly nonsense.

Naturally, engineers with the best understanding of the context, the capacity to articulate the problem and the skills to implement it are even stronger with AI: they can provide better input to the model and quickly validate its output. The once derided 10x engineer is starting to become a reality for anyone who can use AI to implement a correct solution at a fraction of the time it would have taken them.

On the other end of the spectrum, weaker engineers are now compelled to keep up with the pace set by their stronger peers, only they can neither prompt the LLM effectively nor validate what it produces. So they just let the garbage out—knowingly or not.

If you feel like you’ve become a “man-in-the-middle”—a proxy between somebody else’s request and an LLM—you will be phased out. The great engineers of today learned the ropes at a time AI didn’t exist, when they could invest in their fundamentals. Give yourself the same gift: carve out time to use less AI, and start learning again so you can close the divide.

Engineering on sbgrl.me

Why I continue to review code

AI exacerbated the divide between engineers