Sixty files, two minutes, LGTM.
“A PR changes 60 files and two minutes later it's approved with LGTM.” You know nobody read it. Neither did you, last time it was your turn.
Writing got faster. Reading didn't.
Reviewers have the same hours they always had, now facing far more changes. Each one assumes someone else checked the risky part, and the tests passed, so approving feels safe.
But a passing test only tells you the change didn't break what the tests already checked.
What doesn't work.
“Just review harder.” Willpower doesn't scale with output.
An AI reviewer that summarizes the change. You end up reading less, not more.
Requiring two approvals. You get two rubber stamps.
Trusting green tests. A change can add behaviour its tests never exercise.
What actually helps.
Most of this isn't us.
Hard size limits on PRs. Split the 60 files.
Ask the reviewer to break one thing the PR claims to fix, and watch a test go red. If nothing goes red, the test doesn't cover it.
Make an approval say what was checked, not just “LGTM”.
Use code owners for the risky paths, so the right person is required.
A second reader who breaks things on purpose.
Every change we ship gets one read from someone who didn't write it. The reader looks at the change and its tests only, then deliberately breaks the change and checks that a test notices.
On one change, four deliberate breaks turned the tests red and a fifth left every test green, which showed a check nothing covered. The same read found a PATH entry that let a program skip its own trust check. Both were fixed on the branch, before the change shipped.
We added this rule after our release checks, which run on all of a release's changes combined, turned up 10 failures that only appeared in combination and that each change's own tests had missed.
| What was measured | What the record says |
|---|---|
| deliberate breaks on one change | 5 planted, 4 caught by tests, 1 left every test green |
| found by the same read | a PATH entry that skipped the program's own trust check, fixed before shipping |
| failures that only appeared with changes combined | 10, in one release candidate |
| recorded | 13 and 14 October 2026 |
| where it's from | Vinculum's own project record, which runs on Vinculum |
Where a shared memory fits.
Vinculum keeps the review as a record: what was broken on purpose, what went red, what stayed green.
It doesn't add reviewer hours. More output can make skimming worse, so the record has to say what was actually checked.
Common questions.
Can't an AI reviewer just do this?
It can do the breaking and re-running. What matters is that the read is done without the author's explanation and that it plants failures, whoever does it.
Isn't the real fix just smaller PRs?
Smaller PRs help a lot. They still need a review that checks something the tests don't, or they're just smaller rubber stamps.