Dictation for developers: not for the code

Last updated 23 September 2026

The claim we are not making

Voice-driven programming exists, it is a serious accessibility tool, and for engineers with RSI or limited hand mobility it can be the difference between working and not. That is a real and important use, and it is not what this page is about.

For everyone else: dictating const handleSubmit = async (e) => { is slower than typing it, will always be slower than typing it, and anyone demonstrating otherwise has chosen the sentence carefully. Your editor already has completion, snippets and an AI assistant. Speech is not competing with an empty buffer.

Where it actually pays

AI prompts, by a distance

This is the single best use of dictation for a developer in 2026. A good prompt to Claude, Cursor or a coding agent is long, contextual and rambling — exactly the shape speech produces naturally and typing discourages. You type a six-word prompt because a sixty-word one is tedious. You speak the sixty-word one without thinking about it, and get a much better answer.

Same nine seconds of your attention. Completely different answer. See dictating better AI prompts and dictating in Cursor.

Pull request descriptions

The PR body that says "fixes bug" is the one that was typed at the end of a long afternoon. Speaking it takes twenty seconds and produces the context your reviewer needs: what changed, why this approach, what you considered and rejected, what to look at closely.

Review comments

The cost of explaining why is what makes review comments terse, and terse review comments are how teams end up in arguments. Speaking a comment costs almost nothing, so the reasoning survives.

Incident and decision records

Nobody writes the post-incident note properly at 2am. Most people would dictate it, because talking through what just happened is what you are doing anyway. Same for architecture decision records — the format is a paragraph of context and a paragraph of consequence, which is a spoken shape.

The privacy point, for this audience specifically

Developers dictate things that should not be on someone else's server: code snippets, stack traces with internal hostnames, customer identifiers in a debugging note, credentials mentioned by accident while describing a problem.

If your dictation app transcribes in the cloud, all of that is transmitted. The vendor is probably careful. Your security team still did not approve it, and you probably did not ask. On-device recognition removes the question rather than answering it.

Setting it up for a developer's environment

1. Pick a shortcut your editor does not want This takes longer than you would think. Between your editor, your terminal multiplexer, your window manager and your launcher, most reasonable keys are taken. A right-hand modifier or a function key is usually free; on Windows, Right Ctrl is the suggested default. See choosing a dictation shortcut.
2. Teach it your stack on day one Kubernetes, nginx, Postgres, OAuth, Kafka, your service names, your team's names. Twenty entries covers a career's worth of daily corrections. Speech models mangle technical vocabulary because it is rare in ordinary English, not because they are bad.
3. Make snippets for the boilerplate A spoken trigger that expands to your PR template, your standard "this needs a test" review comment, or your incident note skeleton.
4. Latch it for long prompts Double-tap to keep the microphone open, tap again to stop. Holding a key for ninety seconds while you explain a bug is unpleasant; latching is not.
5. Do not dictate into a terminal Seriously. A misrecognised word in a shell is a different class of problem from a misrecognised word in a document. Dictate into the editor, read it, then paste. On Windows it would not work in an elevated one anyway: Windows does not let an ordinary program type into a window running as administrator.

What to expect in week one

• It will feel strange to talk to your computer. Everyone reports this; it lasts about three days.
• Your prompts will get longer, and the answers better. This is the first thing most developers notice, usually within a day.
• Technical terms will be wrong until you teach them. Expect to add five words a day for the first week, then almost none.
• You will keep typing. Dictation replaces prose, not everything. The people who get the most out of it are the ones who switch back to the keyboard without thinking about it — see keyboard and voice together.
• Open-plan offices are a genuine problem. There is no technical answer. A close headset microphone lets you speak much more quietly than you would expect, which helps more than it sounds.