Why Developers Dictate Code Reviews
Code review is one of the most text-heavy parts of a developer's day, and most of that text has nothing to do with code. It's prose: explaining why a function should be refactored, flagging an edge case the tests missed, suggesting a clearer name for a variable, or writing "LGTM, nice catch on the null check" for the tenth time this week. Typing all of that, comment after comment, pull request after pull request, adds up to real time and real hand fatigue on top of the hours already spent reading diffs. Scrybapp turns that typing into speech: hold a shortcut, say what you'd normally type into the GitHub comment box, and the text appears exactly where your cursor is.
This isn't a niche use case. Any developer who spends part of their week reviewing teammates' code, whether that's two PRs a day on a small team or dozens a week on a platform team responsible for gatekeeping a shared codebase, ends up writing more review prose than they realize. It's just spread across small boxes throughout the day instead of one long writing session, which makes the total cost easy to underestimate.
The Real Cost of Typing Every PR Comment
A mid-size team reviewing 15 to 20 pull requests a week easily generates over a hundred inline comments across that workload. Multiply a 30-second typing task by a hundred and you're looking at over an hour a week spent just writing review text, not counting the time spent actually reading and understanding the diff. Reviewers who write more thorough comments, the kind that explain "why" and not just "what," end up typing even more, which creates a strange incentive: writing a genuinely helpful comment costs more time than writing a dismissive one.
That incentive shows up in the comments themselves. When writing has friction, reviewers default to "nit: rename this" instead of the two or three sentences of context that would make the nit worth acting on. Junior developers in particular lose out here, because the comments that teach them something ("this pattern breaks under concurrent access because...") are exactly the ones that take the longest to type and therefore get skipped most often under time pressure.
How Voice Typing Helps
- Faster comment drafting — speaking a paragraph of explanation takes a fraction of the time of typing it, so reviewers end up writing more context instead of terse one-liners they'd otherwise settle for.
- Less repetitive strain — reviewing PRs back to back on top of a normal day of writing code means hours of typing that add up; dictating comments cuts down the keyboard time that accumulates across a full week.
- Works inside any browser or editor — Scrybapp doesn't care whether you're in GitHub's web comment box, a GitLab merge request, Bitbucket, or a local diff tool. It types into whatever text field currently has focus.
- Filler words removed automatically — dictated review comments come out reading like clean prose rather than a transcript, so you're not manually editing out "um" and "so basically" before hitting submit.
Where This Fits in a Developer's Actual Workflow
Code review rarely happens in isolation. You're reading a diff, alt-tabbing to check documentation or the original ticket, then coming back to leave a comment while the reasoning is still fresh. That's exactly the moment typing breaks flow: your hands have to switch from navigating (scrolling, arrow keys, clicking through files) to composing full sentences, and the context you were about to write down starts slipping while you find the right words to type. Speaking the comment the moment you think of it keeps that context intact instead of losing it to the mechanics of typing.
This is the same reasoning behind dictating inside an editor while voice coding more broadly, just applied to the review side of the job rather than the writing side. Developers who already dictate commit messages or comments while coding tend to extend the habit naturally to code review, since the shortcut and the workflow are identical, only the destination text field changes.
The same logic applies to PR descriptions and summary comments, the paragraph at the top of a review explaining your overall take before diving into line-by-line notes. These are usually the comments that get the least effort because they take the most typing to do well. A five-sentence PR summary dictated in fifteen seconds is one that actually gets written, instead of getting reduced to "approved, few nits" because nobody wants to type a full paragraph before their coffee kicks in. The same is true for the description you write when opening your own PR: explaining the "why" behind a change in a few dictated sentences takes less effort than typing it, and it's the part of a PR that future engineers reading the history will actually thank you for.
Common Review Scenarios Where Dictation Saves Time
Some review moments benefit more than others. Explaining a security concern, walking through why a race condition could occur, or describing an alternative implementation approach all require full sentences and connected reasoning, which is where typing slows people down the most. Short comments like "typo" or "remove this" don't benefit much from dictation since they're already fast to type, but the paragraph-length comments that actually change how a PR gets merged are where the time savings show up.
Reviewing on a laptop away from a desk is another case worth mentioning. Developers reviewing PRs from a couch, a train, or a standing desk without a full keyboard setup often type slower and make more errors than they would at their main workstation. Dictating the same comment removes that variability entirely, since speaking doesn't get slower just because your typing position is awkward.
Getting Started with Scrybapp for Code Reviews
Download Scrybapp, hold ⌥Space anywhere on macOS, and start talking. It behaves the same whether you're in a GitHub PR comment box open in Safari or Chrome, a terminal running gh pr comment, or VS Code's own review panel if you use the GitHub Pull Requests extension there, similar to how it works for voice typing directly inside VS Code. Everything is transcribed locally on your Mac using Whisper AI, so none of your review comments, code snippets read aloud, or internal project names mentioned in passing get sent to a server anywhere. For teams working under an NDA, on unreleased features, or on client codebases with confidentiality requirements, that local-only processing isn't a minor detail, it's the reason dictation is usable at work in the first place.
Setup takes about two minutes: install the app, grant microphone and accessibility permissions when macOS prompts for them, and confirm the shortcut you want to use (⌥Space by default, configurable if it conflicts with something else). There's no account to create and no dashboard to configure before you can start dictating. It's a $19 one-time purchase, not a subscription, backed by a 14-day money-back guarantee, so testing it across a normal week of reviews costs nothing beyond the few minutes it takes to install.
Tips for Dictating Code Review Comments
- Say punctuation and formatting explicitly when it matters, like "backticks get user backticks" for inline code references, or dictate the sentence and clean up the formatting afterward for short snippets.
- Speak in full sentences rather than clipped phrases. "This could throw if the array is empty, worth a guard clause here" transcribes more cleanly and reads better than "empty array guard clause?"
- Draft the summary comment first, out loud, before starting line-by-line notes. Saying your overall take forces you to form an opinion on the PR before getting lost in individual details.
- Use dictation specifically for the comments you'd normally skip writing because they take too long to type by hand. That's usually where the real review value is hiding.
- If you review the same kind of issue often, like missing error handling or unclear naming, dictate a slightly longer explanation the first few times. It's faster than typing a template and reads less like a copy-paste comment to whoever receives it.
Code review is judged on more than approval speed. The comments that explain reasoning, flag a subtle bug before it ships, or teach a pattern to someone newer on the team are the ones that make the process worth doing at all, and those are exactly the comments that typing friction tends to squeeze out first. Speaking them instead removes that friction without changing anything else about how you review code.