Blog
Revund Blog
Engineering notes, product decisions, and what we're learning about AI code review.
Latest
RSS- 01
The two halves of code review
Most code-review tools pick a side. Linters and type systems handle the measurable half. AI handles the judgment half. The market keeps debating which one wins. The teams that actually ship know it was never a choice.
Read - 02
Writing code is cheap. Defending it isn't.
Authoring is no longer the scarce skill. Defending what got written is. The shift from production to judgment is already showing up in the data, and the engineers who survive it are the ones who can quote a reference when asked why.
Read - 03
The mirror problem: why a model can't review another model's code
A reviewer drawn from the same training distribution as the author shares the author's blind spots. Recent research calls this correlated failure, and it's the architectural reason a code-review tool needs an external reference, not a smarter prompt.
Read - 04
The 14% gap: why every code-review finding needs a rationale
Bacchelli & Bird showed reviewers think they're hunting bugs but mostly write nits. The deeper finding, and the one Revund's architecture is built around, is that a comment without a falsifiable rationale is indistinguishable from noise, even when it's right.
Read - 05
The 200-line cliff: what 50 years of code review research actually says
Reviewer defect-detection drops off a cliff past ~200 lines of changed code. The research is older than most engineers in the industry. We unpacked the studies, the methodologies, and what they imply for AI code review.
Read
All posts
6 postsThe two halves of code review
Most code-review tools pick a side. Linters and type systems handle the measurable half. AI handles the judgment half. The market keeps debating which one wins. The teams that actually ship know it was never a choice.
Writing code is cheap. Defending it isn't.
Authoring is no longer the scarce skill. Defending what got written is. The shift from production to judgment is already showing up in the data, and the engineers who survive it are the ones who can quote a reference when asked why.
The mirror problem: why a model can't review another model's code
A reviewer drawn from the same training distribution as the author shares the author's blind spots. Recent research calls this correlated failure, and it's the architectural reason a code-review tool needs an external reference, not a smarter prompt.
The 14% gap: why every code-review finding needs a rationale
Bacchelli & Bird showed reviewers think they're hunting bugs but mostly write nits. The deeper finding, and the one Revund's architecture is built around, is that a comment without a falsifiable rationale is indistinguishable from noise, even when it's right.
The 200-line cliff: what 50 years of code review research actually says
Reviewer defect-detection drops off a cliff past ~200 lines of changed code. The research is older than most engineers in the industry. We unpacked the studies, the methodologies, and what they imply for AI code review.
Hello, Revund
Why we're building Revund, what AI code review gets wrong today, and the bar we're trying to clear before we ship a single finding to a real PR.