Review that works at the speed AI writes.
Every AI change is checked against what you asked for — before it merges, in your CI, no matter which agent wrote it. The reviewer opens evidence, not a cold diff. And every merged change leaves a record you can hold.
Review broke first.
AI multiplied the code arriving in review. It did nothing for the person reading it. The numbers say the checkpoint has already given way — quietly.
median review duration
And zero-review merges are up 31.3% — code is shipping with no one looking at all.
missed agent-inserted sabotage
And 56% accepted it even after a monitor flagged it. Eyeballing diffs at AI volume doesn't hold.
of agent-written fix PRs never merge
Closed without merging. Work that can't be trusted gets thrown away instead.
say the bottleneck moved
From writing code to reviewing and validating it. The constraint is now the reader, not the writer.
“I can't possibly review this volume of code.”
Not a 500-line diff. What the change means.
When a gated PR opens, the reviewer gets three things the diff alone can’t give: what the change was asked to do, what else it touches — computed from the dependency graph, not guessed — and which acceptance criteria are already proven by tests.
- orders/sync_api.pychanged — new limit check
- orders/limits.pynew file — counter + config
- orders/sync_worker.pydependent — must handle 429
- billing/usage_meter.pydependent — reads the same counter
- partners/webhook_replay.pydependent — high-traffic path
| Acceptance criterion | Test | Status |
|---|---|---|
| Over 120/min returns 429 + Retry-After | test_limits.py | PASS |
| Throttled jobs re-queue, no orders dropped | test_sync_worker.py | PASS |
| Limit configurable per customer tier | no test found | NEEDS TEST |
Machine first. Human where it matters.
The machine does the reading no human can do at AI volume. The human does the judging no machine should do alone.
Against the spec
Does the change do what the ticket and spec asked? Every acceptance criterion needs a passing test — the ones without one get flagged, not waved through.
Against memory
Has this broken before? The gate checks the change against your team’s recorded incidents and reverted patterns — so the same bug doesn’t merge twice.
Against the blast radius
What else does this touch? Computed from the dependency graph. A two-file diff that reaches a high-traffic path gets treated like what it is.
Then a human makes the judgment call — where one is actually needed.
For critical changes, the approver can be required to be a different person than whoever ran the agent. The person directing the machine doesn’t grade its work.
Every merged change produces a Change Passport.
Machine-generated at merge, committed to your git. Eight things, every time:
Change Passport
one per merged change · written by the gate- 01Why it exists — the ticket and the spec
- 02Who approved it
- 03What memory it used
- 04Which agent and model contributed
- 05The computed blast radius
- 06The tests that prove it
- 07Residual risks
- 08The rollback path
Intent-to-implementation traceability without reading AI conversations — and compliance evidence as a by-product.
Faster, not heavier.
A gate sounds like extra steps. This one gives time back — to the developer, not just the risk report.
Pre-verified PRs merge faster
The machine check runs before a human ever opens the PR. What arrives in review already carries its own proof — so the safe majority moves through quickly.
The reviewer’s clock goes down
Intent, blast radius, evidence — read in minutes. The reviewer spends attention on the one flagged item, not on reconstructing what the change was for.
The passport writes itself
Nobody fills in a form. The record is a by-product of work that already happened — the ticket, the spec, the tests, the approval.
The gate pays the developer back in time, or it’s ceremony — and we treat ceremony as a bug.
See where your review would break first.
Five minutes to your Readiness Score. Read-only, nothing written to your repo.