How to start coding by voice

There is a particular kind of disappointment that comes from trying to "code by voice." You imagine dictating a function, saying "open paren," "semicolon," "close brace," and watching it appear. You try it for ten minutes, the result is a mess, and you decide voice is not for programming. That conclusion is fair, but the experiment was aimed at the wrong target.

Coding by voice works well. It just does not mean what people first assume. The win is not in dictating syntax. It is in everything around the syntax — the prose, the thinking, the conversations — which turns out to be a large and growing part of a modern developer's day.

What voice is genuinely good for

Spend an honest hour watching what you actually type. A surprising fraction of it is not code at all. It is language about code.

Prompts to AI assistants. Whether you use an editor with a built-in chat or a terminal agent, you are writing paragraphs of natural language describing what you want. This is prose. Voice handles it beautifully.
Commit messages. "Fix the race condition in the upload queue by draining pending writes before the connection closes" is a sentence. You can say it faster than you can type it, and you will probably explain it better.
Pull request descriptions. The summary, the context, the "why," the testing notes — all prose, often skipped or written badly because typing it feels like a chore.
Code review comments. "This works, but it will allocate on every iteration — consider hoisting the buffer out of the loop." Spoken in five seconds.
Inline comments and docstrings. The explanation of a tricky block, the note to your future self.
Design notes and tickets. The thinking that happens before any code exists.

What these have in common is that they are sentences, not symbols. They have no brackets, no camelCase, no significant whitespace. They are exactly the kind of text humans have been speaking for a very long time.

What voice is not good for

Be plain about this so you do not waste time. Dictating raw source code, character by character, is a bad idea. Programming languages are dense with punctuation that has no natural spoken form. Saying "underscore" between every word, spelling out operators, correcting a misheard variable name — it is slower and far more annoying than typing.

There are specialized tools that try to make literal code dictation work, with custom grammars and spoken commands for every symbol. They exist, and a few people rely on them, often for accessibility reasons. But for most developers, the better mental model is simpler: type the code, speak the language. Your hands stay on the keyboard for the syntax. Your voice handles the paragraphs.

This division is not a limitation you tolerate. It is the natural seam. Once you stop fighting it, voice stops being frustrating.

How to begin

The mistake is to start with the hardest case. Do not open an empty file and try to narrate a class into existence. Start where the payoff is immediate and the friction is near zero.

Begin with AI prompts. This is the easiest win. The next time you are about to type a request to an AI assistant, say it instead. Prompts are conversational by nature, and you already know how to talk through a problem. You will likely find your spoken prompt is longer and more complete than the one you would have typed — which usually means a better answer.
Move to commit messages. After your next change, dictate the commit message instead of typing a terse five-word summary. Say the full sentence. You will write better history almost by accident.
Then PR descriptions and review comments. These are the places where typing fatigue makes developers cut corners. Voice removes the cost, so you actually write the context.
Leave the code itself alone. Keep typing it. That is not a defeat. That is the workflow working as intended.

Within a few days you stop thinking about which mode you are in. Your hands do symbols, your voice does sentences, and you switch between them without noticing — the same way you already switch between mouse and keyboard.

Why a system-wide tool fits this

The work above is scattered across many applications. The prompt is in your editor's chat panel or a terminal. The commit message might be in the terminal, or a Git client, or your editor's source control view. The PR description is in a browser. Review comments are in the browser too. Design notes might be in a notes app or a ticketing tool.

If voice only worked in one of those places, you would constantly be switching tools and breaking your own flow. What you want is dictation that behaves like part of the operating system — available wherever a cursor is blinking, with no per-app setup and no thinking about whether "this app is supported."

That is the model Lispr follows. It is a small macOS app that lives in the menu bar with no window of its own. You hold the right Option key, speak, and release; the recognized text appears at your cursor in whatever app currently has focus — editor, terminal, browser, chat. It does not have special integrations with any particular tool. It just types where you are typing, like any other input. The round trip takes around 200 milliseconds, audio goes over an encrypted connection to be transcribed and is then discarded, and there is no account to set up.

That universality is what makes the "speak the prose, type the code" workflow practical. The seam between voice and keyboard only disappears if voice is available everywhere the keyboard is.

A realistic first week

Day one, you will overthink it and feel a little self-conscious talking to your computer. Day two, you dictate a few prompts and notice they came out clearer than usual. By day three or four, the commit messages and PR descriptions start to flow, and you realize you have stopped writing one-line commits. By the end of the week, the only conscious decision left is the obvious one: code gets typed, English gets spoken.

That is what "coding by voice" actually means. Not narrating syntax — speaking the large, underrated layer of human language that surrounds the code. If you start there, it works on the first day.

If you want to try it, Lispr is free in early access and macOS-only. You might also like our piece on why voice changes the prompts you write.