Dictate Code Comments and Commit Messages

By Typilot Team

You can dictate git commit messages, code comments, PR descriptions, and documentation into any application using a local Whisper-based tool - no audio upload, no API key, fully offline. A thorough commit message that takes 40-60 seconds to type takes 8-12 seconds to dictate. On a local Whisper model, developer prose transcribes at around 3-5% word error rate on clean audio - accurate enough for daily use without a keyboard correction pass after every phrase.

Here is the full workflow: what to dictate, how to route it into VS Code and the terminal, and where the voice path saves the most time.

What developer writing gains most from voice

Documentation, commit messages, PR descriptions, and code review comments account for 30-40% of a developer's writing time (Source: developer dictation workflow research, aidictation.com). These are natural-language prose tasks - exactly where voice is 2-3x faster than typing. The code-vocabulary problem - camelCase identifiers, package names, operator sequences - is real but affects a different category of text than commit messages or documentation.

Good candidates for voice

• Commit messages, especially multiline ones (subject, body, Closes #123)
• Code comments and docstrings that explain intent rather than identifiers
• PR descriptions and GitHub review comments
• Slack threads, issue descriptions, and ticket comments
• README and documentation prose

Keep on the keyboard

• Variable names, function names, and camelCase identifiers
• Shell commands in an active terminal prompt - a misrecognised character in rm -rf or a piped redirect can be destructive. Dictate only into text fields, not into the live shell.
• Inline code: package names, import paths, language keywords

Commit message workflow

In VS Code

Open the Source Control panel (Ctrl+Shift+G / Cmd+Shift+G), click into the commit message field, and activate your dictation tool. A one-liner takes about 5 seconds. For a multiline commit:

1. Dictate the subject line.
2. Press Enter to start a new paragraph.
3. Dictate the body - "explains why the retry interval was increased from five seconds to thirty" lands cleanly as prose.
4. Press Enter twice, then dictate Closes # followed by the issue number.

Text lands directly at the cursor via the OS accessibility layer - no copy-paste step.

In the terminal

Do not dictate into an active shell prompt. The safe path is to open a second text field (a scratch note, a VS Code editor tab, or a GUI commit dialog), dictate there, then paste:

git commit -m "refactor: move session timeout to config"

Or commit with the editor flag and dictate into the opened file:

git commit  # opens $EDITOR - dictate in the editor window

The git commit -F <file> pattern also works if you prefer to dictate into a plain-text scratch file first.

Code comments and docstrings

For comments that explain why rather than what, voice is especially natural. "This retry logic exists because the upstream service returns 429 after three rapid requests" is faster to speak than to type and produces no identifier-accuracy issues. The output lands as a standard code comment because the tool injects plain text at the cursor.

For docstrings, dictate the description and parameter intent verbally:

def calculate_retry_delay(attempt: int) -> float:
    # Exponential backoff: wait 2^attempt seconds, capped at 60.
    # Used by the job queue on transient failures only.
    return min(2 ** attempt, 60)

Dictating that comment block takes around 10-12 seconds versus 25-30 seconds to type. Long docstrings with parameter lists are one of the biggest per-word gains.

Time comparison

A thorough commit message (subject line, body, and issue reference) takes 40-60 seconds to type and 8-12 seconds to dictate - roughly a 5x reduction. Across all developer prose, voice is consistently 2-3x faster than typing, saving an estimated 1-2 hours per week for developers who write documentation and reviews regularly.

Local vs cloud for developer code

The privacy question for developer dictation is specific: code context, architectural decisions in PR descriptions, and variable names in docstrings should not reach vendor servers under most NDAs and compliance regimes.

Developer dictation tools

VS Code ships a built-in VS Code Speech extension (launched with VS Code 1.87 in February 2024) that runs a local model, but it works only inside VS Code - it does not reach the terminal, browser, or Slack. System-wide tools like Typilot, OpenWhispr, and HyperVoice inject text at the cursor in any running application via the OS accessibility layer.

For AI-assisted cleanup on top of dictation, Typilot routes commands to a local Ollama model with no cloud call. A useful pair: hold to dictate a rough explanation, then press imp: (improve) or rew: (rewrite) to clean it up before it lands in the commit field. The gen: command with a voice prompt also works for boilerplate docstrings - speak the parameter names and intent, get a structured block back. See Wispr Flow vs Typilot for a full side-by-side of cloud vs local developer dictation.

The short version

Voice saves the most time on developer prose that is already natural language: commit messages, code comments that explain decisions, PR descriptions, and review threads. A full commit takes 8-12 seconds to dictate versus 40-60 seconds to type. The practical rule: dictate text fields, keep identifiers and live shell commands on the keyboard.

For a local setup with no audio upload, Typilot ships a 3-day free trial with hold-to-record, toggle-VAD, and toggle-manual modes on Mac, Windows, and Linux. The security page documents the full on-device pipeline, and /features covers the AI command layer that turns dictation into an editing workflow. For connecting a local AI model for post-dictation cleanup, see the Ollama setup guide and the run a local AI assistant with Ollama walkthrough.