Most developer dictation demos are nonsense because they fetishize symbols and syntax. The real win is prose. Software work is full of explanatory writing, and a lot of it is exactly the kind of structured drafting where voice helps.
Where dictation actually helps
Good use of voice
- •Pull request descriptions, review summaries, and release notes
- •Bug reports, issue templates, and acceptance criteria
- •Design notes, architecture comments, and planning docs
- •Prompting tools like Cursor, ChatGPT, or internal assistants
Bad use of voice
- •Raw code entry full of symbols and exact punctuation
- •Fast line-by-line refactors where the keyboard is still the right tool
- •Terminal commands or shell one-liners where one wrong character ruins the point
Why this maps to real developer work
GitHub’s own docs are a reminder that software teams increasingly work through structured issues, pull request templates, and tracked planning artifacts. That means developers spend more time writing context, rationale, and coordination text than they like to admit.
Dictation helps when the job is “explain the change clearly” or “capture the problem while it is still in my head.” It does not need to replace the keyboard everywhere to earn its place.
A practical workflow
- Use voice for the first draft of prose, not for the final exact edit.
- Keep one hotkey across apps so the workflow feels the same in GitHub, Linear, Slack, and your editor.
- Use the keyboard to tighten wording, adjust structure, and fix code-adjacent details after the draft lands.
Internal guides worth opening
- Dictation in Cursor for prompts, plans, and review notes.
- Dictation in GitHub Issues for bug reports and structured issue writing.
- Dictation in GitHub pull requests for summaries, risk notes, and reviewer context.
- Dictation in Linear for issue creation and planning work.