Write Code Review Comments Faster with Voice Dictation

A useful code review comment explains more than what looks wrong. It identifies the behavior, explains why it matters, and gives the author a clear next step. Writing that explanation repeatedly can interrupt your review, especially when a short phrase such as “handle the empty case” leaves too much unsaid.

Voice dictation offers a way to draft the explanation while the reasoning is fresh. On your Mac, keep the diff visible, open a comment draft, and speak as if you were walking a teammate through the issue. Then edit the text before posting. Dictation captures your explanation; it does not verify the code or decide whether a change is correct.

1. Gather the evidence before you speak

Choose one concern for the comment. Note the relevant line or function, the input or situation involved, and the behavior you observed or expect. If you have not run the code, say that your concern comes from reading it. A possible failure should not sound like a reproduced bug.

Decide what kind of response you need:

• Required change: Explain the agreed requirement or concrete issue that needs resolving before approval.
• Suggestion: Make it clear that the improvement is optional.
• Question: Ask for context when you do not yet know whether a change is needed.

Use your team's review conventions. A personal preference should not become a blocking request simply because the wording sounds firm.

2. Dictate the reasoning, then add exact references

Speak in three parts: “In this situation, I noticed this behavior. It matters because of this effect. Could we make or check this change?” Pause between thoughts and keep each comment focused on one issue.

After dictating, insert exact identifiers, file paths, and code snippets from the source. Do not rely on speech recognition for punctuation-sensitive code. Remove repeated explanations and comments about the person; describe the implementation and its effect instead.

3. Turn a vague note into actionable feedback

Here is a fictional example in which the reviewer has reproduced the behavior locally.

Initial note: “The empty search case needs fixing.”

Edited review comment:

Required change — empty search: When I submit a search with only spaces, the results panel stays in its loading state. I reproduced this locally with the current change. The user gets neither results nor an explanation of what to do next.

Could we handle whitespace-only input before starting the search and show the agreed empty-input message? Please also add a test for that path so we can check that the loading state ends correctly.

If you only suspect the problem, change the opening to “From reading this branch, it looks as though…” and ask whether another path already handles it. If the expected message has not been agreed, ask what the intended behavior should be instead of inventing a requirement.

4. Reuse a short code review comment template

Type: [Required change / suggestion / question]

Context: In [location or scenario], [observed behavior or clearly labeled concern].

Effect: This matters because [specific consequence].

Next step: Could we [focused change, verification, or explanation]?

Evidence: [Reproduction steps, relevant requirement, or test result, if available].

Treat these fields as drafting prompts, not mandatory headings for every comment. A small suggestion may need only two sentences. Put a concern that spans several files in a review summary and link to the relevant places rather than repeating it under every line.

5. Review the comment before posting

Check names, negations, and technical terms against the diff. Confirm that “does” has not become “does not,” and that every claimed test result actually exists. Make the requested response explicit, then read the comment from the author's perspective: can they understand the issue without guessing your intent?

For related workflows, see writing pull request descriptions and drafting clear bug reports.

TypeFree is a simple way to turn speech into editable text and write faster. Dictate the reasoning behind your next code review comment, verify the details, and post feedback that helps the author take the next step.