Guides
Dictating in VS Code: around the code, not in it
VS Code is a text editor full of text fields, so dictation works everywhere in it. The useful question is which of those fields you should actually speak into.
Last updated
Resolve the keybinding first
VS Code has the densest default keymap of any app most developers run, and a dictation shortcut that collides with something will make you conclude, wrongly, that dictation is unreliable.
- Pick a candidate shortcut A right-hand modifier, or a function key. Avoid anything with Cmd.
- Press it in VS Code with a file open If something happens, it is taken. Try the next one.
- Check it in the terminal panel too The integrated terminal passes many keys through to the shell, so a shortcut can be free in the editor and taken in the terminal.
- Then set it in the dictation app And restart VS Code once, so nothing is holding a stale registration.
The three places it pays
1. Copilot Chat and inline chat
The highest-value target. A chat prompt is prose, and longer prompts with real constraints produce better output. Typing discourages length; speaking does not.
Click into the chat input, hold, speak the whole request including what to avoid and why, release, read, send.
2. Commit messages
The Source Control panel's message box is an ordinary text field. A dictated commit message tends to explain why, because explaining out loud is natural and typing it is not. Six months later that is the difference between a useful history and a list of "fix".
Dictate the body; type the conventional-commit prefix by hand, because feat: and fix: are not things speech handles gracefully.
3. Documentation and comments
READMEs, architecture notes, the comment above the function that does something surprising. All prose, all things that get skipped because typing them competes with writing code.
Where not to dictate
| Place | Why not |
|---|---|
| The integrated terminal | A misheard word becomes a command. Dictate into the editor, read it, then run it |
| Code itself | Symbol density. Slower than typing and always will be |
| The command palette | It filters as you type; synthetic input and fuzzy matching interact badly |
| Find and replace | Regular expressions are not speech |
| Vim normal mode | Your words become commands. This one is memorable |
Teach it your stack
A general speech model has heard of almost nothing in a developer's vocabulary. Kubernetes, nginx, Postgres, Kafka, OAuth, your service names, your team's names — all rare in ordinary English and all mangled by default.
Twenty vocabulary entries covers most of a career's daily corrections. Add them as they come up for a week, then stop thinking about it. See building a dictation vocabulary.
Snippets in Vaitly Voice A spoken trigger that expands to your PR template or your standard review comment.A realistic day
- Morning: dictate three Copilot prompts about the feature you are starting. Each sixty words rather than nine.
- Mid-morning: type the code. Dictation is not involved and should not be.
- Before lunch: dictate the commit message and the PR description.
- Afternoon: dictate four review comments on a colleague's branch, each explaining the reasoning.
- End of day: dictate two paragraphs into the architecture note you have been avoiding for a fortnight.
None of that is code. All of it is writing, and it is most of the text a senior engineer produces in a day.
Questions
Do I need a VS Code extension to dictate?
No. A system-wide Mac dictation app types into VS Code the same way a keyboard does. There is nothing to install in the editor and nothing to update when it changes.
Does dictation work in the VS Code terminal?
Technically yes, and you should not use it there. A misrecognised word becomes a shell command. Dictate into the editor, read it, then run it.
Will it work with Vim mode?
Yes, in insert mode. In normal mode the inserted text is interpreted as commands, which is a fast way to make an unwanted mess. Be in insert mode before you press the shortcut.
Can I dictate into the Copilot Chat box?
Yes, and it is the single most useful place to do it. Longer prompts with explicit constraints produce noticeably better output, and speaking removes the reason you were writing short ones.