Voice coding changed meaning, and the new one actually works

“Voice coding” used to mean one thing and now means another, and the second one is much easier than the first ever was.

The old meaning: speaking syntax

For twenty years, programming by voice meant dictating the code itself. openParen, camelCase, newline, indent. Plain dictation cannot do this — a speech model trained on human sentences hears “for I in range” and writes exactly that, in English, with a capital I.

So the tools built a command grammar instead. Talon describes itself as “Powerful hands-free input” and pairs voice control with noise clicks and eye tracking, all scriptable in Python. Serenade calls itself “The open-source voice assistant for developers” with a “speech-to-code engine,” and is explicit about who it is for: “Whether you have an injury or you’re looking to prevent one.”

Both are still developed, both work, and both ask something real of you: learning a command language. A voice coder in 2015 was someone who had memorised a grammar, and that was the price of admission. That is a fair trade when typing hurts. It is a hard sell when it does not.

The deeper problem was never recognition accuracy. Code is not natural language, and speech recognition is a natural-language technology. Saying punctuation aloud is an awkward mapping onto a system built for sentences.

The new meaning: speaking to something that writes the code

Coding agents changed the input. You no longer say openParen. You say:

“Take the retry logic out of the fetch helper and put it in a wrapper, then update the three call sites.”

That sentence is ordinary English. It is exactly what speech recognition is built for, and it needs no grammar, no command list and no training. The awkward mapping is gone, because the thing on the other end is designed to read prose.

That is the whole change, and it is bigger than it sounds. Dictation for developers stopped meaning coding with voice recognition and started meaning describing the work out loud — fast, comfortable, and needing no software beyond something that turns your voice into text in the field you are already typing in.

What actually breaks, on a Mac

Three practical things, none of them about the model.

Secure Input eats your hotkey. macOS lets an application take exclusive hold of the keyboard so nothing else can read it. Terminal has a Secure Keyboard Entry option that keeps it on the entire time Terminal is focused, and some password managers do the same. While it is on, an app watching for a global shortcut never receives the key-down event. Nothing errors; the shortcut just does nothing.

defaults read com.apple.Terminal SecureKeyboardEntry

A 1 means it is on. The full mechanics are their own article, including why a held modifier survives Secure Input while a modifier-plus-letter combination does not — which matters if you spend the day in a terminal.

Identifiers come out wrong. Product names, library names, internal jargon: Parakeet becomes parakeet, your service Kestrel becomes castrol. No model fixes this by being bigger. A custom vocabulary applied after recognition does, because you list the terms once and they come out right every time.

Short commands are not worth speaking. npm test is faster typed. The pattern that works is dictating the paragraph and typing the exact strings — the prose by voice, the identifiers by hand.

The details you only learn by getting them wrong

If you are building this rather than using it, three things from my own implementation that were not obvious:

Two different TCC permissions look like one. Accessibility being granted does not mean posting events is allowed. They are separate entries, and CGEvent.post fails silently when the second is missing — so the check has to be CGPreflightPostEventAccess(), not AXIsProcessTrusted().

A hardcoded keycode for V breaks on Dvorak. Pasting by synthesising ⌘V means resolving the keycode through UCKeyTranslate rather than assuming 0x09. Every alternative layout user finds this bug immediately, and nobody else ever does.

Restore the clipboard on a receipt, not a timer. Putting text on the pasteboard and restoring the old contents after a fixed delay loses the race under load, and the user gets their previous clipboard pasted instead of their words. Publishing the text as a lazy promise and restoring only once the target app has actually read it removes the race entirely.

None of that is visible from outside. All of it decides whether dictation feels reliable enough to keep using.

The direction nobody set up yet

Everything above is voice going into the agent. The reverse is more interesting and almost nobody has it configured: the agent reading your recordings.

An MCP server exposes transcription as tools the agent can call — transcribe this file, list past transcripts, add a term to the vocabulary. Then a meeting recording becomes something the agent can work with directly, without an API key and without the audio leaving the machine. The cost side of that is its own article, and it tilts further than you would expect, because agents are not careful about volume.

Where this leaves the old tools

If your hands are the constraint, Talon and Serenade solve a problem agents do not: full hands-free control of the machine, not just text into a field. That is a different requirement and they are the right answer to it.

If your hands are fine and you simply think faster than you type, the agent route needs nothing but a way to get words into the prompt box. Kekoso, which I build, is one of those — recognition on the device, a hotkey, a custom vocabulary for the names it would otherwise mangle.

Talon and Serenade descriptions are quoted from their own sites, read on 5 September 2026. The implementation notes are from my own code.

Questions people ask

Can you actually write code by voice?

Two different answers depending on what you mean. Dictating syntax character by character — brackets, camelCase, indentation — needs a command grammar, and tools like Talon and Serenade exist precisely because plain dictation cannot do it. Dictating a request to a coding agent needs no grammar at all, because the input is ordinary English, which is what speech recognition is good at.

What is the difference between Talon and dictating to an agent?

Talon is hands-free control of the computer: voice commands, noise clicks, eye tracking, scriptable in Python. It types what you tell it to type. An agent takes a description of what you want and writes the code itself, so the speech going in is a sentence rather than a spelling.

Why does dictation stop working in my terminal or editor?

Usually Secure Input. macOS lets an app take exclusive hold of the keyboard, and Terminal has a Secure Keyboard Entry option that keeps it on the whole time Terminal is focused. While it is active, apps watching for a hotkey never see the key-down event, so nothing happens and nothing explains why. Check with: defaults read com.apple.Terminal SecureKeyboardEntry

Is dictating prompts actually faster than typing them?

For long prompts, usually yes, because prompts are prose and prose is where speech wins. For short commands it is not — typing 'npm test' is faster than saying it. The pattern that works is dictating the paragraph of context and typing the exact strings.

Does voice coding help with RSI?

It is the original reason these tools exist — Serenade's own pitch mentions injury and prevention directly. Dictating to an agent shifts even more work off the keyboard than syntax dictation did, because one spoken sentence can replace a lot of typing. It is not medical advice, and the right advice about your hands comes from someone who examined them.

Can an AI agent read my recordings and transcripts?

If you give it a local tool for that, yes. An MCP server exposes transcription as tools the agent can call, so it can transcribe a file and read the result without an API key or an upload. That reverses the direction: instead of your voice going into the agent as a prompt, your recordings become material the agent can work with.