Turn a Git Diff into a Hand-Drawn Walkthrough Video
Published · Updated · Jakub Kuźnicki
Update policy: product facts, cited sources, and checked output evidence are revalidated when they change. See the author methodology.
A diff tells you what changed; a video can tell you why it's safe
A pull request diff is precise about the mechanics of a change and silent about everything else: why the old line was wrong, why the fix is safe, and what a reviewer should actually check. I took a one-line bug fix, the kind that clamps a value instead of letting it go negative, and pasted the raw diff into Scribe to see whether watching it drawn out communicates the fix faster than reading it cold.
The fixture: a one-line clamp
diff --git a/src/quota.ts b/src/quota.ts
--- a/src/quota.ts
+++ b/src/quota.ts
@@ -4,7 +4,7 @@ export function remaining(used: number, limit: number) {
- return limit - used;
+ return Math.max(0, limit - used);
}This is a real quota helper that used to return a negative number once usage exceeded a limit. The fix wraps the subtraction in a clamp to zero. It's a small, boring change, exactly the kind that gets skimmed and approved without anyone asking what would have broken without it. Watching it drawn line by line, hunk header first, then the removed line, then the replacement, gives a reviewer a beat to notice that the old code could return a negative remaining count at all.
What Scribe does, and doesn't, do with a diff
Scribe has no diff-aware syntax mode. Its language list covers JavaScript, TypeScript, Python, Java, a generic C-like family, SQL, HTML, CSS, Bash, Go and Rust, plus plain text; there's no entry for unified diff format, so a plus or minus line doesn't get colored differently from a context line the way it would in a code host's diff view. I left the fixture on Plain text and it still reads clearly: the hunk header, the removed line and the added line are three distinct, legible strokes in order. What you lose is the familiar green/red skim; what you keep is the order a reviewer would actually want to follow, which for a one-hunk fix is the whole point.
Where a diff video earns its minute
- A multi-file change where the interesting line is buried on file four, not file one.
- A subtle behavior change, like this clamp, where the diff is small but the reasoning behind it is not obvious from the lines alone.
- Onboarding a teammate onto a change they didn't write, where a linear watch beats jumping between expand/collapse in a diff viewer.
It doesn't earn its minute on a typo fix, a version bump, or a mechanical rename touching forty files identically. Recording a video for those adds a step nobody asked for. The honest rule is the same one that applies to any explainer: make one when the diff needs explaining, not because a tool makes it easy to do it anyway.
Try it on your own diff
Copy a diff out of your own pull request, paste it into Scribe and preview it before you decide whether it's worth exporting; preview is free and doesn't require an account. The developer notes page covers the rest of the paste-code workflow, and pricing lays out what a signed-in FREE export includes versus Premium.
For the broader question of when a video beats a written explanation at all, see code walkthrough vs. screen recording. For a shorter, narrated example of the same paste-and-export path, explain your code in 60 seconds walks through a different bug fix end to end.