Claude and I have been on an adventure trying to reverse engineer code review. It’s superficially a good idea, but on a deeper level probably less ROI than I initially thought.
The issues review missed weren’t followed by bugs any more often than any other code, and a lot of what got enforced was one person’s preference rather than a team agreement.
https://cate.blog/2026/10/13/attempting-to-reverse-engineer-code-review/
@cate Thanks for doing this. Lots of good thoughts. The additional model for code review I don’t see discussed is where developers are on call for their own collection of microservices that they are working on. To get off call, someone else needs to know enough about the current state and recent changes, so code review becomes an emergent mechanism to not be on call all the time, and to not be called in anyway when you are supposed to be off call.
@adrianco oh interesting that is a good use of it.
@cate Putting developers on call has lots of useful side effects. Devs don’t like it, but that’s actually the point. It’s good for them, and better for the systems they are building.
@adrianco yeah I agree devs should be on call for the services they own.