The Myth of Voice Coding
When developers hear "voice coding," most picture someone dictating Python syntax out loud: "def space calculate underscore total open paren items close paren colon..." That is not voice coding. That is torture.
Real voice coding is not about replacing keyboard input for syntax. It is about using your voice for the large portion of software development that is natural language: documentation, comments, commit messages, PR descriptions, task breakdowns, Slack updates, and code reviews.
The ratio of natural language to syntax in most development work is higher than most developers realize. A thorough developer might spend:
- 20% writing code
- 30% writing documentation and comments
- 15% writing issue descriptions and PR content
- 20% in Slack, email, and meetings
- 15% on code review and planning
That is 80% of work where voice input is either faster than typing or equally effective. The 20% that is actual syntax stays on the keyboard.
What to Dictate as a Developer
Code Comments
Comments are pure natural language. Writing a clear comment explaining why a function exists, what edge cases it handles, or what the caller should know is easier to speak than type.
The workflow: Navigate to the comment location in your editor, press the hotkey, speak the explanation, release. The Clean mode removes fillers and produces clean prose.
Example: Press hotkey, speak "this function handles the edge case where the user token is expired but the refresh token is still valid, it attempts one refresh and then forces a logout if that fails too, the caller should handle the AuthenticationError," release. The comment appears formatted and clean.
Documentation and README
README files, API documentation, and inline JSDoc/docstring comments are exactly where voice input excels. You are writing for a human reader in natural prose — the same thing you would say if someone asked you to explain the code.
Speaking a function's documentation while looking at the code produces better documentation than typing it. You describe what you see naturally, without the friction of translating thought to keystrokes.
Commit Messages
Good commit messages are short prose: what changed and why. Speaking a commit message is faster than typing one, and the Clean mode ensures it reads well.
Pull Request Descriptions
PR descriptions — problem, solution, test plan, reviewer notes — are exactly the kind of structured content that Telvr's enrichment modes handle well. The Dev Task mode produces this structure natively.
Example: Press hotkey, switch to Dev Task mode, speak "fixed the race condition in the payment processing flow, the issue was two concurrent requests could both check the balance before either deducted it, added a database-level row lock around the transaction, added a test that spawns two concurrent payment attempts," release. The result is a structured PR description with problem, solution, and testing notes.
Issue and Ticket Descriptions
Writing a detailed bug report or feature spec by typing is tedious. Speaking it naturally while looking at the issue is faster and often produces more thorough descriptions because you are not fighting the mechanical overhead of typing.
Slack and Team Updates
Progress updates, blockers, standup summaries — these are conversational by nature. "I finished the auth refactor yesterday, today I'm working on the payment integration, blocked on getting test credentials for the sandbox environment, will ask Sarah." That is a complete standup in 15 seconds of speech.
Setting Up for Developer Workflows
Hotkey Configuration
The default Telvr hotkey (Option + Space on Mac) works well for developers because it does not conflict with most IDE shortcuts. If you prefer something else, the hotkey is configurable.
Recommended setup for developers:
- Keep hands on the home row
- Use a two-key combination to prevent accidental activation while in terminal
- Avoid hotkeys that conflict with your IDE (check VS Code or JetBrains keymaps)
Mode Selection
For developer workflows:
- Clean mode: General comments, prose documentation, Slack messages
- Dev Task mode: PR descriptions, issue specs, technical requirement summaries
- Meeting Notes mode: Post-sprint retrospective notes, design discussion summaries
- Email mode: Client-facing technical communication, status updates to non-technical stakeholders
IDE Integration
Telvr uses system-wide text insertion, which means it works in any text field in any application. This includes:
- VS Code (code editor, integrated terminal, search, comments)
- JetBrains IDEs (IntelliJ, WebStorm, PyCharm)
- Zed, Neovim (when in insert mode)
- Linear, Jira, GitHub (in browser)
- Terminal (when entering non-command text like git commit messages)
There is no plugin to install. Any editable text field is fair game.
Real-World Developer Workflow
Here is what a development session with voice input looks like in practice:
Morning standup in Slack: Press hotkey, speak yesterday's progress + today's plan + blockers, release. Done in 20 seconds.
Writing code: Keyboard. Normal development workflow.
Adding a comment to a complex function: Navigate to the right line, press hotkey, speak explanation naturally, release.
Creating a GitHub issue for a bug: Open new issue, press hotkey with Dev Task mode, describe the bug and reproduction steps, release. Title the issue, submit.
Writing a commit message:
git commit in terminal, press hotkey in the editor that opens (or pipe to a file), speak the commit description, release.
Writing a PR description: Open PR form, press hotkey with Dev Task mode, explain what the PR does and why, release. Add reviewer notes if needed.
Answering a technical question in Slack: Press hotkey, explain the technical decision or concept out loud, release. Clean mode produces a readable explanation without having to type carefully.
The Productivity Reality
The biggest gains from voice input in development come not from raw speed but from friction reduction. Documentation is often deferred or skipped entirely because typing it feels like overhead on top of the actual work of coding. When writing a comment or docstring takes 15 seconds of speaking rather than 2 minutes of carefully typing, the threshold for adding it drops significantly.
Better-documented code, more complete PR descriptions, and more thorough issue reports are often the practical outcome of developer voice input — not just faster execution of the same habits.
One Week to a New Habit
Getting voice input into your development workflow:
Day 1: Use voice only for Slack messages. Nothing else.
Day 3: Add commit messages. Speak the description into the terminal editor.
Day 5: Add inline comments. Start narrating complex functions as you finish writing them.
Day 7: Add PR descriptions with Dev Task mode. Notice that you write more complete descriptions than before because speaking is faster than typing.
After two weeks, the habits are established and voice input feels natural rather than effortful.