How to Record a Code Review: Screen Recording as an Async Communication Tool

Code review is communication, and communication gets better when you can hear someone’s reasoning — not just their conclusion. A comment that says “this approach may have performance implications in large lists” leaves the author guessing. A 90-second recording walking through the concern, showing the specific loop, explaining the worry, and suggesting an alternative gives them everything they need to respond or fix it.

Recorded code reviews are not a replacement for written comments. They work best alongside them: the written comment creates a searchable record; the recording delivers context that text handles poorly.

What to record and what not to

Record when:

• The concern is architectural. If your feedback requires understanding how several files interact, a recording showing you navigate between them is far clearer than “see also X and Y and Z.”
• The fix is non-obvious. Showing the specific change you would make — typing it out in the diff — is often faster to understand than describing it.
• You are leaving many comments. A 3-minute walkthrough that covers your top concerns can replace a dozen separate inline comments, and signals that you read the whole PR rather than spot-checked it.
• The author is junior or new to the codebase. Context that you assume is obvious often is not, and video lets you fill in that context conversationally without writing a wall of text.

Do not record when:

• The comment is a nit (typo, missing semicolon, naming preference) — a written comment is faster for both of you.
• You are using a recording to avoid having a live conversation that would resolve the issue in 2 minutes.

Setup before you record

Open the PR in a browser tab, not a desktop app. This keeps the recording focused and avoids accidentally capturing anything else on your screen.

Read the whole diff first. A recording that backtracks, says “actually wait, ignore that,” or ends mid-thought is harder to follow than a live session. Know what you are going to say before you press record.

Have the relevant parts of the codebase open in other tabs if you plan to navigate to related files. Tab-switching in a recording is fine; hunting for a file mid-sentence is not.

Decide whether you need your face. A code-focused review usually does not benefit from a webcam overlay — it splits the viewer’s attention between your face and the code. Disable it unless you are recording something where tone matters.

Recording the review

Start with a one-sentence orientation: “I’m walking through the pull request for the authentication refactor — I have a few concerns I’ll walk through.” This lets anyone who comes back to the recording later understand what they’re watching without reading the PR title.

Navigate slowly. You know what you are looking at; the viewer does not. Give them a beat to orient before you start speaking about a specific section.

Point explicitly. “Line 47 here” is much clearer than “this line” — the viewer cannot see your cursor position without deliberate movement. Move your cursor to the exact line before you discuss it.

Separate observation from opinion. “This loop iterates through the full list on every render” is an observation. “That will cause performance issues at scale” is an opinion. Stating both clearly, in that order, makes your feedback easier to act on.

Suggest, don’t just critique. If you can show a version of the change that addresses your concern — even a rough sketch typed directly into the file — do it. A recording that shows the problem and the fix is more useful than one that only shows the problem.

Keep it under 5 minutes for a single concern, under 10 minutes for a full review. If you need longer, split the recording by concern. A 12-minute recording that covers six issues is harder to act on than three 4-minute recordings, each focused on one thing.

Sharing the recording

A browser tab recording exports as WebM, which embeds directly in Notion, Linear, Slack, and most modern doc tools. For GitHub comments, attach it as a file — GitHub renders video in comment threads.

If your team uses async video tools, those work too. The advantage of a local recording is that it never expires, never requires the viewer to create an account, and stays attached to the review even years later.

Getting useful responses

Ask a specific question at the end: “Does the trade-off I’m worried about make sense given the expected data size?” is better than “thoughts?” A recorded review with a clear question at the end gets a faster, more actionable response than one that trails off.

If the author wants to respond in kind — recording their own 2-minute reply walking through their reasoning — great. That conversation, captured in video on both sides, is often more useful than the same exchange would have been in real-time.

---

ScreenKit records your browser tab locally, exports to WebM, and never touches a server. Install it, record the review, share the file — that’s the whole workflow.