Dictating Code Comments: A Developer's Honest Review

Developers are not the obvious audience for voice dictation. Code is precise, syntax matters, and most of what we produce would confuse any transcription engine. But there is a category of developer writing that is almost entirely natural language, and that category is bigger than most people realize.

Documentation. Comments. README files. Pull request descriptions. Slack messages explaining why a build broke at 2am. All of it is English, and all of it is usually written slowly and reluctantly.

Where Voice Actually Helps

Inline code comments are the easiest win. The comment above a function that explains what it does and why, not the how, that comment is usually one or two sentences of plain English. Typing it takes thirty seconds. Speaking it takes five. Over a full day of coding, those small moments add up.

Pull request descriptions are where I noticed the biggest improvement. A good PR description explains context, links decisions to requirements, and flags anything the reviewer should pay attention to. Most developers write three sentences when they should write ten, not because they are lazy but because writing feels like overhead when you just want to merge and move on.

Speaking a PR description feels different. I just talk through what I did and why. The result is consistently longer and more useful than what I would type. Reviewers have noticed, and not in a way that required me to explain myself.

README files and internal documentation follow the same pattern. Anything where the bottleneck is getting words out, not choosing the right syntax, is fair game for dictation.

The Setup That Works

VoiceInk runs locally on Mac, which matters for developers who work with proprietary code or internal systems. Nothing leaves your machine. You press a shortcut, speak, and the text appears wherever your cursor is sitting, inside VS Code, in a browser, in Notion, anywhere.

For code comments specifically, the workflow is: write the code, place the cursor above the function, press the dictation shortcut, say the comment out loud in one or two sentences, done. No switching apps. No copy-paste. The comment is already where it needs to be.

Where It Falls Short

Anything with symbols, variable names, or precise technical strings is still a keyboard job. Dictating const maxRetries = 3 will give you something like "const max retries equals 3," which needs cleanup. For actual code, voice is not there yet, and probably should not be your tool of choice.

Edge cases in natural language also trip things up occasionally. Acronyms, library names, and product names sometimes come through mangled. A quick proofread catches them, but it is worth knowing the limitation going in.

The Habit That Made It Stick

The developers I know who use voice dictation consistently all arrived at the same rule: speak the explanation, type the implementation. Natural language by voice, code by keyboard. The two modes do not compete. They split the work along lines that suit each one.

One developer I know uses it specifically for the documentation he used to skip entirely. He told me he spent years leaving functions uncommented because writing felt slower than just moving on. Now he dictates a one-sentence explanation before he writes the function, while the intent is still fresh. His codebase became easier to navigate in about a month.

That is not a dramatic story. It is just a small friction point removed, and a habit that became sustainable because the cost dropped low enough.

Worth Trying If You Write Documentation Reluctantly

If you find yourself skipping comments, writing terse PR descriptions, or putting off documentation until it is too late to remember why you made a decision, the problem might be mechanical as much as motivational. Lowering the physical cost of writing sometimes changes the output more than any commitment to being more disciplined.

Try dictating your next pull request description and see if it comes out longer than usual. It probably will.