Architecture
How a pull request actually gets reviewed
Six checks, one shared context, one score. The interesting part is not the model — it is what the model is allowed to see before it is permitted to flag anything.
The pipeline
From webhook to merge gate
A typical review completes in about thirty seconds. Nothing here is asynchronous from your point of view — by the time you switch tabs, the check has reported.
Webhook arrives
GitHub or GitLab notifies us that a pull request opened or moved. Deliveries are deduplicated by commit SHA, so a redelivery or a retry never produces a second review of the same commit.
Queued, one review per PR at a time
Reviews run through a persisted queue that survives restarts. Jobs for the same pull request are serialised so two reviews can never post over each other; different pull requests run in parallel.
Context is assembled
The diff, the complete current contents of each changed file, and the local files those changes import. This is the step that decides whether the review is accurate.
Six checks run on the same diff
Secret scanning, static rules, SAST, AI bug detection, the walkthrough and auto-fix generation. They run together against one shared context rather than as separate passes.
Findings are scored and anchored
Findings become a single 0–100 risk score. Each one is anchored to a line inside the diff — anything outside it goes in the summary rather than being dropped or failing the post.
Posted back, and gated
Inline comments, a summary with the walkthrough, and a GitHub check. Clean pull requests auto-approve; critical findings hold the merge button until they are resolved.
Context
What the reviewer is given before it may flag anything
Most false positives in AI code review come from the same place: the model is shown a diff and asked to reason about code it cannot see. It then reports things like “X is not imported” about a symbol imported four lines above the hunk. The fix is not a better prompt — it is more context.
The diff
What changed, with the surrounding hunk. On its own this is what makes most AI reviewers noisy — a diff cannot tell you whether the symbol on the line above is defined.
The whole changed file
The complete current contents, so imports, type definitions and declarations outside the diff can be verified before anything is flagged. Capped at 32,000 characters and 20 files per review; larger files keep their head, tail and the regions around each change.
The files it imports
Local modules the changed code depends on, so a call can be checked against the function's real signature — wrong argument count and wrong argument type, not guesses.
This is the change that removed an entire class of false positive reported by an early tester. It is also the expensive part: full file contents cost more per review than a diff does, which is the trade we make for findings you can trust.
Six layers, one pass
What runs on every diff
Three are deterministic and will return the same answer every time. Three use a model (currently GPT-5.2). Knowing which is which matters when you are deciding how much to trust a given finding.
Secret detection
deterministic13 patterns across every file type. Runs on the diff only — deliberately. Full file contents are never scanned for secrets, so we cannot report a credential your pull request did not touch.
Static rules
deterministic30 language rules for TypeScript, JavaScript and Python, plus any custom rules in your .microreview.yml.
SAST checks
deterministicInjection, unsafe evaluation, path traversal and similar structural risks.
AI bug detection
modelLogic errors, null dereferences and unhandled rejections introduced by the added lines, verified against the full file before being reported.
PR walkthrough
modelA plain-English summary of what changed and which paths deserve a careful human read.
Auto-fix suggestions
modelExact replacements posted as native GitHub suggestions, so a fix is one click rather than a paragraph of advice.
Scoring
How one number is produced
The score is arithmetic, not a model judgement. It is deliberately boring so that it is predictable — the same findings always produce the same number.
Summed and capped at 100. A clean pull request scores 0 no matter how large it is — the score measures problems found, not the size of the change. Both thresholds (auto-approve, block) are configurable per repo in .microreview.yml.
Deliberate limits
What MicroReview does not do
Worth stating plainly, because several are things competing tools do and some teams specifically do not want.
We do not index your repository
No clone, no embedding, no vector store of your codebase. The reviewer reads the pull request and the files it touches, at the moment it runs.
We do not retain your code
Content is held for the duration of the review and then dropped. It is never used to train models. The public sandbox stores nothing at all.
We do not review the whole repository
Only the diff is reviewed. Full file contents are context for verifying a finding, never a target — so a pull request never turns into a report about code you did not write.
We do not re-review what has not changed
Pushing a fix re-analyses only what moved since the last review, so a force-push does not reopen noise you already resolved.
Read it, or run it
The fastest way to judge a code reviewer is to give it code. The sandbox runs this same pipeline — no signup, nothing stored.
More detail: how your code is handled, configuration reference, or the write-up on why diff-only review produces false positives.