Two tools, one discipline

The same review method, for developers and for business teams.

Both tools start from the version you last reviewed, flag the risky modifications with fixed, explainable rules, and keep a record of what was checked. An AI model can help explain a finding; it never decides what is flagged, and nothing leaves your machine unless you choose it.

Probe for code

Review AI-written pull requests

For developers, tech leads and CI pipelines.

Maps a Git diff to risk signals: authentication, payments, removed validation, public APIs, dependencies.
Runs your tests in disposable containers and tries to reproduce issues on both revisions.
Checks an agent's plan before the code exists, then lets conforming low-risk changes merge.
Reads the requirement from Jira, Linear, Notion or Google Docs and checks the code against it.

CLIHub (Docker)GitHub · GitLabClaude Code · MCPGo · TypeScript · Python · Rust

Explore Probe for code Download the CLI

Probe Desktop

Watch shared office documents

For finance, legal, sales and operations teams, and anyone who shares files.

Follows the Word, Excel and PowerPoint files of your OneDrive or Google Drive folders.
Flags a formula replaced by a number, a total that no longer counts every row, an amount or deadline changed, "shall" turned into "may".
Keeps a queue of documents to review; once reviewed, a version becomes the reference for the next changes.

WindowsmacOSOneDrive · Google DriveWord · Excel · PowerPoint

Explore Probe Desktop Download the app

Which one do you need?

	Probe for code	Probe Desktop
You are	A developer, a reviewer, a platform team	A controller, a lawyer, a manager, an assistant
What changes	Source code, in Git commits and pull requests	Word, Excel and PowerPoint files, in OneDrive or Google Drive
The reference	The base branch of the pull request	The last version someone marked as reviewed
What it looks for	Security-sensitive code, removed validation, API and dependency changes, failing or missing tests	Hard-coded formulas, shrunk ranges, changed amounts, dates and obligations, hidden sheets or slides, macros
Evidence	Checks run in a sandbox, reproduced issues, a JSON and Markdown report	The before and the after of each flagged change, and who saved it last
How it runs	A command-line tool in your terminal or CI, or the Hub for a whole account	An application in the taskbar or the menu bar, watching in the background

Probe Desktop · For documents

Shared files change quietly. Know which changes matter.

A budget passed between five people, a contract reworked by the other party, a board deck updated the night before. Nobody re-reads everything, and nobody should have to. Probe Desktop watches the folders your team already uses and shows you the modifications that change a number, a commitment or a calculation, with the before and the after.

Sees what track changes does not. A formula silently replaced by its value, a sum that stops one row short, a sheet made invisible.
Works where your files already are. Pick a OneDrive or Google Drive folder synchronized on your computer. No migration, no add-in, no account.
Stays on your computer. Documents are compared locally. An AI explanation is optional and receives only the flagged excerpts and the passages that still use a replaced name or term.

Discover Probe Desktop Download for Windows or macOS

Probe Desktop · 2 documents to review

X A range in the formula was reduced: some cells are no longer counted Budget 2026.xlsx · Budget!B1 · high
=SUM(A1:A3)

=SUM(A1:A2)
X A formula was replaced by its value: the cell no longer updates Budget 2026.xlsx · Budget!D2 · high
=A2*2

400
W An obligation was softened Supplier contract.docx · Paragraph 2 · high
The supplier shall deliver before 15/03/2026.

The supplier may deliver before 15/03/2026.
W An amount or a percentage was changed Supplier contract.docx · Paragraph 3 · high
The price is set at €12,000 excluding VAT.

The price is set at €15,000 excluding VAT.

Probe for code

AI assistants write large pull requests fast. Probe tells you which lines to read first: it maps the diff to risk signals, runs your checks in disposable containers, tries to reproduce issues with differential tests, and hands you a focused review plan with traceable evidence. A command-line tool for Windows, Linux and macOS, and a Docker hub for a whole GitHub or GitLab account. Try it in 2 minutes →

Probe for code · The process

Know the impact before the code exists. Review only what needs you.

AI-written code gets predictable when the agent announces its work first. Probe measures the risk of the plan before any code is written, then checks that the change did exactly what was announced. A change that follows a low-risk plan and passes its checks can merge without a human reading the diff; everything else goes to review, with the reasons.

Plan and check the intent

probe plan has the agent simulate the change read-only. Fixed rules, not the model, flag critical paths, public API and dependency changes, widely used or untested code. A flagged plan goes to a human before any code is written.
An agent codes the plan

The plan becomes a contract: the files, symbols and dependencies the agent may touch. It implements that, and only that.
Check conformance

probe review --plan re-assesses the plan, runs the checks in the sandbox and compares the diff with the contract: every unplanned file, unannounced API change, critical path or dependency is reported.
Merge, or review

Conforming change, low-risk plan, checks passed, nothing else flagged: no human review required, exit 0, the pipeline merges. Otherwise exit 2: a human reviews the pull request, starting from the listed reasons.

Exit 0 merge

The plan, re-assessed at review time, raised no risk category and was fully measured.
The diff stays within the plan: no unplanned file, API, critical path or dependency.
Every check passed; no high signal, reproduced issue or unverified area.

Exit 2 human review

The plan touches something critical, public or widely used, or could not be measured.
The change drifted from the plan.
A check failed or the report found something to look at. Every reason is listed.

# 1. before coding: plan, and let a human validate a flagged plan
probe plan --intent-file task.md --ci
# 2. the agent implements .probe/PLAN.json
# 3-4. in CI: conformance, checks and the gate (exit 0 = merge, 2 = review)
probe review --base origin/main --plan .probe/PLAN.json --ci
Plan conformance: conforming; 0 high, 0 medium, 0 low differences from the plan.
Plan gate: no human review required (low-risk plan, conforming change, checks passed, nothing else requests review).

The gate is a process decision, not a proof of correctness: your trusted policy decides what is critical and which tests run, and any doubt sends the change to a human. How the gate decides.

Probe for code · Why it saves time

Stop reading AI-generated diffs top to bottom.

The expensive part of reviewing an AI-assisted pull request is not the risky lines. It is finding them among the helpers, tests and docs around them, then working out whether a suspicion is real. Probe does that sorting and gathers the evidence before you open the diff.

Without Probe every line, same attention

Check out the branch and run tests, vet and build by hand.
Read 110 changed lines in file order, helpers first.
Notice, with luck, that the refund cap vanished from the payment code.
Write a throwaway test to find out whether it matters.
Approve without a record of what was actually checked.

With Probe risk first, evidence attached

Checks already ran in an isolated container, with logs and hashes.
Open the report: 18 flagged lines, ranked by severity, with reasons.
Start with the top risk of the AI report: the refund bound removed from payment/refund.go, reproduced by a test the reviewer wrote.
Let the optional reviewer try to reproduce the issue on base and candidate.
Keep the Markdown and JSON reports as the review record.

Less to read first

A deduplicated review surface counted in real changed lines, so large generated changes shrink to the parts that touch authentication, payments, validation, dependencies or public APIs.

No local setup per PR

Your test, typecheck, build and coverage commands run in disposable, network-less containers. Nothing of the candidate executes on your machine.

Know when to stop

Unverified areas and incomplete checks are listed explicitly, and --ci turns them into an exit code. You know what was covered and what still needs your judgment.

Probe for code · Example report

What you open instead of the raw diff

A real run on the example shop repository. The commit lets support agents issue refunds, adds a restocking fee and catalog helpers, and quietly drops the check that a refund never exceeds what was paid. Every test still passes. Rebuild it with make-repo.sh and run the same commands.

Excerpt of .probe/PR_SUMMARY.md, written by probe review HEAD~1..HEAD --ci with the reviewer model of Probe Hub. The run exits with code 1: a reproduced issue. In the hub, the same report heads the alert list, and every citation unfolds its diff.

.probe/PR_SUMMARY.md

# Let support issue refunds, add a restocking fee and catalog helpers

## Risks1
- high The bound on refunds was deleted rather than adapted,
  so an order can be refunded more than it was paid, from
  both payment.Refund and the public api.RefundOrder.
  — payment/refund.go:23-24 (old) ✓, payment/refund.go:28-29 ✓,
  Refund no longer checks the amount against what the order
  was paid — payment/refund.go:24 (reproduced finding), …
- high The new lines of api.RefundOrder were not executed
  by any instrumented package, so the removed refund bound
  is not covered through the public entry point.
  — api/refund.go:17 ✓, …
  … 1 more high risk, 1 low

## Changes2
- Add restocking fee and return value to refunds: payment.Refund
  now takes a restock flag, subtracts RestockingFee from the
  amount when restocking, and returns the refunded amount; …
  — payment/refund.go:20 ✓, …
  - REPRODUCED / high Refund no longer checks the amount
    against what the order was paid — payment/refund.go:24
  - Payment-sensitive function body changed — payment/refund.go:20
    … 6 more signals
  … 3 more areas; each of the 19 signals sits under one area

## Where to look first3
- high Check that dropping the paid-amount guard is intended
  and that the refund total still cannot exceed what was
  captured, since the sentinel and its test assertion are
  gone. — payment/refund.go:23-24 (old) ✓, payment/refund.go:15 ✓

## Testing4
Probe executed 10 checks for this review: 6 PASS, 3 FAIL, 1 ERROR.

The bug comes first, reproduced. The removed refund bound leads the risks, although every test passes. The reviewer wrote a test that passes on the base and fails on the candidate: Probe ran both and recorded the issue as reproduced.
Every citation is checked. ✓ means the code the model quoted is at those lines of the diff: Probe searched for it, without a model, and drops a citation it cannot find. It proves where the statement points, not that the statement is right.
Findings grouped by intent. The reproduced issue and the signals Probe computed are listed under the change they belong to, with their recorded status, severity and location. A finding no area cites is still listed, at the end.
What ran is Probe's, not the model's. The checks line counts what actually executed in the sandbox, the reviewer's tests included, and the verdict comes from evidence. The model rates and describes; it changes nothing in the result.

Excerpt of .probe/CONFIDENCE_REPORT.md, produced by probe review HEAD~1..HEAD --reviewer=false --ci on the same commit. No AI provider was used.

.probe/CONFIDENCE_REPORT.md

## Change Summary
93 additions / 17 deletions · 7 files changed
Exit code: 2. No confidence percentage is assigned.

## Automated Checks1
- PASS test      (check-1; exit 0; 7136 ms)
- PASS typecheck (check-2; exit 0; 5006 ms)
- PASS build     (check-3; exit 0; 4177 ms)
- PASS coverage  (check-4; exit 0; 7480 ms)

## Reproduced Issues2
No issue was reproduced by a passing baseline
and failing candidate experiment.

## Suggested Human Review3
- high api/refund.go:17–17 (new): Added lines were not
  executed by any instrumented package in the coverage
  run; Exported Go declaration changed;
  Payment-sensitive function body changed
- high auth/auth.go (whole file): Lines added and
  removed in a sensitive file
- high payment/refund.go:24–26 (new): Payment-sensitive
  function body changed
  … 16 more signals

## Review Surface4
Focused review: 18 / 110 changed lines.

## Changed-line Execution5
Measured from check check-4: of 61 added Go lines,
33 were executed at least once, 3 were not executed,
25 are not inside any instrumented block.

Checks are done, and they are not the answer. Every configured command passed in an isolated container, and the commit still lets a refund exceed what was paid.
Evidence, not opinions. A reproduced issue needs a test that passes on the base and fails on the candidate. Without an AI provider nothing is claimed here, and the report says so.
Your reading order. High signals first: the refund API, the authorization rule and the payment code changed in sensitive files. They show where to look; finding the removed check is then your job, or the AI reviewer's.
The size of the job. 18 of 110 changed lines carry a signal. Read those first, then decide how much of the rest deserves attention.
An observation, not a proof. The new refund API never ran during the tests: none of its added lines was executed. Probe reports execution but never presents it as proof that the code is tested.

Probe for code

How it works

Compare immutable commits

Both refs resolve to commit IDs. Renames, deletions, binaries and merge-base semantics are handled; only committed files are reviewed, so local edits never leak into the result.
Collect risk signals

Go AST comparison, labelled lexical heuristics and sensitive-path rules flag authentication, payments, dependencies, removed validation, unsafe constructs and missing tests in Go, TypeScript/JavaScript, Python and Rust.
Execute in a sandbox

Your test, typecheck and build commands run as argv arrays in disposable, non-root, network-less containers with CPU, memory, PID and time limits.
Reproduce, don't assert

An optional reviewer writes temporary tests. A test that passes on the baseline and fails on the candidate supports a reproduced issue; anything else stays UNVERIFIED.

From a first try to every pull request

Try it on your last commit with no configuration, no Docker and no API key. When you adopt it, commit a policy to your base branch: it is read from the base, so a pull request cannot loosen its own rules.

Follow the getting started guide →

# try it: compare with the previous commit
probe lint HEAD~1..HEAD

# adopt it: once, in your repository
probe init
git add .probe.json && git commit -m "Add review policy"

# on every pull request
probe review --base main --ci

Probe for code · Docker

Or run it for a whole account: Probe Hub

The hub is the companion Docker image. Run one container, sign in with GitHub or GitLab, and every repository still missing a .probe.json gets a policy proposed in one click, previewed before it is committed to the default branch.

Repositories that have a policy can be watched: each new commit is analyzed and its report opens on its own. With a reviewer model configured, the report is written by the AI and checked by Probe: risks and places to look first rated by severity, every citation verified against the diff, and the alerts grouped under the change they belong to. A severity slider filters the whole report from low to critical, and clicking an alert or a citation unfolds the modifications it concerns, with the lines highlighted in the diff.

The team shapes the reviewer: each repository keeps its coding rules, and votes, comments and replies on findings teach it what the team finds useful. Coding agents such as Claude Code or Cursor connect to the hub's MCP server to trigger reviews, read findings and give feedback.

The hub can also lend its LLM to the command-line tool: probe login connects a workstation to your account in the browser, and probe review then investigates with the hub's model, within a daily quota, without a provider key of your own.

One Docker container, no external service required, with its state on a volume or in PostgreSQL — so a company can deploy it internally against its own GitHub Enterprise or GitLab instance. In its default mode it never executes the analyzed code.

Open the web app Deploy your own

Hosted at app.probe.technology — the same image you can run on your own network.

# one container, on your own network
$ docker run -p 8080:8080 \
    -e PROBE_HUB_BASE_URL=https://hub.example.com \
    -e PROBE_HUB_GITHUB_CLIENT_ID=... \
    -e PROBE_HUB_GITHUB_CLIENT_SECRET=... \
    -v hub-data:/var/lib/probe-hub \
    gvinsot/probe-hub

Sign in · bootstrap the missing policies · watch pushes
Reports open by themselves, filtered by severity.

Probe for code

Capabilities

Focused review surface

Deduplicated review ranges with old and new coordinates, counted in actual changed lines, ranked by severity.

Differential evidence

Generated tests run on baseline and candidate in fresh environments. Go execution is verified from structured test events.

Changed-line execution

Optionally measure which added Go lines a recorded run executed — reported as an observation, never as proof of testing.

Impact analysis

A static index of Go, TypeScript/JavaScript, Python and Rust lists the unchanged callers of each changed function and the existing tests that reach it.

Tests on both revisions

Impacted and changed baseline tests, differential fuzzing and mutation of added lines run on base and candidate, recorded as evidence, never as a verdict.

Plan, then check the scope

probe plan assesses an agent's plan before any code exists; --plan then flags every file or exported API the change touched without announcing it.

Bounded AI reviewer

Bring any OpenAI-compatible provider, or borrow your Probe Hub's with probe login. Tools are bounded: redacted file reads, search and test runs. No shell, no URL fetcher. It also drafts the pull request description, never the verdict.

Reviewer swarm

Specialized agents for correctness, security, tests, compatibility, reliability and intent investigate in parallel. Their findings are merged and checked against evidence: agreement is not proof.

Beyond the diff

A repository graph, the related repositories of a cluster and an editable knowledge base let the reviewer see who depends on a change and which contract it may break.

Requirements as intent

Point Probe at a Jira or Linear issue, Notion pages or Google Docs: their acceptance criteria become what the change is reviewed against, along with your team's coding rules.

CI ready

A reusable GitHub Actions workflow, meaningful exit codes, JSON reports with commit IDs, evidence and artifact hashes, plus SARIF and a PR comment holding only evidence-backed findings.

Agent friendly

Coding agents run lint and review before handing work over. A Claude Code plugin and the hub's MCP server let them request reviews, read findings and fix them.

What Probe does not claim

A review tool earns trust by being precise about its limits. Probe assigns no confidence percentages and never approves a change on a model's word. For code, it lifts human review only through the plan gate, when a low-risk plan was followed and every automated check came back clean. For documents, a person always decides.

Signals are reasons to investigate, not confirmed bugs.
Passing tests and a small review surface are not correctness guarantees.
An executed line is an observation, not proof that it is tested.
A model's assertion is never evidence; only a reproduced difference is.
The plan gate says the announced, low-risk scope was respected, not that the code is correct.
Execution never falls back to your host when Docker is missing.
A document marked as reviewed is a human decision, not a guarantee that its figures are right.
A document with no finding still changed: the full list of changes stays one click away.

Put your review time where it matters.

Open source, AGPL-3.0 licensed. A command-line tool for code, an application for documents, both published with every release.

Get the CLI Get Probe Desktop

Review what matters.

The same review method, for developers and for business teams.

Review AI-written pull requests

Watch shared office documents

Which one do you need?

Shared files change quietly. Know which changes matter.

Know the impact before the code exists. Review only what needs you.

Plan and check the intent

An agent codes the plan

Check conformance

Merge, or review

Exit 0 merge

Exit 2 human review

Stop reading AI-generated diffs top to bottom.

Without Probe every line, same attention

With Probe risk first, evidence attached

Less to read first

No local setup per PR

Know when to stop

What you open instead of the raw diff

How it works

Compare immutable commits

Collect risk signals

Execute in a sandbox

Reproduce, don't assert

From a first try to every pull request

Or run it for a whole account: Probe Hub

Capabilities

Focused review surface

Differential evidence

Changed-line execution

Impact analysis

Tests on both revisions

Plan, then check the scope

Bounded AI reviewer

Reviewer swarm

Beyond the diff

Requirements as intent

CI ready

Agent friendly

What Probe does not claim

Put your review time where it matters.