Dictating code and technical terms: what works, what doesn't

18 August 2026 · 3 min read · Muteeb Mehraj

Developers ask whether they can dictate code. Mostly the honest answer is no, and the more useful question is which parts of a developer's writing are not code.

Why code dictates badly

A speech model predicts likely word sequences from audio. Source code is a sequence of unlikely ones. Punctuation carries meaning, whitespace is significant, identifiers are compressed and unpronounceable, and casing is load-bearing.

Say "user underscore i d equals get user by i d open paren request dot params dot i d close paren semicolon" and you have spent longer speaking it than typing it, produced something that needs correcting anyway, and broken your own concentration in the process.

There are tools built specifically for voice coding, with grammars and command languages designed for exactly this. They work, and they take real practice to learn. A general dictation tool is not one of them and should not pretend to be.

Where it genuinely helps

Look at a week of your own writing. For most developers the majority of it is prose that happens to live near code:

• Commit messages, especially the body that explains why.
• Pull request descriptions.
• Code review comments.
• Issue reports and reproduction steps.
• Design documents and architecture notes.
• Slack messages and email.
• Documentation, including the docstring above a function you just wrote.

All of that is ordinary English, and all of it is the kind of writing people skimp on because typing it is a chore. It is also where dictation is three or four times faster than typing for most people.

The best commit message you will write is often the one you dictate immediately after finishing the work, while the reasoning is still fresh, precisely because speaking it is cheap enough that you actually explain yourself.

The proper-noun problem

Technical prose is still full of words a speech model has never encountered. Your service names, your internal tools, your dependencies. Kubernetes, nginx and PostgreSQL are common enough to be fine. Your company's four internal services are not, and they will come back as whatever sounded closest.

The usual answer is a custom vocabulary that biases the decoder toward those words. It is worth knowing that this is harder than it looks, and that at least one implementation of it, ours, was measurably worse than not doing it at all. We wrote about that separately.

Until that is solved properly, the practical approach is a text-expansion layer instead: define a phrase you can say cleanly, and have the tool substitute the exact string afterwards. That is deterministic string replacement rather than a model behaviour, so it either works or it does not, and it never degrades the rest of the transcript.

Filler words

Spoken prose has different texture from written prose. You say "um", you restart sentences, you repeat words while thinking. Verbatim transcription of that is accurate and unpleasant to read.

Cleanup is worth having, and worth understanding. Pattern-based cleanup strips a fixed list of fillers and repeated words with no model involved, which means it is predictable and never changes your meaning. Model-based cleanup rewrites for tone, which reads better and can quietly alter what you said.

For a code review comment, predictable is the correct trade. Being misquoted by your own tool in a discussion about someone else's code is a bad way to find out how the cleanup works.

A workflow that works

Dictate the prose, type the code. In practice that means holding a key to talk when writing the commit body, the PR description or the review comment, and never reaching for it inside a source file.

The gain is not that you type less. It is that the explaining parts of the job stop feeling expensive, so you do more of them.