Verification
The gate isn't a suggestion. It's server-enforced.
Every team adopting AI coding agents just discovered the same problem: review became the bottleneck. CodeHerder shipped the fix for it before the market named the problem.
The frontier is verification, not generation
Generation stopped being the bottleneck
Five studies in the last year, four vendor- or consultancy-published, one independent academic paper, converging on the same finding: shipping more AI-generated code means shipping more review debt, not less work overall.
median PR review time increase on teams adopting AI coding agents
Faros AI, "The Acceleration Whiplash" (22,000+ developers, 4,000+ teams) · 2026Vendor-published
4.6×longer first-review wait for an AI-generated PR
LinearB 2026 benchmarks (8.1M PRs, 4,800 teams), via secondary summary · 2026Vendor-published, secondary source
25 to 40%optimal share of AI-generated code per team before review burden outweighs the gain
MetaCTO, "Code review is the new bottleneck" · 2026
53.9%of AI-agent refactorings land bundled with unlabeled, unrelated feature work
"Agentic Refactoring: An Empirical Study of AI Coding Agents" (arXiv) · Nov 2025Independent
0 to 20%of tasks developers can fully hand off without review, despite using AI for roughly 60% of coding work
Anthropic, 2026 Agentic Coding Trends Report · Jan 2026Vendor-published
PyTorch's own maintainers went further in May 2026: unreviewed AI-generated code is not accepted into pytorch/pytorch main at all. Read their playbook →
What's actually shipped
A stage schema the server enforces, not a checklist agents are asked to follow
Every task type carries a schema: an ordered pipeline of stages, and a gate on each one. A story ships through a real pipeline, for example:
Planning can't end without written acceptance criteria. The build stage can't end without a recorded pull-request link, and not without a passing test, lint, and typecheck run for the current attempt. Review can't approve past a failed judge-verification without routing the task straight back to the build stage. None of that is a norm agents are asked to respect; it's enforced the same way for a human-triggered transition and an automatic one.
The gates
Five gates, each server-enforced
Every one of these is real code, not a policy doc. See the engineering write-up for the exact function behind each one.
Required fields
A stage declares which fields must hold a value before the task can leave it. Try to advance without them and the server rejects it outright: acceptance criteria before planning ends, a merge-request link before the build stage ends.
Required verifications
A stage can require a test, lint, typecheck, LLM-judge, or goal-gate pass before it lets a task move forward. No passing record for the current attempt means no advance. A recorded fail routes the task straight back to the stage that needs fixing.
Checklist gates
Acceptance criteria live as a real checklist field. Every box has to be ticked before the task can reach a success-terminal stage, or merge. An agent can't claim done while its own list still has open items.
Approvals with separation of duties
A stage can require sign-off from a specific person or role before it advances, and that gate can require the approver to differ from the requester, an opt-in setting per gate, enforced server-side either way. The server itself answers 'may I approve this' for the caller, so nobody has to guess and get bounced.
Dependency and close gates
A task can't skip past a dependency that hasn't finished. A parent with open children can't reach done, and a join that expected every child to succeed stays blocked if one of them failed, rather than showing green over broken work.
The differentiator
Our review stage sees the whole task. A diff-scoped tool never can.
Point products like CodeRabbit, Greptile, Qodo, Graphite, and Sourcery review a diff in isolation. CodeHerder's review stage doesn't integrate any of them: it reviews with the whole task in view instead.
A diff-scoped reviewer sees a diff. Our review stage's own brief carries the task's description and acceptance criteria, the stage's declared verifications, durable workspace memory, the hand-off notes left by whoever did the work, human answers to any question asked mid-task, and a summary of the diff itself. A review that can say "this contradicts the plan's stated approach" or "this is the third rejection on this exact acceptance criterion" is making a judgment a diff-only tool structurally cannot make, integrated or not.
Want to see the gates from inside the app? Read how work flows, how approvals work, and how review actually happens, or see how this fits alongside device isolation and access control on the security page.
Round up your herd.
Bring every human and every agent onto one table. Watch what's happening, see what's stuck, and know what it's costing you, live.
Already have a workspace? Sign in