An approval on a pull request records that somebody pressed a button. It does not record whether they read the change, and nothing in your review data can tell the two apart. That mattered less when the author was a colleague who could be asked about the code. It matters more now: by September 2026, more than 40% of pull requests on GitHub started with an agent’s first draft, according to GitHub’s Octoverse report. A comprehension check is how Deslopping closes the gap: before a risky pull request merges, its reviewer answers two or three questions about the lines that changed.
What a comprehension check is
A comprehension check is a required status check that passes once the reviewer has answered questions about the change. In Deslopping it is called deslopping/comprehension, and it sits beside your tests and linters in the list of checks GitHub waits for before it allows a merge.
What it is not is easier to say. It is not a test of the code: your CI runs those. It is not a review of the code: a person still does that, and still decides whether the change is right. It is evidence of the one thing a review is supposed to include and cannot prove on its own, which is that the person approving the change could explain it.
How it runs, step by step
The How it works page follows one pull request from the agent’s commit to the merge: retries with backoff for a webhook dispatcher, eleven lines added and one removed. Here is the same pull request, with the reasoning behind each step.
1. Every pull request gets a risk score
As soon as it opens, the pull request is scored from what it changes: which paths it touches, how far the change reaches, what kind of change it is, the files’ history and its size. You set the threshold, and which paths count as sensitive. A pull request under the threshold is never touched.
Which AI tool wrote the code is recorded, and never changes the score. Attribution is easy to strip from a commit, and a gate that depended on it would open for anyone who stripped it.
2. A risky one gets two or three questions
Over the threshold, the check waits. The reviewer gets two or three questions generated from the diff, each pointing at specific lines, and answerable in a couple of minutes by someone who read the change. The check on the pull request links straight to them, so there is no new tool to learn.
A question of the kind it asks points at these six lines of the dispatcher:
if (attempt >= MAX_ATTEMPTS) {
await store.park(evt.id, "exhausted");
metrics.inc("webhook.parked");
return;
}
const delay = BASE_MS * 2 ** attempt + jitter(attempt);and asks, in your own words, what happens to a webhook that has already failed four times. Someone who read the change can say that it is parked rather than retried, that the function returns before anything is posted, and that nothing else is told beyond one metric. Someone who approved it on trust cannot. That difference is what the check is for.
3. The reviewer answers, then rates the AI
The reviewer answers in their own words. An answer that misses brings another question on the same lines, and a hunk nobody can explain is recorded as a finding about the AI, not about the person who could not explain it.
Then they rate how the AI’s code reads: good, mixed or poor, with a note in their own words if they want one. It is the only rating in the product, and its subject is always the code.
4. The check turns green
Once its questions are answered, deslopping/comprehension passes and the merge goes ahead. When production is down and a fix cannot wait, break-glass is one short reason away for the people allowed to use it. Every use is logged, and the review is still owed within 24 hours. Whether the check fails open or closed during an outage is your setting, not ours.
Why it sits on the pull request
There are three reasons, in order of how much they matter.
- The merge is the last cheap moment to ask. Before it, the change is on screen and a question costs minutes. After it, the first person to read the code closely may be whoever is on call when it breaks.
- It uses the gate you already have. GitHub can require status checks to pass before a merge, and most teams already block merges on their tests that way. A comprehension check is one more required check, not a new process.
- The questions can be specific. On the pull request the diff is right there, so a question can point at line 43 and ask what it does. A quiz about the codebase in general would test memory. A question about these lines tests whether they were read.
What it deliberately does not do
- It does not read the code for you. AI review bots read the change and add another opinion to the thread. A comprehension check adds no findings of its own: it checks that a person read the change, and records what the AI keeps getting wrong.
- It does not gate every pull request. Only those over your threshold, so how often a merge waits is a number you set rather than one sprung on you.
- It does not ask about code outside the diff. Questions are only ever about lines that changed in this pull request.
- It does not score the reviewer. No per-person score, ranking, streak or league table exists anywhere in the product. Answers are encrypted, readable by the person who wrote them, and deleted after the organisation’s retention period.
What it costs
On a gated pull request, a few minutes of someone actually reading the change. That is a real cost, and it is spent where the risk score says the change is risky rather than spread over every typo fix. If your team cannot afford a few minutes on its riskiest changes, that is a real answer, and this product is not for you yet.
What comes back is a record that each risky merge was read by someone who could explain it and, across the team, a map of where the AI writes code people cannot follow: by module, and by tool, with Claude Code, Cursor, Copilot and the rest on the same scale.
Where to start
Take last month’s merged pull requests and pick out the ones that touched payments, authentication or anything that moves data. For each, ask whether the person who approved it could explain it today without opening the diff. If the honest answer is “probably”, you have the problem a comprehension check solves, whether or not you solve it with us. How it works shows the whole path, with the screens a reviewer sees.
See a comprehension check on your own pull requests
Thirty minutes with the founder, on a real diff: the score, the questions and the check. We will tell you honestly whether it fits your team.