Here's a thing that snuck up on our whole profession: count the words you typed yesterday and sort them into "code" and "English about code". If you're working with Claude, Cursor, Copilot, or any of their cousins, English probably won. Prompts are paragraphs. Follow-ups are paragraphs. The PR description, the review comments, the issue reproducing that flaky test, the Slack thread about the incident — paragraphs, all of it. We've spent twenty years optimizing how fast we type code, and then the job became writing prose to a machine that writes the code.
Prose has a faster input device. You've had it your whole life.
Where dictation earns its keep
- AI prompts, above all. A lazy prompt gets a lazy answer, and everyone knows the fix — more context, more constraints, what you tried, what failed. Nobody types all that at 11 PM; it's too much typing. Speaking it is thirty seconds. The prompt you'd never bother typing is the one that gets the right answer on the first try, and dictation makes that prompt cheap. This alone justifies the setup.
- PR descriptions and review comments. The difference between "lgtm" and a paragraph explaining why the approach is right is the difference between a rubber stamp and a review. Explaining out loud is something developers already do well — every rubber duck knows it. Now the duck types.
- Commit messages, issues, standups. The daily sediment of small prose. Each one is a minute of typing or fifteen seconds of talking; multiply by a career.
- Docs and ADRs. First drafts by voice are looser and more complete — closer to how you'd explain the design to a colleague, which is what a doc should have been anyway. Tighten by hand afterward.
Where the keyboard still wins
Let's not oversell this. Editing code by voice — args?.filter(Boolean).map(f => f.id) — means speaking punctuation soup, and it's miserable. Dedicated voice-coding systems for hands-free programming exist (Talon is the serious one, built for accessibility needs, and it's impressive); that's a different discipline with a real learning curve. The workflow we're describing needs no learning curve at all: speak the English, type the symbols. Push-to-talk makes the split effortless — hold the key when talking to humans or AIs, keep coding when not. No modes to enter, nothing to remember.
The setup that actually sticks
OpenVoiceFlow is our app, free and open source, so the specifics below use it — but the principles port anywhere.
- Push-to-talk on a key you don't fight over. Default is
fn. Hold, talk, release; text lands in whatever has focus — Cursor's chat pane, a GitHub comment box, your terminal. It's a five-stage local pipeline under the hood, but it feels like a longer spacebar. - Load the dictionary before you judge accuracy. Whisper has never seen your service names, and no model size fixes that (we explain why). Spend five minutes:
kubectl,useEffect,psql,nginx, teammates' names, the staging cluster's cursed codename. Every term is fixed once, forever. - Per-app styles. Casual in Slack, imperative-mood in commit messages, formal in email — configured once per app, applied automatically.
- Snippets for the boilerplate. Spoken shortcuts that expand to full text: your standup preamble, the bug-report template, the "thanks, merging" sign-off.
- Cleanup, tuned to taste. Off by default — raw transcript, fully local. On, it drops the "um"s and fixes grammar via your own key (OpenRouter, OpenAI, Anthropic, Groq) or local Ollama. For prompt-writing, raw is usually fine; LLMs are unbothered by a stray filler word. For PR prose, cleanup is nice.
The part your security team will ask about
Speaking your codebase's internals aloud to a cloud transcription service is a genuinely reasonable thing for a security team to veto. The clean answer is architectural: with on-device transcription, the audio never leaves the Mac — there's no server, no account, no retention policy to audit, because there's no upload. OpenVoiceFlow's transcription is local always; with cleanup Off or pointed at Ollama, the entire pipeline is airtight, NDA-code included. The privacy page states it plainly, and since the app is MIT-licensed, "trust us" is replaced by "read it" — an argument that tends to end the meeting. It also works offline entirely, as we've tested with the radios off.
A week-long experiment worth running
Don't change your workflow; add one held key. For one week, dictate only two things: every AI prompt, and every PR description or review comment. Notice two effects — the obvious one (words per minute) and the sneaky one: your prompts get longer and better, because the cost of context dropped to nearly zero. Most people who try this stop noticing they're doing it by Thursday, which is the highest compliment an input method can earn.
FAQ
Can I dictate actual code?
You can, but you mostly shouldn't — symbol density makes it slower than typing. Dictate the prose around the code: prompts, comments, commits, reviews, docs. For fully hands-free coding as an accessibility need, look at a dedicated system like Talon.
Does it work in terminals and IDEs?
Yes — text pastes at the cursor in any macOS app: VS Code, Cursor, iTerm, Xcode, browsers. If it has a text field, it works.
Is it safe for proprietary code?
Transcription is on-device; audio never leaves the Mac. With cleanup Off (default) or via Ollama, nothing does. Cloud cleanup, if you opt in, sends text only, under your own key.
What does it cost?
Nothing. Free, MIT-licensed, no account. If you enable cloud cleanup you pay your model provider cents for tokens — a rounding error next to $144-a-year subscriptions.
Your next prompt, spoken
Free and open source. Hold a key, describe the bug properly for once, release. The keyboard keeps the semicolons.