Dictating code and shell commands: when it works

9 September 2026 · 6 min read

Dictation is good at the English around code and poor at code itself. Commit messages, pull request descriptions, review comments, documentation and chat all dictate well; a line of Python with underscores, brackets and mixed case does not. You can speak most symbols by name, but case, indentation and exact spacing are where it falls apart, and a misheard word in Terminal is not a typo, it is a command.

What actually works

Start with the parts of a developer’s day that are prose, because that is where the time is:

• Commit messages and pull request descriptions, which are usually the longest thing anyone types in a day and the thing most often written badly because typing them is a chore.
• Code review comments, issue reports and bug write-ups.
• Documentation, README sections, comment blocks above a function.
• Chat, mail and standup notes.
• Prompts to an assistant inside your editor. This one has quietly become the strongest case for dictation in a technical job: the prompt is a paragraph of English about code, which is exactly what dictation is best at.

The pattern that works is mixed input, not voice input. Hands on the keyboard for syntax, voice for anything that is a sentence. Nobody dictates a whole file, and the people who try give up.

Why the code part fights you

Four separate things go wrong, and they compound.

Case. getUserName, get_user_name and GetUserName all sound identical. There is no spoken form that distinguishes them, so either you say the case out loud word by word or you fix it afterwards. For a single identifier that is fine. For a screen of them it is slower than typing.

Spacing. Recognizers put spaces around words, which is what prose needs. Code needs user.name and gets user . name. Every symbol you dictate arrives with the wrong whitespace somewhere.

The Mac helping. Automatic capitalization turns the first word of every dictated line into a capital. Smart quotes turn " into a curly quote that no shell or compiler accepts. Both are on by default, both are correct for writing and wrong for code, and both live in System Settings, Keyboard, Text Input, where the Edit button next to your input source reveals the toggles for spelling correction, automatic capitalization and smart quotes.

The editor helping. Autocomplete, bracket pairing and snippet expansion all react to text arriving character by character. Dictated text arriving in a block can trigger a completion you did not want, or land inside a bracket the editor closed for you.

Speaking symbols

Dictation on a Mac does understand symbol names, and the list is longer than most people assume. The reliable ones in everyday use:

• “period”, “comma”, “colon”, “semicolon”, “question mark”
• “open parenthesis”, “close parenthesis”
• “asterisk”, “ampersand”, “at sign”, “dollar sign”, “percent sign”
• “plus sign”, “equals sign”, “underscore”, “hyphen”
• “forward slash”, “backslash”, “quote”
• “new line”, “new paragraph”

Test the ones you need in a scratch document before trusting them in real work, because coverage varies by language and by recognizer. Curly braces and square brackets in particular are worth checking on your own machine rather than assuming, and if a symbol is unreliable it is faster to leave a placeholder word and replace it afterwards than to fight it live.

For the parts that are not words at all, Voice Control does better than Dictation. System Settings, Accessibility, Voice Control gives you “Press Command S” and the same pattern for any shortcut, plus custom commands under Commands where a phrase you choose can insert a block of text or press a key combination. A phrase that types your standard test scaffold, or one that jumps to the terminal pane, is worth more than any amount of dictated syntax. Voice commands while dictating covers that split in full.

Terminal: dictate into a scratch buffer, not the prompt

This is the part to be careful about. Text dictated into a shell prompt is a command waiting for one keystroke. A misheard flag or a stray word does not sit there looking wrong; it runs.

The safe habit:

1. Dictate the command into Notes, a scratch file, or the note field of whatever you use.
2. Read it back as a command, not as a sentence. Check flags, paths and quotes specifically.
3. Copy it without the trailing line break. Text copied with a newline at the end can execute the moment it is pasted.
4. Paste at the prompt, look at it once more, then press Return yourself.

Two things to never dictate at all: anything with rm in it, and anything containing a path you have not read character by character. The keyboard is faster than the recovery.

For commands you run often, the answer is not better dictation but a shell function or alias in ~/.zshrc, triggered by a short word you can type in half a second. Voice is for the thinking part; the repetitive part belongs in a script.

Vocabulary is the setting that pays

Whatever you dictate into, the recognizer has never heard of your codebase. Project names, service names, library names and the surnames of your colleagues come out as approximate English words, and correcting the same six terms every day is what makes people quit.

Two places to fix it. Voice Control has a Vocabulary list in its settings where you add words it should expect. And Voice Keyboard Pro has a personal vocabulary for names, project codes and jargon, plus text snippets; because it drops text at the cursor in whatever app is in front, including editors and Terminal, the same vocabulary applies everywhere rather than only in one app. It holds to a key you choose (Left Control by default), so the microphone is closed unless your finger is down, which matters when you are talking to a colleague between paragraphs. It needs macOS 14 Sonoma or later. Be clear about what it is: dictation that knows your words, not a system that understands your syntax. No dictation tool does the second thing.

Where the honest limit is

If your hands need a break for a week, dictating prose and using spoken shortcuts for navigation will carry you through most of a working day, and you will type less than you thought. If your hands need to be off the keyboard permanently, code by voice is a real discipline with its own grammars and custom commands, and Voice Control’s custom commands are the built-in starting point for it. That is a bigger project than turning on dictation, and it is worth knowing that before you start rather than after two frustrating days.

Questions

Does dictation work in a code editor? In an editor that uses the standard macOS text system, yes, and text lands where the cursor is. In an editor drawing its own text surface, or in anything running through a remote session or a virtual machine, test it before relying on it; the words may go to the local window instead of the remote one.

Can I dictate a Git commit message? That is the best case for dictation in a technical job. Write it in the editor Git opens rather than in a quoted string on the command line, so nothing you say can become part of a command. Setting up a dictation hotkey covers making that a one-key action.

Why do dictated quotes break my code? Smart quotes. macOS substitutes typographic quotes in normal text, and compilers and shells only accept straight ones. Turn the substitution off for your input source in System Settings, Keyboard, Text Input, or fix them with a find and replace before running anything.

Is there a way to dictate indentation? Not directly, and it is not worth chasing. Dictate the line, then let the editor reindent the file, which most will do with a single command or on save.