Dictating Code Comments and Commit Messages: A Practical Hands-Free Setup

I do not want to dictate code. Brackets, indentation, and symbol-heavy syntax are a bad fit for speech, and autocomplete already does a lot of that work.

The prose around code is a different story. Comments that explain why, commit messages that someone will read during a painful git bisect, PR descriptions, review replies. That text is often the part we rush, because typing a careful paragraph after an hour of debugging feels like a chore. Saying it out loud is easier, and it usually comes out clearer.

Here is how I set that up with InsertKit, a desktop app (Windows, macOS, Linux) that combines voice typing, text snippets, and clipboard history.

The basic loop

1. Put your cursor where the text should go: a comment line, the commit message buffer, a PR description box.
2. Press the voice shortcut (Right Alt by default) and talk.
3. Stop talking. After a short silence (5 seconds by default, configurable), recording stops and the text is inserted at the cursor.

It works system-wide, so the same shortcut works in your editor, a terminal, the browser, or a chat app. Long explanations are fine too: speech is split into chunks at natural pauses and processed while you keep talking.

Let the Code profile handle formatting

Raw transcripts are messy. With Smart Formatting turned on, InsertKit cleans filler words and punctuation and adapts the style to the app in focus. When the active window is VS Code, Cursor, IntelliJ, Sublime, vim, or a terminal, it uses the Code profile.

Two things happen in that profile:

• Output reads like a comment or docstring, not a chatty paragraph.
• Spoken identifiers become camelCase or snake_case. Say "this wraps fetch user profile and retries on a timeout" and you get a comment that refers to fetchUserProfile instead of four loose words.

It will not always guess the convention you want, so glance at identifiers before you move on. If you want a specific house style, there is a Use my own instructions option for a custom formatting prompt. Keep in mind it changes formatting generally, not only in your editor.

If the formatter is unreachable, the raw transcript is pasted anyway, so nothing you said gets lost.

Snippets for the boilerplate around the prose

Voice handles the thinking. Snippets handle the structure that should look the same every time. A few I use:

/todo for a TODO tag with my name and today's date, using built-in variables:

TODO({{myName}}, {{date}}): 

Type /todo, then press the voice shortcut and say what needs doing.

/pr for a PR description skeleton:

## What changed

## Why

## How to test

## Notes for reviewers

Drop it in, then dictate each section. "Why" is where speaking pays off most.

/commit as a dynamic snippet. On desktop, a snippet can have form fields. I use a Dropdown called type (feat, fix, refactor, docs, chore, test) and a Text field called scope:

{{type}}({{scope}}): 

Type /commit in the commit buffer, pick the type, enter the scope, press Enter, then dictate the subject and body.

If you forget a trigger, typing / opens a small autocomplete popup at the cursor with matching snippets.

Press F4 before snippets bite you

Here is the gotcha nobody mentions. Snippets fire the moment the end of what you typed matches a trigger, without waiting for Space. That is great in a chat box and dangerous in code. If you have a /pr snippet and you type a path like /proc/... or a URL segment starting with /pr, it will expand.

Two fixes:

• Pick triggers that rarely appear in code or paths. /prdesc is safer than /pr.
• Press F4 (Fn + F4 on Mac) to turn the whole snippet system off while you are writing code, and press it again when you switch to prose. A small toast confirms "Snippets disabled" or "Snippets enabled". You can change the key in Settings.

Some apps also use / for their own commands. Under Settings → Snippets → Trigger Prefixes, you can enable a different prefix character for those cases.

Teach it your jargon

Speech engines are trained on everyday speech, not on your stack. Custom Vocabulary fixes that in two ways:

• Add word: hint terms like Kubernetes, PostgreSQL, gRPC, or your internal service names.
• Add correction: "When heard as" → "Write as". For example "post gres" → "Postgres", "next js" → "Next.js", or "k eights" → "k8s".

Corrections run before and after AI formatting, so the formatter cannot "fix" your spelling back. Vocabulary syncs to your account, so it follows you to another machine.

Picking an engine: hosted, BYOK, or fully local

You can start with InsertKit Free, which needs no API key and has a daily limit. For more control there are a few options worth knowing.

Bring your own key. Settings → API Keys accepts keys for providers such as OpenAI, Groq, OpenRouter, Deepgram, AssemblyAI, and ElevenLabs for transcription, plus chat providers for formatting. Adding a key assigns sensible defaults. A Groq key, for example, sets whisper-large-v3 for speech.

Local Offline (Whisper). On desktop you can download a Whisper model inside the app, from Tiny (~75 MB) up to Large v3 (~3 GB). With this engine selected, audio is transcribed on your machine and does not leave it. Start with Small or Base on a laptop and move up if accuracy is not good enough for your accent and vocabulary.

Custom OpenAI-compatible endpoint. Formatting uses a chat model, and by default that may be a cloud model. If you want the text to stay local too, add a custom provider pointing at a local server such as Ollama or LM Studio: set a name, the base URL, a key if needed, and fetch or enter the model list. Pair that with Local Offline Whisper and the whole pipeline runs on your machine.

If your team has rules about what can leave your machine, that is the setup to look at. Or turn Smart Formatting off and rely on vocabulary corrections alone.

Linux notes

On Linux, check Settings → General → Linux Dependencies. InsertKit relies on tools such as xdotool, wtype, and maim to type and paste. On Wayland, the tips point to wtype or ydotool.

A couple of extras

• Voice Assistant: say "hey ik draft a short changelog entry for a fix to session expiry handling" and a draft is typed at the cursor. Treat it like a junior's first draft.
• Clipboard history: Ctrl + Shift + Z opens a small popup with recent copies, snippets, and favorites. Handy for juggling an error message, a ticket ID, and a stack trace line while writing a commit.

What does not work well

• Open-plan offices. Dictation is awkward with people around.
• Dictating code itself. Stick to prose.
• Skipping review. Read every comment before you commit it.

If you want to try this workflow, the desktop builds are at insertkit.com/download. My suggestion: set up /todo, /commit, and a few vocabulary corrections, then dictate every commit body for a week and see if your history reads better.