Can you actually write code by voice?

Yes, and almost nobody should make it their default. Talon Voice does it properly with a grammar built for the job, at the cost of real setup and a learning curve; it is the right answer if using a keyboard is not an option for you. With an ordinary dictation app, code by voice is slower than typing for most people, while the prose around the code is much faster.

How do I dictate a variable name?

Use a spoken casing command: "camel case user auth service" gives userAuthService, "snake case user auth service" gives user_auth_service. In Flit these are fixed rules rather than model judgment, so the same phrase always produces the same identifier.

How do I dictate a command with flags?

Say the symbols. "git rebase dash dash onto main" gives git rebase --onto main, because "dash" binds to the word after it. The other half of the answer is that your dictation tool must be verbatim in the terminal, or it will capitalize the command and add a period.

What is the best way to dictate a file path?

Spoken symbols with correct spacing: "tilde slash projects slash flit" gives ~/projects/flit. This only works if the tool binds each symbol to the right side; a tool that treats symbols as words gives you "~ / projects / flit".

Should I dictate commit messages?

This is the single best use of dictation for a developer. Commit messages and pull request descriptions are prose, they are written constantly, and they are usually shorter and worse than they should be precisely because typing them is friction. Speaking them tends to make them better as well as faster.

Does dictating code work in VS Code and Cursor?

It depends on the tool's insertion method, because both are Electron apps and reject approaches that work in native apps. Test it on day one of any trial by dictating into the editor and into an integrated terminal, which are two different code paths and can fail separately.

How to dictate code: a working setup

A practical guide to dictating in a developer's day: what voice is genuinely good at, the spoken commands for symbols and casing, terminal safety, and the parts that are still a bad idea.

There are two different questions hiding behind “dictating code,” and conflating them is why most advice on this is useless.

The first is: can I control my computer and write code without a keyboard? That is a real need, usually driven by RSI or another condition, and it has a real answer, which is Talon Voice. It is free, local, scriptable, and built for exactly that. It also takes genuine investment to learn. If this is your question, stop reading here and go there; nothing else in this article substitutes.

The second is: I have a working keyboard, and I type an enormous amount of text that is not code. Can voice help? That question is under-served, the answer is yes, and it is what the rest of this guide is about.

Start from what you actually type

Look at a normal day. The code is the visible part, and it is not most of the text you produce.

Commit messages
Pull request descriptions
Code review comments
Slack and issue threads explaining decisions
Documentation and READMEs
Incident notes and postmortems
Replies to whoever asked why the build is red

All of that is prose, and prose is what dictation is genuinely 3 to 4 times faster at. It is also, not coincidentally, the writing developers most reliably do badly, because typing it competes with the work it describes. A commit message you speak in twelve seconds tends to be better than one you type in twelve seconds.

The setup that works: dictate the prose, type the code. Everything below is about making that split painless, plus the narrower cases where dictating code itself does pay.

The three things your tool must do

Prose full of identifiers is not ordinary prose, which is why general dictation tools feel wrong in a terminal or an editor.

1. Verbatim in terminals and editors

A dictation tool that helpfully capitalizes the first word, converts straight quotes to curly ones, and adds a closing period will destroy every command you speak. In a terminal you need the words exactly as said, and nothing else.

Flit switches to verbatim automatically when the focused app is a terminal or code editor, with no mode to remember. Test this on day one of any trial you run, using a command with quotes and a double dash, because it is the failure that shows up fastest:

git commit -m "fix: handle empty --input"

If what lands is Git commit -m "Fix: handle empty. Input." then the tool is not for this job, regardless of what its feature list says.

2. Spoken symbols with correct spacing

Saying a symbol’s name has to produce the symbol, attached to the right side. This is the part almost nobody documents, and it decides whether dictated paths and flags are usable.

You say	You get	Why
`dash dash force`	`--force`	“dash” binds to the word after it
`tilde slash projects`	`~/projects`	“tilde” binds right, “slash” binds both
`name at sign gmail dot com`	`name@gmail.com`	“at sign” and “dot” bind both sides
`open brace close brace`	`{}`	openers bind right, closers bind left

A tool that inserts symbols as if they were words gives you ~ / projects and name @ gmail . com, which you then fix by hand, which is slower than typing it was. The full command reference lists every one and which way it binds.

3. Symbol names it can actually spell

Speech models have never seen your repository. “User auth service” becomes whatever English spelling is most probable, not the file that exists. Two ways to fix this: a personal dictionary you build as you go, or a tool that indexes your open project locally and resolves spoken names against it. Flit does the second; most tools do neither.

The commands worth learning first

You do not need all sixty. Five carry most of the value.

camel case … turns the rest into likeThis. Say “camel case user auth service” and you get userAuthService.
snake case … gives user_auth_service.
all caps on … all caps off for constants and env vars.
dash dash for flags, because it binds rightward.
literally … for the moment you need to write the word “comma” in a sentence about punctuation, which happens more than you expect in documentation.

In Flit these are fixed rules rather than model judgment, which is the property that makes them usable: the same phrase produces the same identifier every time, so you stop checking.

Where dictating code genuinely pays

Narrower than the marketing suggests, and real:

Long string literals. Error messages, user-facing copy, SQL, and regex descriptions in comments. This is prose that happens to live inside quotes.
Comments and docstrings. The thing you skip because typing it interrupts the code you are holding in your head.
Test names. it("returns an empty array when the input is undefined") is a sentence.
Boilerplate you can describe faster than you can type, especially with an AI editor: dictating a paragraph of intent into Cursor or a chat panel is much faster than typing it, and it is prose.

That last case has quietly become the biggest one. AI editors moved a large share of a developer’s input from code to natural-language instructions, and natural language is exactly what voice is fast at.

Where it does not work

Stating this plainly, because guides that do not are wasting your time.

Dense syntax by voice is slower than typing it. Nested generics, chained calls, and anything with a lot of brackets. Your fingers know this; your voice does not.
Editing existing code by voice. Navigation and precise selection are keyboard and mouse work. Talon solves this with a grammar built for it; a dictation app does not.
Anywhere you cannot speak freely. Open-plan offices and shared spaces are the real limit on all of this, and no software fixes it.
Anything where you are still thinking. Dictation is fast at transcribing a formed thought and no help at all in forming one.

A first week that actually sticks

Day one: bind the key under a thumb. Not a finger you type with.
Day one: test the terminal, with the quotes-and-flags command above.
Day one: test your editor and its integrated terminal separately. Electron apps like VS Code and Cursor take a different insertion path from native apps, and can fail independently.
Days two to five: dictate only commit messages and PR descriptions. One narrow habit, formed properly, beats trying everything and giving up.
All week: add every misheard symbol name to the dictionary the moment it is wrong.
Week two: add review comments and Slack. By now the hotkey is automatic and this costs nothing.
Week three: decide about code itself, from evidence rather than from an article.

For which tool to run this with, see the best speech-to-text for developers, and for the complete list of spoken commands, the reference page. If you are here because typing hurts, Talon Voice and the hands-free page are the more important reads.

How to dictate code: a working setup, and what does not work