Dictating code in VS Code: a developer's guide to voice-driven typing

The blunt truth

Voice dictation does not type good code. It will never type const handler = (req: Request, res: Response) => { ... } in one fluent breath. Syntax, capitalization, brackets, quotes — that's why we have keyboards.

But raw syntax is maybe 10% of what a developer actually types during a workday. The other 90% — commit messages, code comments, Slack messages, GitHub PR descriptions, Linear tickets, JSDoc, README sections, variable name brainstorming, design docs — is regular prose sitting next to code. That part is wide open for voice.

This guide shows what works (and what doesn't) for combining voice dictation with VS Code in 2026, plus exact workflows for the copy-paste-or-type situations devs hit dozens of times per day.

What voice IS good at, for devs

Commit messages

Most commits get a one-liner that takes longer to type than to think. Holding a hotkey and saying "Fix race condition in session refresh — two parallel refresh calls were burning the same refresh token. Added a 30-second cooldown mutex around the refresh call so the second caller just waits for the first." is faster than typing it, and you end up with a more descriptive commit than you'd normally bother to type.

Code review comments on GitHub / GitLab

Comments on PRs are prose, often complete paragraphs. Voice gets you from "let me click into the review thread" to a full thought without breaking your reading flow.

Slack messages while debugging

"@channel anyone else seeing a 502 from the auth endpoint?" is a 4-second voice message and a 30-second type-and-edit cycle. The difference matters when you're mid-debug.

JSDoc / Rustdoc / docstrings

Documenting a function in prose is one of the lowest-ROI activities in software engineering. Voice doesn't make the doc better, but it makes it cost nothing — so you write more of them.

Linear / Jira tickets and PR descriptions

Anywhere you need 2-5 paragraphs explaining what changed, what's affected, and what to test. These are sloggy to type and very natural to talk through.

What voice is NOT good at, for devs

Typing actual syntax

Code is dense with characters that are easy to say wrong and slow to dictate one-by-one: {}, <>, ::, =>, semicolons, quotes inside quotes. There's no future where this is faster than typing.

Tab-completion-heavy work

When you're 4 letters into a variable name and your LSP is offering the right autocomplete, voice loses. Use the keyboard.

Anything with strict whitespace

Python, YAML, indented Markdown. Voice can't reliably control indentation — and indentation is part of meaning.

The 4 workflows that work

Workflow 1 — Voice for prose, keyboard for code

The simplest setup. Your dictation app types into the active text field, whatever it is. You decide on a per-keystroke basis whether to use voice (for a prose region) or keyboard (for a code region).

Pithflow's default hotkey is Ctrl+Space. Hold it → speak → release. The text appears wherever your cursor is. In VS Code that means: hit Ctrl+Space, dictate the JSDoc, release, then hit Tab to dismiss and continue typing the function body normally.

The win: minimal context switching. You stay in VS Code, never alt-tab to a separate "dictation app." The hotkey is muscle memory within a day.

Workflow 2 — "Talk the function, let Copilot write it"

This one is genuinely new in 2026. The pattern:

1. Open a fresh file or function
2. Hit Ctrl+Space
3. Dictate the intent: "Write a TypeScript function that takes a string of comma-separated emails, validates each one using a regex, and returns an array of { email, valid: boolean }. Skip empty strings."
4. Release Ctrl+Space — the comment lands in your file
5. Trigger Copilot or Cursor's Tab — it writes the function under your comment

You just designed a function by talking. The voice tool isn't typing the code — Copilot is. Voice's role is to capture intent fast enough that you don't lose the thread between "have idea" and "write instructions for AI."

Workflow 3 — Snippets for the boilerplate

Voice dictation tools usually let you define snippets — short trigger phrases that expand to longer canned text. Useful for things that show up constantly:

• "my email" → your full email address
• "sig" → your signature line for emails
• "todo" → // TODO(yourname):
• "caveat" → "Caveat: there's a known edge case where..."
• "jwt comment" → a block comment template you reuse for auth handlers

Dictate the trigger like any other word; the tool replaces it with the expansion. Especially valuable for commit-message conventional formats ("feat colon " → feat:) and ticket prefixes ("FLOW dash" → FLOW-).

Workflow 4 — Punctuation-explicit mode for code comments

Most dictation tools have an "AI cleanup" pass that adds punctuation and capitalization for you. That works great for emails and Slack. For code comments, it sometimes adds emphasis or paraphrases that you don't want.

Set your tone to "Code comment" or "Note" before dictating into source files. These modes use cleanup that's stricter — fewer adjectives, no marketing copy, no over-explanation. The output reads like a developer wrote it.

Hotkey tips for the VS Code setup

VS Code already claims Ctrl+Space for IntelliSense, so if you keep Pithflow's default hotkey there'll be a conflict. Three options:

1. Change Pithflow's hotkey to something VS Code doesn't use — Right Alt, Caps Lock, or F12 are popular. Pithflow's Hotkey tab lets you capture any combination, including single keys.
2. Change VS Code's IntelliSense trigger to Alt+Space (Settings → Keyboard Shortcuts → search "Trigger Suggest"). Frees up Ctrl+Space globally for dictation.
3. Use hands-free mode for long dictation sessions (writing a multi-paragraph PR description). Tap-to-toggle instead of hold-to-speak, no key conflict because you're not holding anything.

Tones every dev should set up

Pithflow ships with 8 tone presets, but for dev work three of them cover almost every situation:

• Code comment — terse, no fluff, no emphasis. Strips "basically" and "essentially." Use for JSDoc, Rustdoc, and inline comments.
• Slack — short sentences, light casual register, no signature block or "Hi all" preamble. Use for team chat and DMs.
• Email — adds a polite hello, structures the body, ends with a clear ask. Use for external email and longer PRs.

Switch tones with a one-key shortcut from the system tray. You can also bind global hotkeys to tone changes — e.g. Ctrl+1 for Code comment, Ctrl+2 for Slack — so you never leave the keyboard.

How much faster is it, actually?

For me (writing this guide): I dictated the first draft at about 165 words per minute. After AI cleanup landed it on the page, I edited for ~10 minutes to fix flow, remove repetition, and check the code examples. Total: about 25 minutes for a 1,600-word post.

Typing the same thing? I'd guess 90-120 minutes including the edit pass. The voice → cleanup workflow doesn't make me a better writer, but it does collapse the "thinking out loud" and "writing the first draft" stages into one.

For commit messages and Slack replies — high frequency, low complexity — the speedup is maybe 3-5x. For PR descriptions and longer docs — high effort, medium complexity — it's more like 2-3x. For actually typing code, it's 0x because I don't use voice for that.

Common objections, addressed

"I don't want to talk to my computer in a coffee shop"

Fair. You can do this with whispered speech — modern transcription handles whispers well — or just use voice when working from home or an office, and the keyboard everywhere else. The two workflows coexist.

"I'm a fast typist already"

Typing speed is a ceiling around 90-110 WPM for almost everyone. Speaking ranges from 130 to 180 WPM. The math says you'll be faster for prose if you're better than your typing's worst case (after long sessions, with cramping wrists, etc.) — but not by as much as marketing claims suggest.

Where voice always wins for fast typists is in fatigue: by hour 6 of typing, your speed and accuracy degrade. Voice doesn't degrade the same way. If you're shipping at the end of the day, that gap widens.

"My English isn't perfect"

Modern dictation handles non-native accents well. Pithflow also has 100+ languages — you can dictate in Spanish, Portuguese, German, Japanese, anything, and the output gets cleanup in that same language. Especially relevant for code review comments to a multilingual team.

Setting it up — exact steps for VS Code on Windows

1. Install Pithflow (free tier is plenty for trying this out)
2. Open Pithflow → Hotkey tab → set primary hotkey to Right Alt or another VS Code-friendly key
3. Style tab → set default tone to Code comment
4. Snippets tab → add 3-5 trigger phrases you type 10+ times a day (your email, your name, conventional commit prefixes)
5. Open VS Code → open a JSDoc block → press your hotkey → describe the function → release
6. Dismiss with Esc, type the actual function body

From install to a working voice-driven dev workflow: about 8 minutes. Reverse it any time by changing the hotkey back, or just close the tray icon.

---

Pithflow is voice dictation that runs across every Windows app and cleans up filler words automatically. Download free. Free tier: 2,000 words/week, no card.