The problem
The code doubled. Review didn't speed up.
In a year, merge requests at GitLab that disclose AI help went from 3% to 22%, and the code in each change doubled, from 37 lines to 76. Review isn’t slow. It just didn’t get any faster, so reviewers kept pace by reading less: review comments per line fell 38%. Review has to speed up to match the code, without people approving what they haven’t read.
Research first
I let the data pick the product.
I started with a different idea, Blast Radius. Before building anything, I wrote down how I’d test it, then pulled 78,276 public posts and 105,397 merge requests, and coded 2,000 posts at random. Blast Radius came last. Reviewers drowning in AI-written code came first.
Every plan was committed before its data, and every number on the site links back to it, including the hypotheses that turned out wrong.
The product
Faster reviews, without skipping the reading.
Vera sits above the review bots and organizes each pull request so it moves faster. It maps what the change touches and shows reviewers what to look at first, including likely AI-written code nobody has checked. Each role gets a brief instead of the whole diff, and can ask Vera about the code; it answers with the lines it used. Design, security and product are asked to sign off at the same time, not one after another.
The speed comes with a check: on risky changes, the reviewer answers a couple of questions, and the result is recorded on the approval. Rules in the repo, not a model, decide who has to approve.
Where it is
Researched, designed, and running as a demo.
The research and the site are live. The demo replays a scripted run in the same trace format the real agents will write, costed with the same price table, so real runs will play in the same viewer. Next come evals on GitLab’s history, then the agents themselves, measured on two numbers: reviewer minutes per 100 lines, and time to full sign-off.