Code Review Is Not About Catching Bugs
March 23, 2026

My former Parse colleague Charity Majors – now CTO of Honeycomb and one of the strongest voices in the observability space – recently posted something that caught my attention. She’s frustrated with the discourse around AI-generated code shifting the bottleneck to code review, and she argues the real burden is validation – production observability. You don’t know if code works until it’s running with enough instrumentation to see what it’s actually doing.
But I think the “code review is the bottleneck” crowd and the “no, validation is the bottleneck” crowd are both working from the same flawed premise: that code review exists primarily to answer “does this code work?”
Code review answers: “Should this be part of my product?”
That’s a judgment call, and it’s a fundamentally different question than “does it work.” Does this approach fit our architecture? Does it introduce complexity we’ll regret in six months? Are we building toward the product we intend, or accumulating decisions that pull us sideways? Does this abstraction earn its keep, or are we over-engineering for a future that may never arrive? Does this feel right – not just functionally correct, but does it reflect the taste and standards we want our product to embody?
We’ve been hearing "code generation was never the bottleneck" for quite some time from people who are skeptical about the impact of identity coding systems on software development.
They observe, rightly, that other parts of the software development cycle are equally, if not more, time-consuming. One of those being code review.
Code review is a practice, not an outcome. What’s the outcome we’re trying to achieve? And it is, as Charity Majors has observed elsewhere Validation.
Here David Poll digs a little deeper and observes…
Tests answer “does the code do what the author intended.” Production observability answers “what is the system actually doing.” Code review answers “was the author’s intent the right thing to build?”
You need all three. None of them substitutes for the others.







