# The gate isn't a suggestion. It's server-enforced. CodeHerder's verification story: required fields, checklist gates, approvals, and a review stage, cited against the code. Source: https://codeherder.com/verification/ Verification Every team adopting AI coding agents just discovered the same problem: review became the bottleneck. CodeHerder puts the checks on the server, where an agent cannot skip them. [Request access →](https://codeherder.com/get-started/#request-access) [See how it works →](https://codeherder.com/docs/how-work-flows/) 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, converge on the same finding. Shipping more AI-generated code means shipping more review debt, on top of the work already there. [441.5% median PR review time increase on teams adopting AI coding agents Faros AI, "The Acceleration Whiplash" (22,000+ developers, 4,000+ teams) · 2026 Vendor-published](https://pages.faros.ai/hubfs/AI_Engineering_Report_2026_The_Acceleration_Whiplash_Faros.pdf) [4.6× longer first-review wait for an AI-generated PR LinearB 2026 benchmarks (8.1M PRs, 4,800 teams), via secondary summary · 2026 Vendor-published, secondary source](https://byteiota.com/ai-prs-wait-4-6x-longer-linearb-2026-benchmarks/) [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](https://www.metacto.com/blogs/code-review-bottleneck-ai-development) [53.9% of AI-agent refactorings land bundled with unlabeled, unrelated feature work "Agentic Refactoring: An Empirical Study of AI Coding Agents" (arXiv) · Nov 2025 Independent](https://arxiv.org/pdf/2511.04824) [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 2026 Vendor-published](https://resources.anthropic.com/hubfs/2026%20Agentic%20Coding%20Trends%20Report.pdf) 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 →](https://docs.pytorch.org/devlogs/ai-agents/2026-05-30-ai-coding-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: todo → plan → code → review → merge → verify → done Planning can't end without written acceptance criteria. The build stage can't end without a recorded pull-request link. The build stage also lists a test, lint, and typecheck run. These checks block only when a workflow marks them required. A judge scores each attempt after it ends. A fail can send the task back to the build stage. The server enforces the gates the same way for a person's move and an automatic one. The gates ## Six gates, each server-enforced Every one of these is real code. 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 workflow can mark a test, lint, typecheck, or goal-gate check as required for a stage. A required check blocks the advance until a pass exists for the current attempt. The built-in build stage lists its checks but does not require them. A recorded fail can send the task 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. The approver is never the requester or the task's own session. This rule is always on. The gate holds an explicit status change the same way as an automatic advance. The server tells each caller if they may approve, so nobody has to guess. ### 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. ### Change-size limit A stage can opt in to a limit on the size of a change. The limit can count changed files or lines. It can also count top-level directories. When a change goes past it, the server refuses the advance and names the limit. Split the work into smaller tasks, or raise the limit. A task with no recorded size is not blocked. Who signs off ## Which check can the author not pass? The answer is one human approval on your git host. Set it up once. The agent that wrote the change cannot give it. No built-in workflow has an approval gate. You can add one to any stage. Without one, the human check is your git host. Protect the main branch and require one approval. If the host refuses the merge, the merge agent blocks the task and waits for a person. An agent review stage helps, but it is not separation of duties. The server only checks that the reviewer uses a different model tier. It does refuse some self-checks. A stage override that makes the author the reviewer fails with `self_review`. A required goal-gate pass from the author fails with `self_verification`. The server also refuses a judge result from a member who worked the attempt. Read [how approvals work](https://codeherder.com/docs/approvals/) and [the security page](https://codeherder.com/security). 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](https://codeherder.com/docs/how-work-flows/), [how approvals work](https://codeherder.com/docs/approvals/), and [how review actually happens](https://codeherder.com/docs/reviewing-work/), or see how this fits alongside device isolation and access control on [the security page](https://codeherder.com/security). Gates catch most mistakes, not all of them — [see what happens when an agent gets it wrong](https://codeherder.com/when-agents-get-it-wrong).