How to Dictate Code Comments Without Breaking Your Flow

Ask a developer why a function exists and they will explain it clearly in thirty seconds. Ask them to write that explanation as a comment and it will either never appear or arrive as a three-word placeholder. The problem is not knowledge or intention. The problem is that switching from code to prose, typing out a full sentence, breaks the rhythm of the work.

Voice capture changes the economics of documentation.

Why Developers Skip Comments

Documentation debt is not laziness. It is a friction problem. When you are deep in a problem, your working memory is loaded. Stopping to type a paragraph-long explanation costs attention you cannot spare. So you write "// handles edge case" and tell yourself you will flesh it out later. You never do.

The same applies to commit messages, README sections, internal wiki entries, and code review notes. Any prose that lives adjacent to code tends to be thin because typing it costs too much in the moment and feels low-priority later.

If you could speak a comment as fast as you could think it, the calculation changes.

What Dictating Comments Actually Looks Like

The workflow is simple. You finish writing a function, press the dictation key, and say what you would say to a colleague standing next to you. "This checks whether the session token is expired before making the API call. If it is expired, it triggers a refresh. The retry count is capped at three to avoid infinite loops."

That took about eight seconds to say. Typed, it would take closer to forty, and most developers would not bother. Spoken, it just happens.

VoiceInk places the transcription wherever your cursor sits, so you can stay in your editor. Press the shortcut, speak, release. The comment is there. You move on.

Handling Technical Language

The common worry is accuracy with technical terms: function names, library names, acronyms, domain-specific jargon. Modern local transcription handles most of this well because it uses large language models that have seen substantial amounts of technical text.

For the cases where it stumbles on a specific term, the fix is fast. You are not re-dictating a paragraph. You are correcting one word. The overall time cost is still far below typing the comment from scratch.

A practical tip: dictate the intent and shape of the comment, then do a single pass to fix names and symbols. The split between speaking and editing is cleaner than trying to dictate with perfect precision.

Beyond Comments: Other Places Voice Helps Developers

Comments are the obvious case, but they are not the only one.

Commit messages are a natural fit. A spoken commit message takes a few seconds and tends to be more descriptive than something typed in a hurry at the end of the day. "Fixed the race condition in the auth middleware that was causing intermittent 401s under high load" is the kind of message you say easily but rarely type.

Technical notes during debugging are another good use. When you are tracing a hard bug, keeping a spoken log of what you tried and what you found is faster than switching to a notes app and typing. You speak, the note appears, you go back to the terminal.

PR descriptions, meeting notes after a technical discussion, and rough documentation drafts all benefit from the same approach. Any time you are translating thought into prose, speaking is faster than typing.

The Shift in Habit

The goal is not to eliminate typing. Keyboards are the right tool for code. The goal is to stop using keyboards for the prose work that sits around the code, where typing is slow and voice is fast.

Documentation gets written when writing it takes less effort than skipping it. Voice gets you closer to that threshold. If you want to test this, pick a project with thin comments and spend one session dictating your way through it. The difference in time is noticeable. The difference in completeness tends to be striking.