Dictate Code Reviews and Commit Messages by Voice (and What to Still Type)

Dictating a code review or a commit message works when you speak the reasoning and type the symbols. Review comments and commit bodies are mostly explanation, which is what speech is good at. They also contain identifiers and exact numbers, which is where dictation quietly goes wrong. This post gives a split that works, two prompts to clean up a transcript, and a small linter I ran so you can catch the usual dictation damage before you press save.

I did not run any dictation tool for this article. What I did run is the linter below, on hand-written samples, and the output is pasted as it printed. Tool facts come from vendor pages read on 2026-10-09. If you have not chosen a tool yet, start with the dictation tool comparison. For the general spoken-prompt shape, see how to speak a good AI prompt.

What should you dictate in a code review?

Dictate the why and the suggested direction. Type the where.

A review comment has three parts: where it points, what is wrong, and what you would do instead. The "where" is already attached by the review tool, because the comment sits on a line. The "what is wrong" is prose. The "what to do instead" is prose plus maybe one identifier.

A spoken pattern that stops rambling is tag, problem, reason, ask. Here is an illustrative comment (written by hand, not a captured transcript):

"Blocking. This retries on every non two hundred response, including four hundreds. A four hundred means the request is bad, so a retry can only create duplicates. Can we retry only on five hundreds and network errors?"

After the dictation pass you would turn "non two hundred" into non-2xx and "four hundreds" into 4xx by hand. That is two edits of about three seconds each. It is faster than typing the paragraph, and the typed parts are exactly the parts where a wrong character matters.

If you want an AI model to draft the first pass of the review itself, that is a separate job; see AI code review prompts that catch bugs. Dictation helps when you are the reviewer and want your own judgement written down faster.

How do you dictate a commit message?

Open the editor, do not use -m. The reason is practical: with git commit and no message flag, your editor opens with the staged-changes summary below the cursor, you can see what you are describing, and you can read the message before saving. Git's git commit documentation also says that if you leave the editor without changing a template message, the commit is aborted, which is a useful safety net.

Git's documentation, read on 2026-10-09, says it is a good idea to begin the message with "a single short (no more than 50 characters) line summarizing the change, followed by a blank line and then a more thorough description." It also says the text up to the first blank line is treated as the title and used throughout Git, for example as the email subject line by git format-patch. That is why the blank line matters: without it, your whole paragraph becomes the "title".

Dictation tends to break exactly those two rules. You speak one long run-on sentence, and the tool gives you one long line. So split the job:

1. Type the subject. Fifty characters is ten words at most. If you use Conventional Commits, the structure is type(scope): description, then a blank line, then an optional body, and the spec says feat and fix map to minor and patch version bumps. Typing fix(webhook): is faster than saying "fix open paren webhook close paren colon".
2. Press Enter twice, then dictate the body. Say what changed and why, not how; the diff shows how.
3. Read it once. Search for negations and numbers.

An illustrative spoken body:

"Retries now only happen on five hundreds and network errors. A four hundred means the request itself is bad, so a retry cannot succeed and only creates duplicates."

Notice what you did not dictate: the issue number, the branch name or any hash. Type those.

A linter for dictation damage (real output)

Reading is the weak step, so I wrote a short Python script that checks a message for the usual dictation artifacts. It checks the subject length against the 50 and 72 figures, the blank line, a trailing period, spoken punctuation left in the text (the words "period", "comma", "colon", "new line"), filler words, and the Conventional Commits pattern. It is about 40 lines and uses only the standard library.

import re
import sys

FILLERS = re.compile(r"\b(um|uh|you know|basically|i mean|kind of)\b", re.I)
SPOKEN = re.compile(r"\b(period|comma|new line|newline|new paragraph|colon|open paren|close paren)\b", re.I)
CC = re.compile(r"^(feat|fix|docs|refactor|test|chore|perf|build|ci)(\([\w-]+\))?!?: .+")

def check(msg: str):
    lines = msg.split("\n")
    subject = lines[0]
    out = []
    if len(subject) > 72:
        out.append(f"FAIL subject is {len(subject)} chars (over 72)")
    elif len(subject) > 50:
        out.append(f"WARN subject is {len(subject)} chars (git docs suggest 50 or fewer)")
    if subject.endswith("."):
        out.append("WARN subject ends with a period")
    if len(lines) > 1 and lines[1].strip() != "":
        out.append("FAIL no blank line between subject and body")
    if SPOKEN.search(msg):
        out.append("FAIL spoken punctuation left in text")
    if FILLERS.search(msg):
        out.append("WARN filler words")
    if not CC.match(subject):
        out.append("INFO subject does not match Conventional Commits pattern")
    return out or ["OK"]

I ran the full version (which also prints the matched words) on four hand-written samples. Sample 1 is a raw run-on dictation with spoken punctuation. Sample 2 is good text with no blank line. Sample 3 is the fixed message. Sample 4 is a long prose subject with a filler.

--- fix the retry bug in the webhook handler where we were um re
   FAIL subject is 96 chars (over 72)
   FAIL no blank line between subject and body
   FAIL spoken punctuation left in text: colon, comma, period
   WARN filler words: basically, um
   INFO subject does not match Conventional Commits pattern
--- fix(webhook): stop retrying on 4xx responses
   FAIL no blank line between subject and body
--- fix(webhook): stop retrying on 4xx responses
   OK
--- Update the webhook handler so that it no longer retries when
   FAIL subject is 105 chars (over 72)
   WARN subject ends with a period
   WARN filler words: you know
   INFO subject does not match Conventional Commits pattern

The samples are artificial, so this proves the script catches those patterns, not how often your tool produces them. To use it for real, save the script, point it at .git/COMMIT_EDITMSG from a commit-msg hook, and treat FAIL lines as blocking. Keep the hook fast and local; a hook that calls a model on every commit will annoy you within a day.

Which cleanup prompt works for a messy transcript?

If a dictated body is long and messy, paste it to a model with a strict instruction. These are untested templates.

For a commit body:

Below is a dictated commit message body. Rewrite it as a git commit body:
wrapped at 72 characters, explaining what changed and why. Do not add facts
that are not in the text. Do not invent issue numbers, file names or test
results. If the reason for the change is missing, output one line starting
with "MISSING:" instead of guessing. Keep every negation exactly as spoken.

[PASTE TRANSCRIPT]

For a review comment:

Below is a dictated code review comment. Tighten it into one comment of at
most 80 words. Keep the severity word first. Keep my meaning, including any
"don't" or "not". Do not soften a blocking comment. Put any identifier I
mention in backticks exactly as I wrote it, and list identifiers you are
unsure about after the comment.

[PASTE TRANSCRIPT]

The last line of each does real work. A rewriting model fills gaps with plausible detail, and in a commit history plausible but wrong detail is worse than a short message. If your repo is confidential, remember that pasting a transcript into a hosted model is the same disclosure as pasting code; see what not to paste into ChatGPT.

What about privacy for review comments?

Review comments describe unreleased code and sometimes security flaws. Wispr Flow's privacy page says transcription always happens in the cloud. Superwhisper's homepage says it works offline and lists cloud language models for some modes, and it does not state on that page where audio goes, so read its privacy policy before relying on "local". Both pages were read on 2026-10-09 (through a summarising fetch) and I did not verify either in a network trace.

Practical rules:

• Do not dictate a vulnerability description for a private repo into a cloud tool without clearance. Type it, or use a local model.
• Do not speak secrets you spotted in a diff. Say "there is a hardcoded key on line 40" and type the rotation ticket yourself.
• Remember who can hear you. A review spoken in an open office is a disclosure.

Where this does not pay off

Skip voice for one-line commits ("docs: fix typo"); typing them takes five seconds. Skip it for nit-heavy reviews where each comment is six words. Skip it in rooms where you cannot talk. And skip it if your correction time beats your typing time: count honestly for a week.

A fair test is cheap. For five days, dictate every review comment longer than two sentences and tally how many needed a fix before posting. If more than about one in three did, your vocabulary needs adding to the tool's dictionary, or the tool is not for you. That threshold is a rule of thumb I am suggesting, not a measured finding.