Let agents write it. Prove it's safe to merge.
The bottleneck stopped being how fast code gets written. It's whether anything can vouch for it. fastverk computes what a change can actually reach in the real Bazel graph, runs exactly those tests on your own remote execution, and writes the verdict back to the pull request as a native check — so review is a decision, not an archaeology project.
Writing the code was never the hard part.
It is now genuinely cheap to produce a correct-looking change. It is not cheap to know one is safe.
A reviewer approving an agent's pull request is doing something the old workflow never asked of them: vouching for code nobody wrote. The habits that made review work — you recognize the author, you know what they were working on, you can guess what they forgot — are all gone. What's left is the diff, and a diff has never been able to tell you what it might break three repositories away.
So the gate has to carry the weight review used to. Not "did the tests pass" — which tests, chosen how, and would this change have been caught if it were wrong.
Push → reach → run → verdict.
Four steps, none of which ask a human to guess what a change touches.
Push
An agent opens a pull request. The build subscriber picks up the push and resolves it against the Bazel module graph — no per-service pipeline to write, and no YAML that has to be kept honest by hand.
Reach
Blast radius is computed as reverse-dependencies in the real graph: every target that transitively depends on what changed, across repository boundaries. Not a directory glob, and not a guess from the diff.
Run
Exactly those targets build and test on your own remote execution. Hermetic, cached, and reproducible — so the same change yields the same answer tomorrow.
Verdict
assess_merge checks that the build actually exercised the change before it can go green, then forge writes the result back as a native Check Run attributed to the signed-in user.
The dangerous build isn't the red one.
It's the green one that tested nothing at all.
A build can pass because the change was correct. It can also pass because the change resolved to zero test targets — a misconfigured package, a target that lost its dependency edge, a glob that stopped matching. Both look identical on the pull request: a green check.
That is the specific hole assess_merge exists to close. A build whose computed target set didn't actually reach the change won't report green; it reports that it proved nothing, which is a different and far more useful answer. On the forge side, a neutral or skipped check maps to canceled rather than success — so an absent result can never be read as a pass.
Reach is computed, not configured.
The alternative asks every team to describe, by hand and in advance, what their change might break.
What the reviewer actually sees.
One row per change: what it can reach, what ran, and whether the gate is willing to vouch for it. Values illustrative.
| change | author | blast radius | verdict |
|---|---|---|---|
| #4182 bump rules_cc_cross | migrate-toolchain-7f3 | 312 targets · 9 repos | SAFE ✓ merged |
| #4183 widen retry window | fix-flaky-cache-9c2 | 24 targets · 1 repo | SAFE ✓ merged |
| #4184 drop unused dep | tidy-deps-2a8 | 0 targets | BLOCKED — tested nothing |
| #4185 change proto field | schema-evolve-b41 | 1,004 targets · 22 repos | building… |
A change won't go green while breaking a test it never thought to run — because the gate chooses the tests, not the change.
Backed by shipping plugins.
Each claim on this page is anchored to a plugin that provides it. The site build resolves these cross-references against the live feature catalog and fails if one of them doesn't exist — so this list can't quietly outlive what the platform ships.
Computes the blast radius as reverse-dependencies in the real Bazel module graph, turns the push into a graph-scoped build on your own RBE, and blocks a green build that tested nothing.
plugin detail →Writes the verdict back to the pull request as a native Check Run — and maps a neutral or skipped check to canceled, so an absent result never reads as a pass.
plugin detail →Agent work is an Agent / AgentTask CR with explicit spawn → handoff → merge lineage, so the change has a provenance trail before it reaches review.
plugin detail →The remote execution that ran the gate, live — cache, workers, queue, latency — so a green traces back to real execution rather than a cached assumption.
plugin detail →Agents ground in your actual code units — functions and classes, deep-linked to exact lines — before they change one.
plugin detail →Adjacent problems.
Turning agents on is a one-line change. Deciding what they may touch, whose authority they carry, and how you stop them is the actual project.
Read more →At a hundred merges a day, testing everything is too slow and testing the diff is too little. The graph knows which answer is right.
Read more →Prove it's safe to merge.
Hosted, or launched into your own AWS account. Start free — no card required.