Specialists for the risky part of a change
Most pull requests need one careful reader. A change that touches auth, money, retries or a public API deserves a few, each looking for one kind of mistake. inline picks them from what the diff actually changed, runs them beside the main review, and posts only what survives a verifier.
Specialists, and a
verifier that argues back
Up to three specialists read a change along one axis each: security, correctness, concurrency, or API and contract breakage. A verifier then tries to refute every candidate, and only what survives reaches the pull request. The review page shows who was called, why, what each found and what the verifier threw out.
How it works
Picked from the diff,
not from a menu
Selection is a set of rules over the changed paths, the added and removed lines, and the risk areas triage found. Docs, lockfiles, assets and tests do not count. Raw SQL, shell calls and unsafe HTML are matched in each file's own language, TypeScript, C# or Python. Every specialist considered is recorded with the reason it was called or skipped.
One question
per specialist
Security looks for a way in. Correctness looks for logic that does the wrong thing. Concurrency covers races and data integrity. API and contract looks for a change that breaks a caller. Each reads the repository with the same read-only tools as the main reviewer, on a step budget sized for one narrow question.
Refuted findings
never post
The verifier reads the code again and rules on every candidate: confirmed, refuted or a duplicate. It can lower a severity or a confidence, never raise one. Confirmed findings then meet the same confidence floor, severity threshold and comment cap as the rest of the review. Refuted ones are stored with the reason and never count against the merge gate.
Small changes
stay cheap
Below 30 changed lines, only the security specialist runs, and only on a strong signal such as session code, webhook signatures, raw SQL or dynamic code. A specialist that errors never fails the review: the review posts without it and the record says so. Model inversion, a separate switch, reviews code an AI agent wrote with another provider's model where the workspace has one.
Included
Related
The review
Line-anchored findings with a severity, a confidence and a validation pass behind them, from a review that reads the code around the diff.
Read moreSandbox tests
Dependencies installed, the suite run, tests written for uncovered code, and the terminal trace kept, in a sandbox built for each pull request.
Read moreLearnings
Teach inline a rule from a pull request. It drafts rules from what your team dismisses and fixes, and retires the ones the evidence stops backing.
Read more
Put it on one repository
Connect GitHub or GitLab, enable a repo, and the next pull request opened gets a review.