Dictating Code Comments: A Developer's Honest Take

Nobody wants to write documentation. Most developers I know write code at speed, then spend a guilty hour at the end of a project backfilling comments and hoping they remember what they were thinking. The result is documentation that's technically accurate and completely unhelpful.

Voice dictation doesn't fix the motivation problem. But it does remove enough friction that you might actually do it in the moment, while the context is still live in your head.

Where Voice Works Well for Developers

The best use case isn't dictating code. It's dictating the prose around code. Comments, docstrings, README sections, architecture notes, PR descriptions. These are things you'd write in plain English anyway, and they're exactly the kind of task where typing slows your thinking without adding value.

Dictating a docstring takes about ten seconds of talking. Writing it by hand takes longer, and you're more likely to keep it terse to save time. Spoken documentation tends to be more thorough, because there's less cost to being complete.

What to Expect From Accuracy

General prose transcription with a tool like VoiceInk is accurate enough that cleanup is minimal. Technical terms are where you hit friction. Variable names, method names, library names, anything that doesn't appear in standard text corpora might come out garbled.

The practical workaround most developers land on: dictate the explanation, type the technical tokens. Say "this function takes a user object and returns a filtered list based on the role field" as speech, then manually type the actual identifiers in context.

It sounds like a workaround because it is. But it's still faster than typing the whole comment from scratch.

Stand-Up Notes and Meeting Capture

This is where voice tools earn their keep in a developer workflow. You're in a planning session, someone makes a decision about the API contract, and you want to capture it without breaking the flow of the conversation.

Press a key, speak the note, release. VoiceInk drops the text wherever your cursor is. You didn't open a new tab, you didn't switch apps, and you didn't lose your place.

For async stand-ups written in Slack or Linear, dictating is faster than typing. You say what you did, what you're doing, and what's blocking you in about thirty seconds of speech.

Architecture Decision Records

ADRs are one of those things that teams know they should write and rarely do. The friction is real: you've just made a decision, you understand it completely, and the last thing you want to do is write several paragraphs explaining the context and tradeoffs.

Dictating an ADR takes about three minutes of talking. You're explaining it the same way you'd explain it to a new team member. The spoken version has a natural structure: here's the problem, here's what we considered, here's what we chose and why.

That structure is exactly what an ADR needs. Speaking it out loud produces a better first draft than most developers write by hand, because you're not trying to write. You're explaining.

The Keyboard Isn't Going Anywhere

Nothing about this is a replacement for typing. You will type code. You will type precise commands. Voice doesn't help you there, and trying to force it creates more problems than it solves.

But there's a category of developer work that is fundamentally prose: documentation, comments, notes, tickets, commit messages, postmortems. That category is large, often neglected, and poorly suited to the keyboard-first mentality most developers default to.

Voice is a tool. Add it where it fits, skip it where it doesn't.

One Way to Start

Next time you finish a function, before you move on, press the key and describe what the function does in one or two sentences. Don't think about it. Just say it.

That's your comment. It took ten seconds. It's probably better than what you would have typed.