Use case
When most of the code is machine-written, review is the control
Your agents are productive. The question is no longer whether the code gets written, it is whether anybody can tell what landed and why.
What changes when volume goes up
A team reviewing eight pull requests a week reads all of them. The same team facing eighty skims, and skimming is indistinguishable from approving. The interface has to do more of the work: show only the change being reviewed, keep the conversation attached to the code, and refuse the merge when a gate is genuinely unmet.
The specific things that break first
These are the failures teams hit within a month of turning agents loose.
- Agents force push constantly, and in most forges that quietly discards review threads
- Approvals stay attached to a pull request rather than a commit, so a rewrite inherits them
- Dependent work arrives as one enormous diff, because there was no way to stack it
- A retry loop discovers merge blockers one at a time, burning an hour per pull request
How this forge answers each of them
- Threads anchor to a commit and survive a rebase, or mark themselves outdated and stay readable
- Approvals record the commit they approved, and a branch rule can dismiss them when it moves
- Stacked pull requests each diff against their parent and retarget when the parent lands
- Every merge blocker is computed in one pass and returned together
Agents are ordinary users here
Scoped personal access tokens, an identity on the pull request, and a review state they can submit. The history says who wrote what, which is the thing you will want six months from now when nobody remembers the change.
And it runs on your own machines
The code your agents read and write never leaves your infrastructure. For a lot of teams that is the difference between using agents on the main codebase and not.
Put a real review gate in front of your agents
Everything here is open source, self-hosted, and built around the review rather than around the repository.