Skip to main content

​
Why use Rapid Review?

Rapid Review is fast without being shallow. In standard mode, most reviews of a pull request are complete in under a minute. Complete means every part of the change was reviewed, the findings are on the pull request as inline comments, and the summary comment and the rapid-review check are up to date. It gets there by combining three things, each doing the work it does best:
  • Deterministic code analysis reads the change and gathers the code around it by fixed rules, with no AI model involved.
  • Frontier AI models, Anthropic’s Claude, review the code.
  • Fast AI models, such as TypeSafe AI’s Jev, make quick, narrow judgements, such as how likely a finding is to be real, how severe it is, and whether a later push fixed it.

​
How long does a Rapid Review review take?

In standard mode, most reviews are complete in under a minute from when they start. In a test on 50 pull requests from five large open-source projects, a standard review took 25 seconds at the median, and 95 in 100 took under 40 seconds. The largest pull request in the test, with 53 parts to review, took 71 seconds. On GitHub, the time GitHub takes to deliver the push and to show the results comes on top. A review can start later than the push:
  • In repositories where the review of a later push waits for the pull request’s description, it starts once the title or description, edited after the push, has gone 10 seconds without another edit, and 90 seconds after the push at the latest. The first review of a pull request never waits.
  • In repositories that review later pushes only on request, a later push is reviewed once someone asks.

​
How does Rapid Review review so fast?

Rapid Review spends AI model time only where it’s needed:
  • The context is ready before the review starts. Deterministic code analysis splits the change into parts and gathers, for each part, the code the reviewer needs to see. In standard mode, the reviewing model doesn’t spend time searching the repository.
  • Several parts are reviewed at the same time, so a review’s time grows far more slowly than the size of the change.
  • Each job gets the model that fits it. Frontier models review the code. Fast models answer narrow questions, such as whether a finding is likely to be real, without the time a frontier model takes.
  • Unchanged parts aren’t reviewed again. On a later push, parts an earlier review already reviewed, unchanged and in the same mode, keep their earlier findings.

​
Which AI models does Rapid Review use?

Rapid Review combines two kinds of AI models. Frontier models review the code. In standard mode, Anthropic’s most capable Claude model reviews the larger parts of a change, and a faster Claude model reviews the parts that add only a few lines. In advanced mode, the most capable model reviews every part. If the model for a part isn’t available, another model can take over that part’s review. Fast models make quick, narrow judgements, the kind psychologists call System 1 thinking:
  • Jev, by TypeSafe AI, estimates how likely each finding is to be real and how severe it is, picks which of the repository’s learnings apply to a change, matches what the pull request says it does to the change, and checks whether a later push fixed a finding. For the larger parts of a change, it also flags calls elsewhere in the repository that the change may break, so the reviewer looks at them.
  • A small Claude model writes the summary, looks specifically for wrong conditions and wrongly built text, and drafts code suggestions, which Jev checks before they’re posted.
What the models are sent, and how their providers may use it, is on Your code and data.

​
What does deterministic code analysis do in a review?

Deterministic code analysis is the part of a review that follows fixed rules, with no AI model involved, so the same change gives the same result every time. In a review it:
  • splits the change into parts to review, and leaves out files that look like secrets, lockfiles, generated and vendored code, and files your .rapid-review.yml excludes;
  • parses the code to find the functions and types a change touches, and gathers related code from the rest of the repository and from the packages it depends on;
  • recognises parts that an earlier review already reviewed unchanged, and keeps their findings;
  • places each finding on the line it’s about, never posts the same finding twice or raises one that was resolved, and posts a limited number of comments, most severe first.