vera

Vera · review for the AI era

Understood.Signed off.Shipped.

AI doubled the code in every change, and review didn't get any faster. Vera speeds it up to match: it shows reviewers what to look at first, briefs each role, and gets everyone to sign off at once, with proof someone understood the change.

diff · 14 files
review bots
.vera.yml rules
design · preview
security · data flow
engineering · 3 questions

Four agents, one change

A coordinator hands each pull request to four agents. They read; they never run the code or push to it.

01 / 04 · Mapper

What a reviewer sees

One comment on the pull request and one check. The comment says what changed and who needs to look; the check stays pending until the people the rules name have signed off.

veracommented on #482 · Move checkout totals to the new pricing service

What this touches

  • Checkout totals · pricing logic, 6 files
  • Order summary UI · 2 components, preview linked
  • Tests · 4 files, written with AI

Likely AI-writtenAI help disclosed, 412 lines, no tests for the new rounding, 2 bot findings still open. Added the checkout owner as a second reviewer.

Before you approve

  1. What happens to an order's total if the pricing service times out?
  2. Which existing discount codes would now round differently?

Sign-off

  • Engineering · approved, answers recorded
  • Checkout owner · asked because it's likely AI-written
  • Design · approved the preview
  • Product · asked in Slack, 2 h ago
A mock-up of the planned comment. Vera hasn't run on a real pull request yet.

Agents propose, code decides

Who has to sign off comes from rules in the repo, not from a model, including what happens when a change looks AI-written. The gate is a check run and the record only grows. An agent can suggest who should look; it can't talk its way past the rules.

# .vera.yml
signoff:
  - when: "src/ui/**"
    roles: [design]
  - when: "src/auth/**"
    roles: [security]
  - when: { label: "behaviour-change" }
    roles: [product]
ai_changes:          # likely AI-written
  add: [code_owner]
  second_reviewer_over: 200   # lines
  understanding: required
understanding:
  record: true
  gate: false   # teams can turn it on

Where it runs

Without a server first, so it's cheap to keep alive and nobody's code sits on my machines.

Run viewer

Planned

Real runs on public pull requests, replayed step by step: each agent's reasoning, tool calls, time and cost. No install.

CLI

Planned

vera review <pull request URL>, with your own API key, on any public GitHub pull request.

GitHub Action

Planned

Runs in your CI. Posts the comment, creates the sign-off check and records approvals. No server.

Slack

Planned

Later, on a demo workspace: @vera asks design, security and product to sign off in parallel, and answers questions about the change.

Why it's needed

Measured on GitLab's product repo, which is developed in public.

2×code per changeMedian lines per merge request, 37 to 76 in two years.
-38%review attention per lineReview comments per line of code, same period.
22%of changes written with AIUp from 3% a year earlier, counting only those that say so.
2.2×wait when several roles sign offSmall changes reviewed by people from two or more roles.

The full case: quotes, the market, trade-offs and what the data ruled out

Where it's at

The research is done and the foundations are in. Each step ends with something that runs and the numbers behind it.

  1. R

    Research

    Six rounds of research on public data, each planned and committed before its data was pulled, picked the problem. This site shows all of it.

    Done
  2. M0

    Foundations

    Workspace, CI, secrets handling and the trace format every run writes.

    Done
  3. M1

    Evals before agents

    Datasets from GitLab's history and a rules-only baseline: the number the agents have to beat.

    Next
  4. M2

    The agents, from the CLI

    The coordinator and the four agents on any public pull request, scored against the evals, including whether the likely-AI signals predict fix-ups better than size alone.

    Planned
  5. M3

    Run viewer

    Recorded runs on real pull requests, replayed here.

    Planned
  6. M4

    GitHub Action and understanding checks

    The comment, the sign-off check and the reviewer questions, running end to end on my own repo.

    Planned
  7. M5

    Demo company

    Seeded roles and realistic AI-written changes, measured against the targets in the case.

    Planned
  8. M6

    Slack

    Cross-role sign-off from Slack on a demo workspace.

    Planned