Proof Carrying Review

The problem Code review is the slowest part of shipping software, and most of it is not thinking. It is reading a diff you did not write, guessing what the ticket asked for, and checking whether anything broke. Reviewers skim. Real bugs get approved while style notes collect three comments. AI reviewers were supposed to fix this and mostly made it worse. They post long lists of maybes. This could be a null reference. Consider adding validation here. Some of it is right, most is guessing, none of it comes with proof, so reviewers stop reading the bot. The problem is not that the model cannot spot bugs. It is that nobody can tell which of its twenty comments are real without redoing the review. And most AI reviewers never see what the change was supposed to do. They get the diff, not the ticket, so they call the code fine and miss that it implements the wrong thing. The solution Proof carrying review. An IBM Bob mode that reviews a pull request against its ticket and the project spec, under one rule: no finding is reported unless Bob wrote a test that fails because of it. Give it a PR. Bob gathers the diff, the ticket, the spec and the style guide, then runs four reviewers in parallel: spec conformance, bugs and security, tests, style. Every candidate finding goes to a prover subagent whose only job is to turn that claim into a failing test and run it. If the test passes, the claim was wrong and it is dropped before a human ever sees it. What survives arrives with the test attached, so a reviewer confirms a real bug in seconds instead of arguing with a chatbot. Bob then patches the mechanical findings and reruns the suite until green. The output is REVIEW.md plus findings.json, rendered as a dashboard: every finding, the test that proves it, the fix diff, a scoreboard. Who it is for Anyone who reviews pull requests for a living. You point Bob at a PR and get back a dashboard where every claim is proven, so your attention goes to design and intent instead of typos. Why it is different Most AI review tools try to find more. This one tries to be trusted. The proof rule makes noise structurally impossible, because a claim that cannot fail a test never reaches you. Reading the ticket and the spec also catches the bug that clean looking code hides, the feature that works perfectly and does the wrong thing. How we know it works We built a separate repo of twelve pull requests against a written spec, with nineteen bugs planted by hand and two clean PRs as controls, and kept the answer key out of the repo so Bob never saw it. Every number on the dashboard comes from that run, scored against the planted list and placed next to an ordinary single pass review of the same PRs. Review you can check. That is the whole idea.