Use cases / Maintainers with a queue
Reviewing in the time you actually have
Fourteen pull requests, ninety minutes. Say how long each one gets and read what fits.
The problem
“I will read it properly later” is where review goes to die. Without a budget every pull request is read the same way: skimmed from the top until attention runs out, which is rarely where the risk is.
What visualdiff does
- Set a time budget per review. The plan sorts every hunk into read, skim or skip so that what matters fits the minutes you have.
- Each item says why it is there: new code, high fan-in, a finding, a sensitive area. Each skip says why it is safe to skip.
- A reading order follows the dependencies, so the twenty minutes are spent in the order that builds understanding.
In the sample, twenty minutes buys a close read of 65 lines, a skim of 190 and a reasoned skip of 327.
Related
- Reviewing pull requests written by agentsAgents open pull requests faster than anyone can read them. Read the 10% that decides whether it is safe.
- Large refactors that hide a behaviour changeA refactor is supposed to change nothing. Find the one line that does.
- Stopping hallucinated dependenciesSlopsquatting: attackers register the package names models invent. Catch them at review.
- Seeing which running systems a change reachesThe diff says rds.tf. The map says orders-db, the API in front of it, and the queue behind it.