Review code your agent just wrote

The weakest review available is the one where an agent re-reads its own work in the same conversation. The reasoning that made the code look right is still in scope, and it tends to confirm itself.

This is the case Predictive Debugger was built for: getting a second opinion from outside that context.

The rule the server actually enforces

The MCP server ships instructions that ask your agent to check new code from a fresh context. What it asks for depends on how far the change reaches - and the test is file count, not how large the change felt or whether it was a fix or a feature.

Change	Requested check
One file, including a whole feature in one file	A fresh predict_failures call
Several files	A sub-agent scoped to the changed files
Mechanical correction with one clear answer	Neither

The reason for the split: predict_failures reads each file on its own. It never sees how several files have to agree, so it cannot catch a contract that two files disagree about.

One file

Ask directly:

Check src/services/orders.ts for likely runtime failures.

This calls a model, and the verdict comes back with a line number and a reason rather than a vague warning. A real finding from the demo project:

{
  "pattern": "race_condition",
  "file": "reserveStock.ts",
  "line": 26,
  "score": 0.82,
  "reason": "onHand is read at line 18 before two awaits; concurrent reserveStock calls for the same sku both read the same onHand and setStock(sku, onHand-qty) overwrites each other, letting stock oversell despite the negative-stock guard."
}

Read the reason, not the score. The number is a confidence from that one recorded prediction, not a measured accuracy rate. The reason is what you can check against the code - and here it names the exact mechanism, which makes it falsifiable.

Several files

Do not loop predict_failures over each file and call it a review. Scope a sub-agent to the change instead:

Review the changes I just made to src/services/orders.ts, src/services/stock.ts
and src/db/inventory.ts. I was adding partial-reservation support. Review only
that change.

Giving it the files and the intent matters. An unscoped agent rebuilds the project from cold and reports on code nobody touched, which is what makes this expensive and noisy.

Reviewing a batch efficiently

If you do want per-file verdicts on several files, pass them in one call rather than one at a time:

Check src/services/orders.ts, src/services/stock.ts and src/db/inventory.ts
for likely runtime failures.

The verdicts are independent and run concurrently, so a batch costs the same as the same files one at a time but returns in roughly the time of the slowest one. Calling once per file pays that wait again for every file.

A clean verdict is not a clearance

predict_failures returning nothing means the file is locally sound. It does not mean the feature is correct, that the files agree with each other, or that the behavior matches what you intended. Those still need tests and your own reading.