We Built EmberType By Dictating Most of the Non-Code Parts. Here's Why.

Dictating Code vs. Dictating Around Code

Let's get the obvious misconception out of the way first: you cannot realistically dictate code in a conversational way. Code is full of punctuation-dense syntax, camelCase identifiers, and symbols that don't translate well to spoken language. Saying “open curly brace new line tab double quote password double quote colon space” is slower than typing.

There are specialized tools that solve this differently. Talon uses custom grammars and phoneme-based commands so that “slap func” expands to a function declaration. Serenade does similar things with natural-language commands like “create function get user by id.” Both work. Both have real learning curves — weeks, not hours — and both are primarily used by developers with RSI, disability, or strong ergonomic motivations.

For the rest of us, the actual win is different. It's not dictating code. It's dictating everything else. That's this article.

The 40% You're Not Counting

Pay attention to your keyboard tomorrow. Note every time you're typing something other than code. A partial list of what probably comes up:

• Commit messages
• PR descriptions
• Code review comments
• Slack and Teams messages
• Design docs and RFCs
• Incident postmortems
• GitHub/Linear issue descriptions and replies
• Customer support tickets
• Retro notes and standup updates
• Technical blog posts
• Email to stakeholders, vendors, recruiters
• README files and inline documentation
• AI chat prompts in Cursor, Copilot Chat, ChatGPT, Claude

All of this is natural English. All of this is dictatable. For most developers with any amount of leadership, communication, or cross-team responsibility, this is a solid third to half of the keyboard day. Stack Overflow and GitHub's developer surveys have consistently shown communication and documentation as major non-coding time sinks for engineers — and at mid/senior levels, the share of time spent in English usually grows.

Where We Use Dictation Building EmberType

Fair warning: this is biased — we build a dictation app. But it's the same setup I'd recommend to any developer. Here's the honest tour of where I use my own tool day-to-day:

Commit messages

I stage changes, run git commit, and dictate a proper two-paragraph message. First line is the summary; a blank line; then a paragraph explaining why this change was made, what alternative approaches I considered, and what the reviewer should look at. Typing that out used to feel like homework. Dictating it takes 20 seconds and reads better.

Specifically: my commits got longer when I started dictating them, and reviewers noticed. When you're not punishing your fingers for every character, you can afford to explain things.

PR descriptions

Same thing, longer form. A good PR description has a What, a Why, a How, and a Testing Notes section. Dictating that is 2 minutes. Typing it when you're tired is 8 minutes — and you skip the optional sections half the time because you're tired.

AI chat panes

This is the sneaky biggest win. If you use Cursor Composer, GitHub Copilot Chat, Claude Code, or any of the AI-pair-programming tools that take natural-language prompts, you're typing English all day. Dictating “can you refactor this function to use async/await and return a typed result, preserving the existing error handling but converting it to a Result type” is much faster spoken than typed. And the prompt tends to be more specific when you're talking through what you want.

Code review comments

GitHub's review comment boxes are English. “Nit: this variable name doesn't match the existing pattern — we're using Hungarian notation everywhere else in this file, so userMap should be mUserMap for consistency.” That whole sentence is 2 seconds spoken and 15 seconds typed.

Slack threads

Incident channel updates, DMs to a teammate, long explanations in #eng-architecture. Voice dictation turns the “I don't have time to write this up properly right now” excuse into a non-issue. You can write it up properly in the time you'd have spent on a hasty two-line reply.

Design docs and RFCs

I draft these by dictating into Notion or a plain markdown file, then edit. A 1500-word draft that would have taken me 45 minutes to type takes about 12 minutes to dictate plus 10 minutes to clean up. The quality of the first draft is usually higher too, because I'm thinking in paragraphs rather than sentences.

The IDE Question: Does It Actually Work in VS Code and Cursor?

Yes. This surprises developers who expect dictation to require an IDE-specific plugin. On Mac, system-wide voice dictation types into whatever text field has focus. That includes:

• VS Code (and any VS Code fork: Cursor, Windsurf)
• JetBrains IDEs (IntelliJ, PyCharm, GoLand, WebStorm, etc.)
• Xcode
• Zed
• Terminal and iTerm2 (useful for git commit -m inline)
• Neovim running in a terminal

The editor doesn't know or care that the text came from voice. It's just keystrokes arriving in whatever field has focus. The speech recognition happens upstream in a separate process.

The one place system-wide dictation struggles is inside modal inputs like Vim's command mode. If you're a heavy Vim user, you'll want the dictation tool active in insert mode only — most tools have a hotkey to toggle dictation on and off, which works cleanly with Vim's mode model.

Custom Vocabulary: The 10-Minute Setup That Saves You an Hour a Week

Whisper and most modern speech recognition models are trained on general English. They will misrecognize:

• Your company's product and service names
• Package and library names that aren't already famous
• Internal acronyms and jargon
• Teammates' last names, especially non-Anglo names
• Domain-specific terminology (biotech, fintech, ad-tech, etc.)

Every serious Mac dictation tool has a custom dictionary. Populate it once with terms you use daily. For a typical backend developer that might include:

Kubernetes, kubectl, Helm, Istio, Argo,
Datadog, Grafana, OpenTelemetry, OTEL,
RabbitMQ, pgBouncer, Snowflake, DBT,
our-service-name, our-product-name,
Marquez, Liliana, Ovidiu, Priya,
SRE, P1, P2, PDR, RCA, SSO

Ten minutes of setup. The accuracy improvement on technical English is dramatic.

The Commit Message Pattern

Here's a specific workflow I use almost every commit. It might sound excessive — it is not, once you've dictated it once.

1. Stage your changes: git add -p or however you do it.
2. Start the commit: git commit (no -m — you want the editor to open).
3. Hit your dictation shortcut. Speak the commit message as two parts: a one-line summary, pause, then a full explanation of what the change does and why.
4. Quick cleanup pass. Fix any mis-transcribed identifiers — usually a word or two.
5. Save and close. Commit created.

Total time: maybe 40 seconds for a commit with a proper message. Compared to 3–5 minutes of typing, or the alternative of typing git commit -m "fix bug" with none of the context a future reader needs.

This is also a quiet way to force yourself into better commit hygiene. When writing a good message costs almost nothing, you stop writing bad ones.

The AI Chat Pattern

The AI pair-programming workflow (Cursor, Copilot Chat, Claude Code, Warp agent mode) has a particular dictation sweet spot. You're effectively explaining a change to a teammate, just a teammate who happens to be an LLM. The prompts that produce the best results are long, specific, and conversational — exactly what dictation is good at.

My typical prompts went from:

“add tests for this”

to:

“Add unit tests for the parseUserInput function covering: the happy path with valid input, empty string input, input with special characters, input exceeding the max length, and input with mixed casing. Use the existing Jest patterns in the same file — describe block with nested its, no mocking, synchronous. Match the existing naming convention.”

Both take about the same amount of cognitive effort. The dictated one takes 15 seconds and gets a usefully better answer. This is a real, underrated productivity gain in the AI-coding era.

Where Dictation Genuinely Doesn't Win

Fair is fair. Three situations where I still reach for the keyboard:

1. Short Slack replies

If the reply is four words, typing is faster than activating dictation, speaking, and getting back to work. Dictation has a minimum-task-size threshold. For 1–5 word replies, keyboard wins.

2. Noisy environments

Open-plan offices, coffee shops with loud music, next to a teammate on a meeting. Dictation is a quiet-space tool. Noise-canceling microphones help but don't fully fix it.

3. Anything involving a lot of punctuation

Regex. Shell one-liners with quoting. YAML fragments. SQL with lots of joins. If you're going to say “backtick grep space quote ERROR quote space pipe space head n 20 backtick,” just type it.

The Offline Privacy Angle for Developers

One developer-specific note worth calling out: if you dictate into your work machine about proprietary code, internal architecture, or customer incidents, you almost certainly don't want that audio going to a cloud speech service for transcription. Most company security policies prohibit it, and most cloud dictation tools don't have the enterprise BAA/DPA setup that would make it cleanly OK.

A local Whisper-based tool processes audio entirely on your Mac — the audio and transcript never leave your laptop. No security review needed; it's architecturally identical to typing into a text field. We've written about the broader privacy angle for voice tools, but for developers specifically, this is the cleanest answer to “is it OK to use this at work?”

The Five-Minute Setup

1. Download EmberType. Free trial. Apple Silicon Mac, macOS 14+.
2. Pick the Medium Whisper model for a good speed/accuracy balance. Swap to Large v3 if you care about unusual package names.
3. Set your dictation hotkey. I use Option+Space. Make sure it doesn't collide with Spotlight, Raycast, or Alfred.
4. Populate your custom dictionary with the list above — 10 minutes, done once per machine.
5. Tomorrow, dictate your first commit message. Dictate one Slack reply that's longer than three lines. Dictate one AI chat prompt in Cursor or Copilot. That's it — you'll notice within a day.

Bottom Line

Voice dictation isn't a replacement for the keyboard, and it's not a tool for writing code. It's a tool for the English-language typing that sits on top of everything you do as a developer — and that typing is a bigger share of your day than you think. On Mac, with a local Whisper-based tool, it integrates into every editor and chat surface you use without any per-app setup.

The developers I know who adopted it kept adopting more. It's the kind of change that feels small in week one and indispensable by month three.

---