Voice-First Code Review: Talk Through PRs Like You're Pair Programming

Code review comments are the passive-aggressive tweets of the development world. We've all written them. We've all received them.

"Interesting approach here."

Translation: What on earth were you thinking?

"Might want to consider the edge cases."

Translation: This is going to break in production.

"nit: spacing"

Translation: I have nothing useful to say but I need to justify my review.

There's a better way. And it involves talking instead of typing.

The Written Review Problem

Written code review comments strip out all the nuance that would be present in a verbal conversation. Tone doesn't translate. Intent gets lost. Friendly suggestions read as harsh criticism.

Plus, written comments take forever to compose. You want to be thorough but not harsh, specific but not pedantic. The cognitive overhead is enormous.

So we either rush through reviews (missing issues) or spend way too long on them (killing productivity).

Voice Review Workflow

Here's what I've been experimenting with: reviewing PRs by recording voice notes.

Instead of typing out comments, I open the PR, hit record, and talk through my review as if the author were sitting next to me.

"Okay, looking at the changes in user-service.ts. The new validation logic looks good, I like how you're handling the null case here. One thing I'd suggest—around line 45—you might want to extract this into a helper function since I see similar logic in the auth module. Not blocking, just a thought for reducing duplication."

This gets transcribed and posted as a PR comment. It takes maybe 30 seconds instead of 5 minutes.

Why It Works

Tone Comes Through

When you speak, you naturally include softeners. "One thought," "maybe consider," "I wonder if." These get transcribed and preserve the collaborative intent.

Context Gets Included

Spoken reviews naturally reference the bigger picture. You explain why you're suggesting something, not just what to change.

Speed

Speaking is 3-4x faster than typing for most people. A review that took 15 minutes now takes 5.

Actually Doing Reviews

The biggest win: reviews actually happen. The lower friction means PRs don't sit in the queue for days.

Best Practices

• Start with positives - Verbally acknowledge what's working before diving into suggestions.
• Be specific about locations - "In the useEffect around line 30" rather than vague references.
• Distinguish blocking vs non-blocking - "This needs to change before merging" vs "Optional improvement for later."
• End with summary - "Overall this looks ready to merge with that one small change to error handling."

The Future: Video Reviews?

Some teams are experimenting with Loom-style video reviews where you share your screen while talking through the code. This adds even more context—you can highlight specific lines, show how you tested something, demonstrate the issue you're describing.

It's not for everyone, and it takes longer to consume than text. But for complex reviews, it's incredibly effective.

The trend is clear: asynchronous code review is moving from terse text toward richer, more human communication. And voice is leading the way.