Dictating commit messages, PRs and code comments

Ask a developer where their day goes and they will say "writing code." Watch the same developer for a few hours and you will see something else. A real share of the keyboard time is not code at all. It is prose about code: commit messages, pull request descriptions, review comments, the explanatory comment above a tricky block, the reply in a ticket thread.

This layer of writing is real work, and it is often done badly — not because developers cannot write, but because typing it competes with the actual coding and usually loses. Voice changes that, because this prose is the part of the job voice is genuinely good at.

The prose layer is bigger than it looks

None of these individually feels like much. But they add up, and each one is plain English with no syntax in it.

Commit messages. Every change ships with one. Most are one terse line because the full explanation felt like too much typing.
Pull request descriptions. The summary, the context, the reasoning, the testing notes. The single most-skipped piece of writing in software.
Code review comments. Several per review, and they set the tone of a team. Curt comments feel harsher than intended; that curtness is often just typing fatigue.
Inline comments and docstrings. The note to the next person, who is frequently you in six months.
Tickets and design notes. The thinking that happens in words before any code exists.

Add it up and a developer writes a surprising amount of prose every day. All of it is sentences, not symbols — exactly the material voice handles well, and exactly the material that suffers when typing it competes with coding.

Why these get written badly

The reason is consistent: typing this prose has a cost, and it is competing for attention with the code you would rather be writing. So you economize. The commit message shrinks to "fix bug." The PR description gets a one-liner or nothing. The review comment gets clipped to "why?" when you meant "I am not sure this handles the empty case — can you check?"

The intent was never to communicate poorly. It is that the full version costs typing effort at exactly the moment you want to move on. The medium shaped the output. This is the same effect that makes typed AI prompts shorter than they should be — we cover that in why voice changes the prompts you write.

The cost of this bad prose is not paid by you. It is paid later, by whoever reads the git log trying to understand a change, by the reviewer with no context, by the teammate who reads a comment as colder than you meant it.

Where voice genuinely speeds you up

When you dictate this prose, the cost that caused the compression mostly disappears, and the writing gets better almost as a side effect.

Commit messages

Instead of "fix bug," you hold a key and say: "Fix the race condition in the upload queue — drain pending writes before closing the connection so the last chunk is not dropped." That is one spoken sentence, maybe four seconds. It is a commit message someone can actually use a year from now. You did not write better history out of discipline; you wrote it because saying the full sentence cost nothing.

Pull request descriptions

The PR description is where voice pays off most, because it is the longest prose and the most often skipped. Speak it: what changed, why, what you considered and rejected, how you tested it, what a reviewer should look at closely. Two minutes of talking produces a description that would have been a chore to type and therefore would not have existed. The reviewer gets context. The review goes faster. The PR thread is shorter.

Code review comments

Dictated review comments tend to come out fuller and warmer. "This works, but it allocates a new buffer every iteration — consider hoisting it out of the loop, it is on a hot path" takes seconds to say and lands as a colleague helping rather than a terse "slow." Tone in review matters, and the curtness teams complain about is frequently just typing fatigue. Remove the fatigue and the tone softens on its own.

Inline comments and docstrings

The explanatory comment above a gnarly block is the thing you skip when typing because you want to keep moving. Dictating it costs little enough that you actually leave the note. Your future self benefits.

How this works in practice

The mechanics are simple, and the key point is that all of this writing is scattered across different apps. The commit message might be in a terminal, a Git client, or an editor's source control panel. The PR description is in a browser. Review comments are in the browser. Inline comments are in the editor. Design notes might be in a notes app.

That scatter is why a system-wide dictation tool fits the job. You want one way to dictate that works in every one of those places, with no per-app setup. That is how Lispr works: a small macOS app in the menu bar with no window. You hold the right Option key, speak, release, and the transcribed text appears at your cursor — in the terminal, the browser, the editor, anywhere. It does not integrate with Git or GitHub or your editor specifically. It just types where the cursor is, so it covers the whole prose layer without you configuring anything.

A workflow that holds up:

Finish the code change by hand. Code is keyboard work; that does not change.
Dictate the commit message. Hold the key, say the full sentence, glance at it, commit.
Dictate the PR description. In the browser, speak the summary, context, and testing notes as if briefing a colleague.
Dictate review comments as you read. Speak the fuller, kinder version of the note.
Read before sending. Dictated text wants a quick glance for a misheard word. A couple of seconds, worth it.

The honest scope

Voice will not type your code, and this post is not asking it to. The brackets, the identifiers, the operators — that is the keyboard's job, and trying to dictate raw syntax is a frustrating dead end. We say so plainly in how to start coding by voice.

But the prose layer around the code is large, it is real, and it is currently the part of the job most degraded by typing fatigue. That is exactly where voice helps: not by making you a faster coder, but by making the writing that surrounds your code something you actually do well, because doing it well no longer costs you a typing tax at the worst possible moment.

If you want to try it, Lispr is free in early access and macOS-only. The next post worth reading is voice-to-text for developers.