May 16, 2026

How I Write 3x Faster Using Dictation (As a Developer Who Hates Voice Assistants)

I want to be clear about this upfront: I do not talk to my computer. I type for a living. I have never used Siri for anything beyond setting a timer. The idea of having a conversation with an AI assistant makes me cringe. So when I say that dictation has made me a faster writer and a more productive developer, I am not coming from a place of voice-tech enthusiasm. I am coming from a place of “this actually works and I cannot ignore it.”

What I use dictation for (and what I don't)

I do not dictate code. Python and TypeScript are not spoken languages, and saying “const fetchUser equals async left paren user colon User right paren colon Promise less than User greater than equals greater than” is a form of self-harm I refuse to engage in. I type code. I always will.

But writing code is only about 40% of what I do. The other 60% is:

  • Pull request descriptions. Explaining what I changed, why, and what reviewers should look at. Every PR takes 5-10 minutes of writing.
  • Slack messages and async updates.The “here is where I am on this, here is what is blocked” messages that keep a distributed team running.
  • Documentation and READMEs. The writing everyone puts off until it is too late.
  • Design docs and RFCs. Long-form technical writing where the ideas are clear in my head but typing them out is the bottleneck.
  • Emails.Especially the “let me explain this technical decision to a non-technical stakeholder” kind.
  • Code comments and commit messages. Short-form technical writing that benefits from being conversational.

For all of these, dictation is faster — and the output is often better. Here is why.

Why dictation produces better writing than typing

When you type, especially as a developer, you edit as you write. You delete half-finished sentences. You rework phrasing mid-stream. You optimize for correctness at the sentence level, and you lose the thread of the paragraph. The result is text that is grammatically correct but reads like it was assembled from spare parts.

When you dictate, you cannot do any of that. You have to think a full sentence before you say it, and you have to say the whole sentence without stopping to revise. This constraint produces prose that is more conversational, more coherent, and — critically — faster. Your spoken vocabulary is larger and more natural than your typed vocabulary. You use clearer transitions because you are thinking in paragraphs, not in sentences.

The first time I dictated a PR description, I wrote more in three minutes than I typically would in ten — and the result was better structured. Not because I am a better speaker than writer, but because speaking forced me to think in complete thoughts rather than fragmented ones.

Real before and after: what dictation with cleanup looks like

Raw dictation is messy. You get filler words, run-on sentences, and the verbal tics you never noticed you had. A good dictation tool does not just transcribe — it cleans up. Here is a real example from a PR description I dictated:

Raw transcription (what I said)

“okay so uh this PR refactors the auth middleware to use the new token validation service which we talked about in the architecture review last week basically the old middleware was doing too many things it was validating tokens and also checking permissions and also logging and it was just this giant thing that was really hard to test and also hard to reason about so I split it up into three separate concerns the token validation the permission check and the audit logging and each one is now its own middleware that you can compose together”

After cleanup (what gets pasted)

This PR refactors the auth middleware to use the new token validation service discussed in last week's architecture review. The old middleware handled token validation, permission checks, and audit logging in a single module — making it hard to test and reason about. I've split it into three composable middleware functions: token validation, permission check, and audit logging.

Notice what changed: filler words removed (“okay so uh”, “basically”, “just this giant thing”), sentences broken up, structure applied, passive voice tightened. The core content is the same — it came from my brain in one shot. But the formatting pipeline turned a verbal brain dump into something a reviewer can actually read.

The developer dictation stack

Here is my actual setup. It runs on Apple Silicon Macs:

  1. Dictation tool: Rewisper (on-device, no cloud dependency). Global hotkey for hold-to-speak.
  2. Hold hotkey, speak, release. The transcription happens entirely on my Mac, then a cleanup pass runs on the raw transcript — also on-device.
  3. Preview popup appears. A small overlay shows the cleaned text. I can accept, edit inline, or discard. By default, accepting copies the result to the clipboard so I can paste it where I want; auto-paste at the cursor is an opt-in setting.
  4. Cmd+V into Slack, VS Code, Notion, Gmail. The cleanup toggles I leave on by default: filler word removal, punctuation and capitalization, grammar fixes, and sentence restructuring. Formality adjustment stays off unless I need it.

Where dictation breaks down for developers

I want to be honest about the rough edges, because developer audiences can smell hype from a mile away:

Technical vocabulary

On-device speech models are trained on general web data, not programming jargon. Saying “PostgreSQL” can produce “postgres SQL” or “post grey squirrel” depending on the model and your accent. You learn to enunciate technical terms clearly, or you type them. I do a hybrid — dictate the prose, type the variable names and technical identifiers.

Inline code and markdown

Dictating markdown formatting is tedious. “Backtick backtick backtick python newline” is not a good use of voice input. For PR descriptions and docs with code blocks, I speak the prose and then type the code snippets. The time savings on the prose alone is worth it.

Open-plan offices

Dictating in an office is socially strange. People hear you talking to your screen. It feels like being on a phone call but only one side. I do it anyway, with noise-cancelling headphones on, and my team got used to it within a week. But it is a real barrier.

The privacy angle for developers

As a developer, I am acutely aware of where my data goes. I would not dictate internal design docs or PR descriptions through a cloud service. The content of those messages is commercially sensitive — it describes what we are building, why, and what the architecture looks like. Sending that through a third-party server is unreasonable for most companies.

On-device dictation solves this. Both the transcription and the cleanup pass happen on my Mac. Audio is processed locally and discarded after the transcript is produced. The result lands on my clipboard (or at my cursor if I enable auto-paste). There is no server, no API call, no data retention. I can dictate internal technical content without creating a data trail outside the company. This is not a privacy preference — for many developers, it is a condition of being allowed to use dictation at all.

What changed after a month

The first week was awkward. I kept forgetting the hotkey. I would start speaking and realize I did not actually know what I wanted to say. My dictated sentences were halting and self-conscious.

By week two, the hotkey was muscle memory. I stopped thinking about the fact that I was speaking and started just communicating.

By week four, I noticed a pattern: I was writing longer, better PR descriptions. I was sending more thorough Slack updates. I was actually writing documentation instead of putting it off. Not because I had become more disciplined — because the friction was gone. Writing no longer felt like work.

Dictation did not make me a faster typist. It removed typing from the equation entirely for the 60% of my job that is communication. That is the part I did not expect.

Should you try this?

If you are a developer and the idea of talking to your computer makes you uncomfortable — good. That means you are the target audience. The people who already enjoy voice assistants are not the ones who will benefit from dictation as a productivity tool. The people who resist it, try it, and discover it actually works are the ones who become evangelists.

Start small. Use dictation for one PR description. Then one Slack message. Then one email. You will notice within a week whether it fits your workflow. If it does not, you spent nothing but a few awkward minutes talking to your screen. If it does, you just unlocked a writing speed you did not know you had.

Read: The Mac Power User's Guide to Voice Workflows →
Read: Fixing RSI — How I Switched From Typing to Dictation Without Going Insane →