Talk to your editor without the code leaving your Mac.

Last updated 7 September 2026

What voice coding is good for

The honest version of "voice coding" in 2026 is voice around code. Agents and chat panels have turned a lot of programming into explaining what you want in plain sentences, and plain sentences are what dictation is built for.

• Prompting Cursor, Claude Code and Copilot chat. A good prompt is two or three paragraphs of context. Saying it takes a fraction of the time, and you tend to give the agent more of the why when you are talking.
• Commit messages. Hold, say what changed and why, release, tidy the first line. Works in the terminal, in the editor's commit box and in the GitHub Desktop field.
• PR descriptions and review comments. The paragraph that explains the trade-off is the one nobody writes because it is tedious to type. Dictate it.
• Terminal commands you then check. "git log dash dash oneline dash n twenty" lands as words, which is fine for a command you read before pressing return. Treat it as a draft, not an execution.
• Comments, docstrings, READMEs, issue reports. Anything that is prose sitting inside a repo.

What it is not good for

VV does not understand code syntax. It types the words you say. Dictating raw code means saying every bracket, semicolon and camel-cased identifier out loud and then fixing the spacing, which is slower than typing for anyone who can type. It is not a hands-free programming environment and it does not try to be one. If you need that, tools built around grammar-driven commands are a better fit; VV is for the words, not the tokens.

Vocabulary: identifiers, jargon, product names

A general speech model has never heard of your service names. Vocabulary fixes that one word at a time. Each entry has a spoken form and a written form, so you can say it the way you actually say it:

• "auth service" → AuthService
• "use effect" → useEffect
• "k eight s" → k8s
• "postgres" → PostgreSQL
• "Vaitly" → Vaitly, because your own product name is usually the first casualty

Add a handful when you set up and then add one each time the model gets something wrong. The list is stored locally and the biasing happens on the Mac.

Snippets: boilerplate by trigger

A Snippet is a spoken trigger that expands to a block of text. Developers use them for the things they paste all day:

• "PR template" → the headings your team expects in every pull request description.
• "repro steps" → the skeleton of a bug report: environment, steps, expected, actual.
• "review prompt" → the paragraph you send an agent before every review.
• "licence header" → the comment block that goes at the top of a new file.

Say the trigger mid-sentence and it expands in place. Say it on its own and it is a template you fill in.

Secrets, history and the privacy boundary

Standard dictation is recognised on your Apple Silicon Mac and the text is typed there. No audio and no text is uploaded. VV never sees the file, the repo or the terminal buffer; it only handles the words you say. The first launch downloads the speech model, which is the one time standard dictation needs the internet.

VV keeps a local history of what you dictated, with the audio, under the app's data directory, for the retention period you set in Settings. That is the thing to be careful with. If you dictate an API key, a token or a password, it is now in your history on disk as well as in the field you typed it into. So: do not dictate secrets. Paste them from a password manager, keep the retention period short on a shared or loaner Mac, and delete individual history entries when you need to.

A Transform rewrites the dictation on the way through, and by default it runs on Apple Intelligence or a local Ollama model, so it stays on the Mac. If you configure a cloud provider instead, the text of that dictation is sent to that provider, and only the text. The app labels those Transforms as cloud. Nothing is sent otherwise.

Other limits: Apple Silicon Mac on macOS 14 Sonoma or later; Intel Macs are not supported. Windows is in development and not downloadable yet.

Works in any editor, because it pastes at the cursor

VV types through the macOS input layer, the same path a keyboard uses. That is why there is no Cursor extension, no VS Code plugin and no terminal integration: it does not need one. Click into a chat panel, a commit box, a shell prompt or a GitHub comment, hold the shortcut, speak, release. Your clipboard is restored afterwards, so the thing you copied a minute ago is still there.

Compared with the developer page

This page is the workflow. The developers page is the shorter case for why the recording should stay local when the thing you are describing is your architecture. For the features themselves, see Vocabulary, Snippets and the security page.