Voice coding, honestly

Two different practices share this name, and confusing them is why people try voice coding once and give up. One of them has been hard for twenty years and still is. The other became easy about two years ago, and almost by accident.

The two things called voice coding

1. Speaking code structure

You learn a command grammar — spoken phrases that produce symbols, identifiers, motions and edits. "Camel case user profile." "Snake wrap." This is the tradition of Talon, Serenade, and Dragon-based systems before them. It is genuinely powerful, and for people with RSI who cannot type it has been life-changing.

It is also a real skill with a real learning curve. You are memorising a language to avoid typing a language. People who stick with it get fast. Most people bounce off in the first week.

2. Dictating at an agent

You say, in ordinary English, what you want — and something else writes the code. No grammar, no memorisation. You already know how to do it.

This did not work before, and it is worth being precise about why. Dictating "create a function that validates the email and throws if it's malformed" into an editor in 2019 produced a sentence, not code. The sentence was useless. What changed is not speech recognition; it is that there is now something on the other end that can act on a sentence. The moment coding agents arrived, the hard half of voice coding was solved by someone else.

Which one you want

	Command grammar	Dictating at an agent
Learning curve	Weeks	None
Good for	Precise edits, navigation, working without hands at all	Prompts, intent, comments, commits, review notes
Bad at	Long prose	Exact symbol-level edits
Tools	Talon, Serenade	Any dictation tool + an agent
Ceiling	Very high, if you invest	Bounded by the agent

They are not rivals. Someone with RSI may want both. Someone who just types a lot of prompts wants the second and nothing else.

What still does not work

• Dictating literal syntax. Brackets, operators, camelCase, indentation. Speech recognition is the wrong tool and always has been; this is what command grammars exist for.
• Talking through a long refactor. Holding five files in your head and describing edits to all of them out loud is harder than doing it, not easier.
• Noisy rooms and shared offices. This is a real limit and no amount of model quality fixes it.
• Speaking in a language your model was not built for. A general multilingual model will look like it works and then quietly drop content. If you dictate in a language other than English, check the model, not the marketing.

The two things that decide whether you keep using it

Latency, not accuracy

Once accuracy is good enough, speed is what makes or breaks the habit. If the text is there within about a fifth of a second of letting go of the key, dictation feels like typing. Past a second it feels like waiting, and waiting is what makes people quit. Cloud round-trips are the usual culprit.

Where it types

Most of what you dictate while coding is not code. It is a prompt, a commit message, a comment on a pull request, a reply in Slack about the thing you just built. A tool that only works inside one editor covers a fraction of that. Whether it types into every application is a bigger practical difference than any accuracy benchmark.

If you want to try it this week

• Pick a key you never use. Side mouse buttons and CapsLock are the usual picks.
• Start with prompts only. Do not try to dictate code — you will conclude the whole idea is broken.
• Give it three days. The first hour feels strange; the habit forms faster than people expect.
• Build a replacement dictionary early. Your project names will be wrong every single time until you do.