Dictating Code Comments and Docs Without Losing Your Flow

Developers tend to dismiss voice dictation quickly. The assumption is that code cannot be dictated, so voice has no place in the workflow. That assumption is mostly right about code itself, but it misses the bigger picture. A working developer writes a lot more prose than they often realize.

Readme files. Pull request descriptions. Inline comments. Slack messages explaining why a build broke. Tickets, postmortems, architecture notes, onboarding docs. That is a lot of words, and most of it is being typed one keystroke at a time when it does not have to be.

Where Voice Fits in a Dev Workflow

The highest-value place to start is inline documentation. Writing a function comment is exactly the kind of task where the bottleneck is not thinking, it is transcription. You already know what the function does. You just have to describe it. Speaking that description takes 15 seconds. Typing it, with the usual pausing and self-editing, takes two minutes.

Multiply that across a codebase and the time savings become meaningful fast.

Pull request descriptions are another obvious target. A good PR description explains what changed, why it changed, and what a reviewer should pay attention to. Most developers write mediocre PR descriptions not because they do not care but because writing them by hand feels like overhead after already solving the actual problem. Dictating a PR description takes about the same mental effort as explaining your change to a colleague out loud, which you were probably going to do anyway.

Practical Setup

You do not need anything complicated. A tool like VoiceInk sits at the OS level on your Mac, so it works wherever your cursor is. That means you can be in VS Code, in your browser, in a Notion doc, and the dictation lands exactly where you need it without switching contexts.

For technical prose, modern dictation handles plain language well. You will occasionally need to correct a word, but the correction cost is lower than the cost of typing the whole thing. The break-even point is usually around two sentences.

For anything requiring specific syntax or variable names, keep typing. Voice and keyboard are not competing. They cover different parts of the job.

Capturing Ideas Without Stopping

One underrated use case is hands-off note capture while you are thinking. When you are deep in a problem and a side thought comes up, typing a note breaks your concentration. Speaking it into a quick scratch pad does not.

Some developers keep a plain text file open specifically for this. Dictate the thought, keep working, process the notes later. It is a low-friction way to avoid losing ideas without interrupting the focus state you worked to get into.

The Repetitive Strain Factor

Developers are one of the highest-risk groups for repetitive strain injuries. Eight or more hours a day at a keyboard, often with poor posture and tight deadlines that push through discomfort. RSI is not a fringe concern in this profession, it is an occupational hazard.

Reducing keyboard time for prose tasks is one of the more concrete things you can do before symptoms appear. Once you have wrist pain, every hour of typing is a tradeoff. Better to build the dictation habit before you need it as a workaround.

Start with One Task

If you want to try this without changing your whole workflow, pick one category of writing you do regularly and dictate only that for two weeks. PR descriptions work well. So do daily standup notes or end-of-day summaries.

The goal is to build the habit on low-stakes output first. Once it becomes automatic for simple prose, you will start noticing other places where speaking is faster than typing.

Voice will not write your code. But it can handle a surprising amount of everything else that surrounds your code, and that is worth at least one honest experiment.