Guide

Dictation for programmers: what actually works

Every developer who tries dictation tries it on code first, watches it produce def foo open paren, and concludes voice is useless for this job.

That conclusion is half right. Dictating code is genuinely bad. Dictating everything around the code is one of the largest speed gains available to you, and it is the part nobody tries because they quit at step one.

The honest split

Here is where voice wins and loses in a normal working day. This is not a marketing table, it is the actual boundary.

Task	Voice?	Why
Writing code	No	Syntax is punctuation-dense and position matters. The keyboard wins and always will.
Prompting an AI agent	Yes	Long, natural-language, low-precision. This is the single biggest win.
Commit messages	Yes	You already know what you did. Saying it takes ten seconds; typing it takes a minute and you write less.
PR descriptions and review comments	Yes	Prose about code, not code.
Docs, READMEs, ADRs	Yes	The reason these are thin is friction, not ignorance.
Slack and email	Yes	Highest volume, lowest stakes.
Renaming a variable	No	Two words. Just type it.

Notice the pattern. Voice wins wherever you are explaining and loses wherever you are constructing. Most developers spend far more of the day explaining than they think.

The agent-prompting case is the one that changed things

Coding agents shifted the shape of the work. You are no longer typing implementations as much as you are describing intent, at length, repeatedly, in prose. A good prompt is three or four sentences of context that you would never bother typing.

That is the exact input voice is best at. A spoken prompt is longer, more specific, and contains more context than a typed one, because the cost of an extra sentence drops to nearly zero. And prompt quality is mostly a function of how much context you were willing to include.

Setting it up so it is not annoying

It has to work in every app

The failure mode of most dictation tools is that they own a window. You talk into their box, then copy the text, then switch back. Three context switches to save typing one paragraph is a net loss, and you stop using it inside a week.

What you want is a global hotkey that inserts text at the cursor wherever the cursor already is: the terminal, the editor, the browser, the Slack box. No window, no copy step.

Teach it your vocabulary once

Accuracy does not fail evenly. Ordinary English is near perfect. Your stack is where it falls apart, because the model is guessing from a general vocabulary and nothing in it expects kubectl, Postgres, nginx, or your service names.

Any tool worth using lets you add a dictionary. Put in your repo names, your service names, your teammates, and the ten pieces of jargon you say daily. It is a five minute setup that removes most of the errors you would otherwise blame on the transcription.

Let something clean it up

Raw speech has filler, restarts, and no punctuation. A cleanup pass that fixes grammar and casing before the text lands is the difference between a usable tool and a transcript you have to edit. Just do not expect it to fix structure: it can tidy a rambling paragraph, it cannot give it a point.

What to expect in the first week

• Day one is worse than typing. You will compose out loud word by word and it will read badly. This is normal and it passes.
• Day three you stop repairing mid-sentence. This is the habit that matters most.
• Week two you are faster on prose than you ever were typing, and you still type all your code.

Speaking runs around 150 words per minute. Comfortable typing is 40 to 70. That gap is the whole opportunity, and it only exists on the prose half of your day. Which, if you are honest about where the hours go, is most of it.

usevoiceforge.com