Dictating code and technical terms on a Mac

Written 15 August 2026.

Dictation into a terminal fails for a reason that has nothing to do with accuracy: everything that makes dictated prose readable is damage when the target is syntax.

The problem is helpfulness, not recognition

Dictation is tuned to produce sentences. It capitalises the first word, adds a full stop, expands what looks like an abbreviation, and turns spoken punctuation into typographic punctuation — including curly quotes. Every one of those is right in an email.

In a terminal, a curly quote is a syntax error. In an editor, a capitalised first word is a different identifier. git commit dash m is not Git commit dash m., and a shell does not care that the second one reads better.

So the useful question is not "which tool is most accurate on technical words" — it is "which tool can be told to stop helping".

Per-app behaviour is the actual fix

What works is one hotkey that behaves differently depending on where the cursor is: word-for-word in a terminal or an editor, cleaned-up prose in Mail or a browser. You do not want to think about which mode you are in, and you definitely do not want to flip a setting before each dictation.

Bunso does this with a per-app profile, so the same key gives you verbatim text in Terminal and finished sentences in Mail. When the profile is wrong for a particular moment — a proper sentence in a terminal, something word-for-word in an email — a second hotkey forces the other mode for one dictation. (That forced-mode key is part of the paid tier; the per-app profiles themselves are not.)

There is a safety property worth naming here: a forced "word-for-word" skips the cleanup step entirely, which means nothing about that dictation can leave the machine even if you have optional cloud cleanup switched on.

Technical vocabulary still needs teaching

Per-app behaviour solves formatting. It does not make a model know kubectl, or your internal service names, or a library that shipped after the model was trained.

Those go in a custom dictionary, and the mechanism matters: the terms are given to the recogniser before it transcribes, so it is biased toward your spelling rather than corrected afterwards. Twenty terms covering the names you say every day does more than any amount of careful enunciation.

The distinction to keep in mind — and the reason both exist — is that a dictionary term shapes what the recogniser hears, while a correction rewrites the transcript afterwards. Use a term for a word the model gets wrong because it does not know it. Use a correction for a word it reliably hears as something else.

What still does not work well

Dictating code structure — brackets, indentation, camel case — is a different problem from dictating technical prose, and no amount of per-app behaviour solves it. Speaking a nested expression aloud is slower and more error-prone than typing it for most people.

Where dictation genuinely pays in technical work is the prose around the code: commit messages, pull request descriptions, code review comments, design docs, and the long explanatory Slack message you keep putting off. Those are sentences, they are the part of the job people write least willingly, and they are exactly what a cleanup pass is good at.

If you want the raw transcript untouched everywhere, that is also a supported setting — the cleanup pass is a stage you can turn off, not a condition of using the tool.