Self-Hosted AI Code Review: The Assumption Hiding in the "Review Less" Debate

Rachel Laycock, CTO at Thoughtworks, published Maybe We Shouldn't Be Reviewing All This Code on martinfowler.com this Tuesday. It reached the front page of Hacker News and collected 73 comments, which for an essay about review process counts as a brawl.

The numbers she relays from Brian Houck of DX are stark. At Meta, significant lines of code per human-landed diff reportedly grew 106% in a year. DX's own data shows median pull request size up 64%. Code is being produced faster than humans can read it, and the review queue is where the collision shows up first.

Her argument: "we've been using code review to solve the wrong problems." Teams stuff knowledge sharing, mentoring, architecture alignment, and formatting arguments into a ritual that was meant to catch defects. Her fix is to move judgment left, into pairing and design sessions, and automate everything deterministic. In her words, "we really shouldn't still be arguing about whitespace in 2026."

We build an AI code review tool, so we read the piece twice with a highlighter. Half of it is correct, and the other half rests on an assumption the whole thread skipped.

What the argument gets right

The teaching parts of review should not happen in a diff thread. A comment arriving three days after you wrote the code is a bad teaching medium: you have context-switched twice since then, and the lesson lands as criticism. Pairing, mob sessions, and up-front design conversations do that job better. Laycock is right to push them.

She is also right that much of what fills review queues was never judgment work. Formatting. Unused imports. A test that asserts nothing. A regex recompiled inside a loop. A machine catches these every time, at any hour, and stays consistent about it. Humans should spend attention where interpretation pays.

The interesting part is what "automate it" implies.

The assumption nobody named

Every mainstream AI code reviewer is a cloud service. Per-seat pricing, diffs shipped to an external API, findings rendered in a dashboard you do not control. Automating the boring parts of review has quietly become an agreement to upload your proprietary source to a third party on a subscription.

For many teams that trade is acceptable. For teams building fintech, health, or government software, pasting a diff into an external API can be a reportable incident. There is also a second-order issue: when your review gate is a SaaS, your review gate has an outage schedule, a pricing page, and a roadmap you do not vote on. CI should fail because the code is wrong, not because a vendor had a bad Tuesday.

So the debate argues over how much review humans should do, and skips the question of where the automated layer should run. That question already has an answer, if you want one.

How it works

Disclosure: cora-code is our project, an open source AI code review CLI, so weigh what follows accordingly. It is Rust, Apache-2.0, at 24 stars and 30 releases since May, which is a polite way of saying early. It runs where your code already lives: your laptop, a pre-commit hook, a CI runner you own. You bring your own model key, and the only outbound requests are the model calls you configure.

Three modes map to the layers Laycock wants automated.

Diff review at the point of change

cora review reads a diff and reports findings before anything is committed. Wired into a pre-commit hook, it is the formatting-and-obvious-bugs layer that settles the whitespace argument before a human ever sees it.

Repo-wide scan

cora scan walks the whole tree and reports findings, with SARIF output so CI systems can ingest results. This is the mode for questions about what already exists in a codebase, as opposed to what changed in this branch.

Semantic search over the codebase

cora brain indexes the project with FTS5 plus vector search, so questions work by meaning rather than exact strings. The index builds with cora index, and v0.15.0, shipped August 31, adds an opt-in vecq vector store: a pure Rust quantized index roughly 5x smaller than the previous usearch HNSW setup, with keyed persistence, so unchanged projects are not re-embedded on every run. A new brain.vector_bits knob selects the quantization width; the default residual mode scored the best recall@10 at 4-bit scan speed in our own study across 1k, 5k, and 13k symbols.

Decisions and trade-offs

BYOK means you own model choice and spend. There is no bundled model, and when a provider changes pricing, that becomes your migration. The upside is symmetrical: switching providers is a config value, and your review pipeline never inherits a vendor outage.

There is no web dashboard. cora-code prints findings and emits SARIF; your existing tooling renders them. Teams that live in polished GUIs will find the cloud products more comfortable, and that is a fair preference. We chose terminal-first because that is where the go or no-go decision happens for the kind of developer who adopts a 24-star tool.

And 24 stars is the real number; you would be an early adopter, finding edges we have not. The incumbents have support teams and ecosystems. What you get on this side is a code path you can read, an Apache-2.0 license, and a review gate where your source goes only to the model provider you picked, under your key.

What's next

The vecq store is opt-in for this release (brain.vector_store: vecq in .cora.yaml) while we collect recall numbers on real codebases. If you run it against a large repo, the findings, good or bad, are useful to us as issues. For more context we wrote a comparison against the hosted alternatives, cora-code vs CodeRabbit vs Reviewpad, and a longer piece on semantic analysis in code review.

The "review less" position wins only if the deterministic layer runs, everywhere, every time. Whether that layer is cora-code or a five-line shell script around a linter matters less than where it runs: on your infra, under your keys, inside your CI. Judgment can move left. The mechanical layer can stay home, on hardware you control.

Try it with cargo install cora-code, or read the source first: github.com/codecoradev/cora-code.