no_human: ticket-to-pull-request automation with an adversarial review gate

The gap no_human is aimed at: agents that report success without evidence

Coding agents are good at producing a diff and bad at telling you whether the diff is correct. The README frames the whole project around that failure mode: the promise is a plan before any code, an adversarial review, a tamper guard, and an honest stop. The target user is an engineer who already runs an agent against a real repository and has been burned by a confident summary that did not survive contact with the test suite. The project is local-first. It installs as a Python package, ships a board, and talks to your repository and your CI rather than to a hosted control plane. The tagline is "From ticket to reviewed pull request" and the second line is "Free and open-source, on your machine." The topics list confirms the shape of the thing: agent-orchestration, agent-fleet, multi-agents, git-worktrees, mcp, sdlc. This is infrastructure for running several agents at once against one codebase, not a chat interface.

How the loop works: plan, coder, tamper count, reproduction gate, reviewer

The pipeline described in the README has four gates and one reviewer. First, a plan is written from the ticket plus what the agent finds in your repository, expressed as acceptance criteria plus the files to change, the approach, the test plan, out-of-scope items, and a verification command. Two edge cases are documented rather than hidden. When planning fails, the coder is told it is working without a plan. When the change is judged trivial, the plan is skipped without telling the coder, and the README says that skip is still stated in the run's event stream. That asymmetry is deliberate: the coder is not told, the operator can still see it. Second, the tamper guard runs mechanically before the review gate. Deleted tests, new skips, and an assertion turned into a tautology are counted, then have to be justified against your acceptance criteria or the attempt stops with a TAMPER DETECTED banner. Third, the reproduction gate takes the tests offered as evidence and requires them to fail at the merge base and pass on the new tree. Fourth, a different model reviews in a session that never saw the coder's transcript, instructed to refute "done", returning a pass or fail checklist that cites file and line. The README is explicit that the verdict is never a numeric self-score. The reviewer's outputs are binary, and every blocking finding points at a location in the diff. The board screenshot in the README shows this state: one task waiting on a question in Needs answer, four tasks working in parallel, one pull request ready for review.

Getting it running: nh init, nh doctor, and the web build that is not optional

The one-line install is `uv tool install no-human`, with `pipx install no-human` as the alternative, and the README notes the wheel ships the board. Then `nh init && nh doctor`, described as token, config, first repo, followed by proving the install is real. From source the sequence is `git clone https://github.com/no-human-ai/no_human.git && cd no_human`, then `uv sync` to install the `nh` entry point into `.venv`, then `(cd web && npm install && npm run build)` to build the board, then `uv run nh init` and `uv run nh doctor`. The README warns that a cold first install of the web build can take minutes and that the web build is not optional if you want the board: a source checkout ships no `web/dist`, so without it `nh start` serves the API only and renders no UI. Requirements are Python 3.12+, uv, git, and Node with npm for the board build. One config key is named in the README: `repro_gate.mode: required`, which extends the reproduction gate from a Python bug fix to every kind and every change. Desktop builds exist for macOS, Windows and Linux, and each release ships a SHA-256 alongside the artifact. The README states that `nh init` takes about two minutes.

Where the design gets opinionated, and where it will not fit

The reproduction gate is the most opinionated part and the easiest to trip over. Out of the box it binds a Python bug fix, which means the "proof the fix fixed the bug" property is narrow by default. Teams working in other languages get the tamper guard and the reviewer but not the fail-at-base, pass-at-head check unless they set `repro_gate.mode: required`. That setting is a real trade-off, because requiring the gate for every kind and every change raises the cost of changes that have no meaningful failing test to write. The second constraint is the reviewer itself: it is a different model in a session that never saw the coder's transcript, so the workflow assumes you have a second model available and are willing to pay for it. The README does not document rollback, and it does not describe what happens when the reviewer model is unavailable or when the two models disagree in a way the checklist cannot express. The honest-stop behaviour is a design choice with a cost: when the agent runs out of budget it emits a structured record instead of a diff, which is better than an invented patch but still leaves the ticket unfinished. Anyone expecting unattended throughput will hit that wall. The README does not document how the budget is configured.

How it compares with a plain agent plus CI

The obvious alternative is running a coding agent yourself and letting your existing CI be the gate. The difference is where the verification lives. A plain agent loop produces a diff and hands it to CI, and CI tells you whether tests pass, not whether the tests are still meaningful. no_human inserts two checks before that point: the tamper guard counts deleted tests, new skips and tautological assertions mechanically, and the reproduction gate requires the evidence tests to fail at the merge base. CI cannot make that second claim, because CI only sees the new tree. The reviewer is the other divergence. A second model in a fresh session, told to refute "done" and required to cite file and line, is a different artifact from a human reading a diff after the fact, and it is also different from asking the same agent to review its own work, which the README implicitly rules out by specifying a session that never saw the coder's transcript. The cost of that structure is latency and orchestration complexity: git worktrees, a board, an event stream, and at least two models in the loop. A single agent plus CI is cheaper to run and easier to reason about. no_human is buying you a paper trail.

Maintenance, licence and the upgrade surface

The repository is not archived, and the last push was on 2026-09-13. Three releases landed in the same week: v0.2.0 on 2026-09-05, v0.2.1 on 2026-09-07, and v0.2.2 on 2026-09-08. That cadence on a 0.2.x line means the config surface and the event stream are still moving, so pinning a version is the sane default. The licence is MIT, which permits commercial use and modification provided the copyright notice and permission notice are retained; this is a summary of the licence identifier in the repository, not legal advice, and anyone embedding the tool in a product should read the LICENSE file. Upgrade cost is concentrated in two places: the `nh` package itself, and the board, which is a separate Node build. A source checkout that skips `(cd web && npm install && npm run build)` gets an API with no UI, and that is a failure mode that looks like a broken install rather than a missing build step. The README does not document a migration path between 0.2.x releases, so treat config keys such as `repro_gate.mode` as things to re-check after each upgrade.

Editorial conclusion

Adopt no_human if you want an agent loop that refuses to fabricate a plausible diff and you are willing to run the verification chain, which means Python 3.12+, uv, git, Node with npm for the board build, and a second model for the reviewer. Do not adopt it if you need a hosted service or cannot supply a test command, because the README states a PR that found no test command reads NOT RUN on its face. Verify first with nh doctor after nh init, and check whether your bug fix is Python, since the reproduction gate binds a Python bug fix out of the box and only repro_gate.mode: required extends it to every kind and every change.

Official sources

1. License: MIT
2. no-human-ai/no_human on GitHub
3. Project website
4. README
5. Releases