The reviewer
Usually a senior engineer. Reads about twice the code per change that they did two years ago, in the same time.
Why Vera
The datapicked it.
AI doubled the code in every change, and review didn't speed up to match, so reviewers started reading less. Before building anything, I set out to find where product teams actually lose time, how big the problem is, and whether someone has already solved it. This page is the case for what I chose to build.
2×code per changeMedian lines per merge request went from 37 to 76 in two years. Time to merge stayed flat (75 h to 69 h).
-38%review attention per lineReview comments per line of code, same period. Exploratory.
22%of changes written with AIUp from 3% a year earlier: merge requests that disclose AI help. Disclosure undercounts use.
2.2×wait when several roles sign offSmall changes reviewed by people from 2+ roles (95% interval 1.63–2.91×).
Measured on GitLab's product repo, which is developed in public: 105,397 merge requests, roles from its public team page. See the work data
Why now
AI-assisted changes went from rare to routine within a year. The amount of code arriving for review doubled, and the time teams spend on it didn't move. Something had to give, and it was attention.
Merge requests that disclose AI help, by month
Show as table
| Month | AI-disclosed |
|---|---|
| Oct 2025 | 2.9% |
| Nov 2025 | 3.8% |
| Dec 2025 | 2.4% |
| Jan 2026 | 3% |
| Feb 2026 | 2.5% |
| Mar 2026 | 9.4% |
| Apr 2026 | 11.2% |
| May 2026 | 10.8% |
| Jun 2026 | 15.5% |
| Jul 2026 | 13.7% |
| Aug 2026 | 7.5% |
| Sept 2026 | 18.7% |
| Oct 2026 | 22.3% |
Lines changed per merge request
Show as table
| Month | Median lines |
|---|---|
| Q4 '24 | 37 lines |
| Q1 '25 | 40 lines |
| Q2 '25 | 34 lines |
| Q3 '25 | 37 lines |
| Q4 '25 | 47 lines |
| Q1 '26 | 56 lines |
| Q2 '26 | 52 lines |
| Q3 '26 | 76 lines |
Time to merge
Show as table
| Month | Median hours |
|---|---|
| Q4 '24 | 75 h |
| Q1 '25 | 78 h |
| Q2 '25 | 73 h |
| Q3 '25 | 67 h |
| Q4 '25 | 74 h |
| Q1 '26 | 80 h |
| Q2 '26 | 78 h |
| Q3 '26 | 69 h |
In their words
2,000 posts, read and coded at random.
Each dot is one of them. Of all the pains people described, the ones around AI-made changes are by far the biggest group: 39% of relevant posts, and 46% of first-hand accounts.
- 222 describe a pain first-hand
- 350 discuss one
- 1,428 aren't about a pain
Nobody understands the code
“I cannot have a productive code review with someone that does not even understand what their code is actually doing”
How big each pain is
Twelve pains scored on how common they are, what they cost, whether someone has a budget for them, how well they're already solved, and whether agents suit them. The weights were fixed before scoring. The top two stay on top in 98% of runs when every judged score is nudged up or down by one.
Show as table
| AI-written code needs cleaning up | 53 | 18% of relevant posts · top 3 in 98% of nudged runs |
| Code review is overloaded | 53 | 12% of relevant posts · top 3 in 98% of nudged runs |
| Supervising agents is hard | 45 | 8% of relevant posts · top 3 in 41% of nudged runs |
| Knowledge lives in people's heads | 45 | 6% of relevant posts · top 3 in 33% of nudged runs |
| Nobody understands the code | 42 | 4% of relevant posts · top 3 in 16% of nudged runs |
| Approvals and sign-offs stall work | 42 | 1% of relevant posts · top 3 in 3% of nudged runs |
| Vague or changing requirements | 40 | 6% of relevant posts · top 3 in 7% of nudged runs |
| AI tools lack the team's context | 39 | 4% of relevant posts · top 3 in 2% of nudged runs |
| Tech debt never gets prioritised | 38 | 8% of relevant posts · top 3 in 2% of nudged runs |
| Interruptions and context switching | 36 | 6% of relevant posts · top 3 in 1% of nudged runs |
| Too many tools | 35 | 6% of relevant posts · top 3 in 0% of nudged runs |
| Non-engineers depend on engineering | 31 | 1% of relevant posts · top 3 in 0% of nudged runs |
Who it's for
Teams of 10 to 200 engineers who've adopted coding agents, ship UI, and have design or security people who review changes. Sign-off across roles hurts them most.
The engineering manager
Answers for quality and delivery. Sees the review queue, the fix-ups after merge, and the senior engineers running out of attention.
The head of engineering
Already pays $20–72 per developer a month for review tools. Vera sits in that budget, as the layer above the bots.
Design, security, product
Asked to approve changes in a tool they don't live in. On small changes, that's where most of the waiting happens.
The market, and where Vera fits
The products closest to this problem, against the four things still unsolved: how much human reviewers can get through, proof they understood the change, sign-off across roles, and doing the rework. AI review bots are close to a commodity and auto-fix is crowded. Nothing checks understanding, and cross-role sign-off is partial at best.
| Product | Throughput | Understanding | Sign-off | Rework | Price |
|---|---|---|---|---|---|
| VeraMaps the change, checks understanding, coordinates every role's sign-off | partly | yes | yes | no | review-tool budget |
| CodeRabbitAI review comments, walkthroughs, auto-fix | partly | partly | no | yes | $24–72/user |
| Graphite + Bugbot (Cursor)Stacked PRs, review inbox, merge queue, AI review | yes | no | no | yes | $20–40/user |
| GitHub Copilot reviewAI review inside GitHub, agent fix PRs | partly | no | no | yes | bundled with Copilot |
| Claude Code ReviewVerified, ranked findings; never approves | partly | no | no | no | token usage |
| AviatorReviewer routing, review time targets, spec approval | yes | partly | partly | no | $20–50/dev |
| Slack CodeAgents in Slack channels, previews | no | partly | partly | yes | in Slack plans |
| Chromatic UI ReviewVisual diffs, design sign-off as a check | no | partly | partly | no | $179–399/mo |
| LinearB gitStreamPolicy routing, auto-approve low risk | yes | no | partly | no | $29–59/user |
From a teardown of public docs, pricing pages and reviews, October 2026. Vera doesn't do rework by design: it uses the bots' findings and fixes instead of competing with them.
It makes each review faster, without skipping the reading
Reviewers see what to look at first, each role gets a brief instead of the whole diff, and Vera answers questions from the code. Sign-off goes to everyone at once. Success is fewer reviewer minutes per 100 lines and less waiting for sign-off, measured from the traces.
It proves someone understood the change
On risky changes, reviewers answer a couple of questions about it, or explain it in their own words. The answer is graded and recorded on the approval. Nothing on the market does this.
Every role signs off, in parallel, on one record
Rules in the repo decide who has to approve: design for UI, security for auth, product for behaviour. Vera asks them all at once, gives each what they need to judge, and keeps one record.
It sits above the review bots
Vera reads what CodeRabbit, Copilot or Claude Code Review found, and doesn't add another stream of comments. The bots look for problems; Vera makes sure a person made the call.
Trade-offs
Each decision, what I chose it over, and why.
Record understanding by default; teams can turn it into a gate
- Over
- Blocking merges until a reviewer passes
- Why
- A mandatory quiz on every change becomes its own theater. Recording it keeps the friction low and still shows on the approval when nobody understood.
Read-only agents
- Over
- Agents that run code or push fixes
- Why
- Auto-fix is the most crowded part of the market, and running a pull request's code is a security risk. Vera's job is judgment, not edits.
Agents propose, code decides
- Over
- Letting a model decide who must sign off
- Why
- Who must approve and what blocks a merge have to be predictable and auditable. Those are rules in the repo, a check run, and an append-only record.
A layer above the review bots
- Over
- Another review bot
- Why
- First-pass AI review is close to commoditized. The unsolved part is underneath: understanding and sign-off.
Likely AI-written changes raise the stakes: the code owner, a second reviewer and the understanding check
- Over
- A slop score for every change
- Why
- AI-written code needing cleanup tied for the biggest pain, but rating code is what the review bots already do, and a score per author would be surveillance. Vera makes sure the right person looks, and says why.
Vera explains the change to each reviewer, from the code, with the lines it used
- Over
- An assistant that answers anything
- Why
- Understanding is the point, so Vera should help people get there, not just test them. But it won't give away the answers to an open check, and it says when something isn't in the code instead of guessing.
GitHub first
- Over
- GitLab first, where the evidence came from
- Why
- Most teams and review bots live on GitHub. The core doesn't depend on the platform, and the evals still run on GitLab's history.
Runnable without a server first (run viewer, CLI, GitHub Action), then Slack
- Over
- A hosted app from day one
- Why
- Weeks instead of about twice that, and no holding other people's code on my servers. Slack comes next, because that's where design and product sign off.
Team-level numbers only
- Over
- Individual understanding scores
- Why
- Ranking people by quiz results would turn Vera into surveillance, and that's one of the conditions that would kill it.
What the data ruled out
Including my own first idea. Each was written down with what would disprove it, before the data came in.
My original idea: let non-engineers ship small changes (Blast Radius)
It ranked last of 25 pains in the coded posts. At GitLab, non-engineers' small changes were approved faster than engineers' (0.59x). I dropped it.
Review is getting slower
Time to merge stayed flat over two years while volume rose 55%. The cost of AI code is attention, not speed.
AI-assisted changes take longer to merge
They don't: the medians are within 7% at every size. They do draw more review comments.
Approval delays as the headline
Only 1–3% of posts mention them, even though they measurably slow small changes 2.2x. So they're part of the product, not the pitch.
What would make me stop
- Reviewers skip or game the checks (opt-out above 30% after two weeks).
- Routing can't reach 70% on GitLab's historical merge requests.
- Teams see it as surveillance.
7 / 5
Every hypothesisHypotheses supported and disproved, each written down with what would disprove it before the data came in. Including my own first idea.
How the evidence was gathered
Measured in full where the data allowed it, sampled at random where reading every post wasn't needed. Every plan, search term and scoring rule was committed before the data it applies to.
105,397merge requests, measured in fullEvery GitLab MR over two years: review time, size, and who opened and reviewed it
36,769posts searched and cleanedFrom 78,276 pulled. Posts that matched a search term only by typo were removed
2,000read and coded, at randomA random sample is enough to rank pains: every share carries a 95% interval, 2–4 points either way. Two independent passes agreed on 96.5% of posts
7 / 5hypotheses supported / disprovedEach written with what would disprove it first. 4 open or untestable
All the evidence · Every hypothesis · Work data · The codebook