no_human alternative: Provefab compared
Support update, 14 October 2026: Native enforcement and login modes are restricted. Linux enforcement remains unverified; all Claude stages temporarily refuse. Select Codex or Pi. See current versions, prerequisites and protection limits.
no_human and Provefab solve the same problem the same way: an agent turns an issue into a pull request on your own machine, a second model reviews it, and nothing ships on the agent’s word alone. Both can also review a pull request a person wrote, both read repository rules, and both review risky changes harder. They differ in who reviews, how work is triggered, which platforms they run on, their license, and whether a merge can ever happen without a person. Both are good choices; this page is here to help you pick.
Side by side
| no_human | Provefab | |
|---|---|---|
| License | MIT (LICENSE) | Functional Source License, Apache 2.0 after two years (LICENSE) |
| Price | “Free and open-source” (README) | Core free; Pro EUR 79 per month per GitHub organization |
| Where it runs | “on your machine” (README); its reviewer and tamper guard also run as a GitHub Action on pull requests | Your Mac or Linux server, as a background service |
| Platforms | Download badges for macOS, Windows and Linux (README) | macOS, Linux (x86_64, ARM64) |
| Coding agent | claude (default), codex or local (BACKENDS.md) |
Claude Code, Codex or Pi, chosen per model and stage |
| Reviewer | “A different model, in a session that never saw the coder’s transcript” (README); by default it “stays on Claude”, and you can pick another reviewer backend (BACKENDS.md) | A different model provider than the implementer’s whenever your catalog has one (usage) |
| Trigger | CLI (nh task add <issue URL>) for GitHub and GitLab issues; Jira Cloud, Linear and monday.com polling; an MCP server for Claude Code or Cursor (README) |
A label on a GitHub issue, or on a Jira Cloud or Linear ticket (beta) (docs) |
| Pull requests people wrote | A GitHub Action on pull_request posts “a single pass/fail checklist comment”; nh gate --pr <url> prints the same checklist in your terminal (README) |
The provefab:review label or a /provefab review comment; one comment per pull request, edited on each review (docs) |
| Repository rules | Path-scoped rules in .no_human/verifiers.yaml, each judged on its own before the review (verification.md) |
Conventions in .provefab/rules.md, given to every stage and checked by the reviewer (docs) |
| Risk policy | A diff with a risk-flagged pattern (guard code, a deleted test, paths such as auth, secret or .github/workflows/**) always gets the full multi-round review (configuration.md) |
CI, dependencies, migrations, infrastructure, secret-looking files and paths you name get extra checks, a frontier reviewer from another provider when one is configured, a Risk section and a label (README) |
| Test checks | Your tests, a tamper guard for deleted or weakened tests, and a reproduction gate: a bug-fix test must fail on the old code and pass on the new, by default for Python bug fixes (README) | Your repository’s commands (format, lint, tests); for a bugfix, a reproduction command that must fail before the fix (Provefab stops if it passes) and runs with your checks after it (usage); deleted or disabled tests listed in the pull request under “Test changes to check”, and Pro’s auto-merge requires “no test weakened” (security) |
| Merge | “There is no auto-merge anywhere; merge is always a human action” (security.md); nh approve squash-lands the pull request when a person runs it |
Core: a person merges. Pro: optional auto-merge of small, tested changes under a policy |
When no_human is the better choice
Pick no_human if you want an MIT license or if you work on Windows. It is free, it runs locally, and its reviewer works in a session that never saw the coder’s reasoning, which is a sound design. Both tools check the tests themselves, with a different stance. no_human’s tamper guard stops an attempt that deletes or weakens a test without a reason tied to your acceptance criteria; Provefab lets the attempt finish, flags the deleted or disabled tests in the pull request, and Pro’s auto-merge refuses it. Both ask a bug fix to be reproduced first: no_human’s reproduction gate runs the offered test on the old code and the new (out of the box for Python bug fixes, for every change if you set it), and Provefab’s plan must give a reproduction command that fails before the fix, in any language. If you want a weakened test to stop the work rather than be flagged, no_human is stricter. Its review also runs as a GitHub Action with no daemon, and it reads monday.com boards and GitLab issues, which Provefab does not. Its pull requests can open on GitLab too; Provefab opens them on GitHub only.
When Provefab fits better
Pick Provefab if you want the reviewer to come from a different vendor than the coder whenever you configure two providers, not only a different model: a Claude implementation is reviewed by an OpenAI model and the other way round. no_human can do the same if you choose another reviewer backend; in Provefab it is the default. Provefab is driven by labels, so the person who can triage an issue is the person who authorizes work on it. The same goes for reviews of pull requests people wrote: the provefab:review label, or a /provefab review comment from an owner, a member or a collaborator, and Provefab never approves or merges that pull request. Jira Cloud and Linear work in both tools: no_human polls them, Provefab starts from a label on the ticket, in beta.
Provefab routes each stage to the cheapest model that fits and reports what each pull request cost. And if you want some changes to merge on their own, Provefab Pro can do it for small pull requests that add or change a test, on private repositories, with fail-closed checks; risky changes never merge without a person unless you allow them, and everything else waits for a person. Both the free core and Pro can optionally run your repository’s commands again on the merged commit and propose a human-reviewed revert PR when the revert itself passes those commands. This is not production monitoring.
To see what Provefab refuses on the way to a pull request, watch the demo. To set it up, you can hand the job to a coding agent with Set up Provefab with a coding agent: the agent writes the configuration, and you keep the sign-ins, keys and service.
What they share
Both run the agents on your machine with your own plans or keys, both refuse to trust a pull request only because the coder says it is done, and both leave the final call to a person by default. If you already use one, the other is worth a look for the parts above, not for a different philosophy.
See how Provefab verifies a pull request in How to verify AI-generated pull requests, look at the pull requests Provefab opened on its own repository, or compare other alternatives, such as a self-hosted Devin alternative.