no_human

no_human

From ticket to reviewed pull request. *Free and open-source, on your machine.*

English · 简体中文 · 日本語 · 한국어 · Español · Français · Deutsch · Português (Brasil)

getnohuman.com · Quickstart · Docs · Watch it work a sprint · Discord

▶ Watch the loop — a ticket in, a reviewed pull request out; the whole loop in 57 seconds.

The AI coding factory you can trust :

• A plan before any code, from the ticket plus what it finds in your repo. When planning fails, the coder is told it is working without one; when the change is judged trivial the plan is skipped without telling the coder, by design — the skip is still stated in the run's event stream.
• An adversarial review. A different model, in a session that never saw the coder's transcript, told to refute "done". You get a pass/fail checklist citing file and line — never a numeric self-score.
• A tamper guard. Deleted tests, new skips, an assertion turned into a tautology — counted mechanically before the review gate runs, then justified against your acceptance criteria or the attempt stops.
• Proof the fix fixed the bug. The tests offered as evidence must fail at the merge base and pass on the new tree — the reproduction gate runs both. Out of the box that binds a Python bug fix; repro_gate.mode: required binds every kind and every change.
• Your tests run, locally and optionally through your CI — and a PR that found no test command says NOT RUN on its face.
• An honest stop. When it cannot finish it stops and says why — a specific question when your answer would unblock it, a structured record when it has simply run out of budget — never an invented plausible diff.

What the gate caught

no_human builds no_human. Over 65 days on its own board, none of this reached a pull request:

• 505 of 1,709 attempts the coder called done were sent back by the second model, each with a pass/fail checklist citing file and line.
• 44 attempts were stopped before the review even ran, for deleting or weakening a test.
• 46 bug-fix proofs were refused because the test offered as evidence passed on the old code too.

How these were counted

Install

One line (CLI + board)

uv tool install no-human   # or: pipx install no-human — the wheel ships the board

nh init && nh doctor # token, config, first repo; then prove the install is real

Desktop app

Each release ships a SHA-256 alongside the artifact. Platform notes and the first-run walk-through: docs/quickstart.md.

From source

git clone https://github.com/no-human-ai/no_human.git && cd no_human

uv sync # installs the nh entry point into .venv (cd web && npm install && npm run build) # builds the board (cold first install can take minutes) uv run nh init # token, config, first repo (about 2 minutes) uv run nh doctor # verify the install is real before relying on it

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. Needs Python 3.12+, uv, git, and Node with npm for the board build.

Product highlights

A plan before any code Acceptance criteria you can check, written from the ticket and your repo.

An independent reviewer A second model that never saw the coder's session, told to refute "done". Pass or fail; every finding that blocks cites file and line.

Your tests, on the PR's face Run locally or through your CI. No test command found reads NOT RUN , never blank.

A tamper guard Deleted tests, new skips and tautological assertions are counted before review. Unjustified, the attempt stops.

Proof the fix fixed the bug The tests offered as evidence must fail on the old code and pass on the new. The gate runs both, and the event log shows the verdict.

An honest stop When it needs you, it parks with one specific question instead of guessing.

Your tracker's tickets, on your board Pick Jira or Linear tickets from the backlog (monday.com boards are polled). Each one is scoped with you before it starts.

Stills: the real board on a demo workload.

Run one task

Run nh with no arguments for the shell: your lanes, a live event tail, and an intake you describe a task to in plain English. Every command below still works.

nh                                   # the shell

nh start # board + worker on 127.0.0.1:8420 nh task add https://github.com/org/repo/issues/42 --repo ~/git/repo nh status # needs-you / working / waiting / done nh review # the reviewer's evidence checklist nh diff # the diff it wants to ship nh approve # your approval squash-lands the PR (git.approve_identity) nh reject --reason "..." # send it back with feedback

Integrations

Point no_human at the tracker you already use and it pulls the tickets to your board — a tracker's filter lives in your config, never in a task's own text, and a transport error logs and retries on the next tick instead of crashing the pool.

With write-back on (write_back, off by default), the ticket moves with the task — matched by status category, type, or the label you name, never a hard-coded transition id — and gets the PR link; a task that needs a human is commented on, never transitioned. GitHub and GitLab issues import as tasks by URL, and PRs or MRs open on your own host; Slack and Teams get a message when a task needs you; Jenkins and CircleCI can run your test layers and gate the loop. Setup for each: docs/adapters.md.

Watch the Jira flow end to end — tickets synced from a Jira board, scoped, implemented, and delivered as a review-passed pull request (click for the full video with every step):

▶️ Play the full demo — 1:33, from Jira board to review-passed PR

GitHub Action

Run the same adversarial reviewer and tamper guard as a pull-request check — one shot, no daemon, no ~/.no_human database, and not the queueing nh review CLI path. It judges the diff alone: unlike a local run, it collects no lint, wiring or type evidence and does not explore the repository. It posts a single pass/fail checklist comment with file:line citations, found by its own marker and updated in place on every run rather than creating a new one e