Most of a file is syntax, and syntax has to be typed exactly, one character at a time, by someone who already knows precisely what it needs to say. A docstring, a comment explaining why a piece of code exists, a commit message, a pull request description — these are different. They are prose, composed the way any sentence is composed, and then typed out afterward at whatever speed a keyboard allows. That gap, between having the sentence already formed and getting it into the file, is what a held key closes.
Where typing the comment is slower than writing it
The code itself rarely benefits from being said aloud — nobody dictates a
for loop. What does benefit is everything around it: the docstring on a
function, the paragraph in a pull request explaining a decision, the commit
message that will be the only record of why a change happened once the
context has left everyone's head. Those get typed slowly because they are
composed in full sentences, re-read, and often edited mid-thought, which is
exactly the kind of writing dictation replaces well.
Where a held key fits into an actual coding session
Docstrings and inline comments, said once
Hold ⌥ Space, say the sentence, let go — it lands in whichever field has focus, through the accessibility API where the editor's text area supports it and a synthetic paste otherwise, with the clipboard restored afterward either way.
Retries the request up to three times with backoff before surfacing the error to the caller.
Commit messages that explain the "why," not just the "what"
A commit message summarizing a diff is easy to type badly — a rushed "fix bug" that explains nothing six months later. Saying the actual reasoning out loud, then letting it land in the commit editor, tends to produce a fuller sentence than typing the same thought would, if only because speaking a reason takes less effort than typing one.
Pull request descriptions
The PR description is often the longest piece of prose in the whole change — what the diff does, why, what was tried and rejected, what a reviewer should look at first. Dictating that paragraph into a browser's PR form works the same way it does in an editor: the destination is fixed the moment the key goes down.
Code review comments
A review comment explaining a suggested change benefits the same way a PR description does — it is prose, aimed at a specific line, and typing it out in full rather than in clipped shorthand takes real time across a day of reviewing several changes.
What gets kept, across an afternoon of small edits
- 10:123.6sRetries the request up to three times with backoff before surfacing the error.Code
- 11:405.1sSwitched to a queue here because the old approach dropped events under load.Terminal
- 15:024.4sLeft the old path in place behind a flag until the new one has run in prod for a week.Code
Every dictated line is written to local history before it is typed anywhere, and that history stays on the machine it was said on. Nothing about a docstring or a commit message leaves the Mac to be transcribed, and the app works the same with no network connection at all — worth knowing for anyone who edits code on a flight or in an office where the network is deliberately restricted.
What stays on the keyboard
The syntax itself — brackets, indentation, the actual logic of the code — is still typed by hand, one character at a time, the way it always has been. So is anything that needs picking from a list: an autocomplete suggestion, a specific file in a fuzzy finder, a line in a diff view. Dictation replaces typing the English around the code; it does not replace writing the code, and nothing about using it changes how an editor's own shortcuts or autocomplete behave.
Where Talon does something this app is not built to do
Talon is built specifically for writing and editing code by voice — commands to move the cursor, select a block, insert a snippet, navigate between files, all spoken rather than typed. This app does none of that. It has no command grammar and no way to edit code structurally; it only types the words it hears, into whatever field already has focus. Anyone who wants to write the code itself by voice, not just the comments around it, is better served reading what Talon actually does than taking this page's word that a held key is enough.
Where a learned vocabulary would help more here than almost anywhere else
A codebase has its own vocabulary — internal service names, a teammate's unusually spelled surname, an acronym specific to one company — and this app has no memory of any of it. Each one comes out however the engine hears it, every time, with no improvement from repetition. Wispr Flow builds a vocabulary that adapts with use specifically so that recurring names and jargon get corrected automatically after the first few times, which matters more in a codebase full of invented names than it does in ordinary prose. That gap is real and worth weighing before choosing between the two.
What happens if a dictation doesn't make it into the file
- 1Key downthe target is chosen here
- 2You speaklevel meter, over your work
- 3Key up
- 4Written to historybefore the engine is asked
- 5Engineon your Mac
- 6Typedabout half a second
A docstring dictated right as a terminal loses focus, or a comment said just before an editor crashes mid-save, used to mean redoing the sentence from memory, if it got redone carefully at all. Here, whatever was said before the key was released is written to local history immediately, before the engine that turns it into text is even asked to produce a result. An interruption costs, at worst, pasting the sentence back in from history rather than retyping a comment that had already been thought through once.
Working across a laptop and a desktop
A licence covers three devices, each installed separately with no account and no sync connecting them. For a developer who writes code on a desktop during the day and reviews pull requests from a laptop in the evening, that means each machine's dictation history stays exactly where it was created — a comment dictated on the desktop does not show up in the laptop's history, and moving one anywhere else is a deliberate, manual step rather than something that happens in the background.
Building the habit across a sprint
The value of dictating comments and commit messages rarely shows up in any single line being faster to write than it would have been typed — it shows up across a full sprint, in how many commits actually carry a clear explanation of why a change was made rather than a rushed one-line summary written under time pressure. A held key does not make any individual commit message better reasoned than a typed one would be; it lowers the friction of writing the fuller version, which is where the extra context actually comes from.
What it costs and what it runs on
$19 once, three devices, macOS 13 Ventura or later, Apple Silicon or Intel. The thirty-day trial runs the full app with no card and no account, which is enough time to carry a real sprint's worth of docstrings, commits and PR descriptions through it and judge the habit against actual work rather than a single test sentence. The broader page written for developers covers a day that mixes this with longer technical writing, and the round-up of speech-to-text tools built with developers in mind compares several options side by side for anyone still deciding.
A hotkey that survives an editor's own bindings
Most editors and terminals ship with dense keyboard shortcuts of their own, and a system-wide dictation hotkey has to avoid colliding with them. The default ⌥ Space is chosen to sidestep the most common conflicts, but it is worth a quick check in System Settings, under Keyboard Shortcuts, against whatever editor and terminal are already installed. The general page on setting up a dictation hotkey covers the same check in more detail for anyone running several development tools at once.
A realistic afternoon of small commits
A plausible stretch: dictate a docstring explaining why a function retries before failing, write a commit message for a small refactor a few minutes later, leave a review comment on a teammate's pull request suggesting a different approach, and draft a PR description summarizing the day's change before opening it for review. None of it is individually large — each one alone might save thirty seconds over typing the same sentence. Across a week with dozens of these moments spread through several pull requests, the time saved on the English parts of the work adds up to noticeably more of the day spent writing and reading code, and less of it spent composing sentences about it one keystroke at a time.
Why the comment benefits from being said, not composed silently
A comment explaining a non-obvious decision is usually clearest the moment it's first thought through — right after the workaround is written, while the reasoning is still fresh, rather than reconstructed later during a review when the original context has partly faded. Typing that comment out slowly, word by word, tends to produce a shorter, vaguer version of the explanation than saying it in one pass does, if only because typing introduces natural pauses to reconsider and shorten a sentence that speaking does not. A commit message written the same way — said once, in full, right after the change is made — tends to hold more of the actual reasoning than one typed under the pressure of moving on to the next task.
Reading a comment back before trusting it
A comment or a commit message still deserves the same glance a typed one would get before it's committed — an engine that mishears a technical term or a project's internal name will type the wrong word with the same confidence as the right one, and only a human reading it back catches the difference. That check costs a few seconds and is worth building into the habit from the first day, the same way reviewing a typed sentence for a typo already is for most people. Nothing about saying a comment instead of typing it removes the need to read it once before moving on.
Code review, from the other side
Reading someone else's diff and explaining what needs to change is its own kind of writing, distinct from writing the original code — full sentences, reasoning through a suggestion, sometimes several paragraphs on a change that touches a sensitive part of a system. A reviewer who dictates that explanation, the way they would if walking a teammate through it in person, tends to leave a more complete comment than one typed in the clipped shorthand that a review tool's small text box tends to encourage.
Who this actually suits
Anyone whose day includes writing the English parts of a codebase — docstrings, commit messages, PR descriptions, review comments — rather than typing them out slowly after the fact, has a straightforward reason to try the thirty-day trial against a real week of actual commits.
Anyone who wants the code itself written or edited by voice, or who needs a vocabulary that learns a codebase's own names automatically, is better served reading the comparison against Talon or the comparison against Wispr Flow first, since this app closes neither gap. The general page on Mac dictation covers the same mechanism applied to writing outside of code entirely, for a day that mixes both.
The real test is an ordinary sprint, not a single docstring dictated as a demo — a week where every commit message and PR description gets said rather than typed, judged by whether the habit still feels worth it once the backlog is empty and the next sprint has started.