Why I Stopped Using My Keyboard for Claude Code

I spent years getting faster at typing. I learned vim motions. I bought a mechanical keyboard. I optimized my terminal shortcuts.

Then I started dictating to Claude Code and realized I’d been solving the wrong problem.

The bottleneck in AI-assisted development isn’t how fast you can type. It’s how fast you can articulate what you want. And speaking is simply faster than typing for most people—especially when explaining complex logic or describing multi-step changes.

The Setup That Changed Everything

On macOS, dictation is built in. You enable it in System Preferences, assign a keyboard shortcut, and start talking. I use the double-tap of the Function key.

Here’s what a typical session looks like:

1. Press the dictation shortcut
2. Say: “Add a retry mechanism to the API client with exponential backoff starting at 500 milliseconds and maxing out at 30 seconds”
3. Release the shortcut
4. Claude starts working

No typing. No fighting with syntax. Just describing what I want in plain English.

The Problem With Raw Dictation

Speech-to-text isn’t perfect. It mishears technical terms constantly. “API” becomes “a pie.” “Kubernetes” becomes “Cooper Nettie’s.” “pytest” becomes “pie test.”

I could manually fix these errors, but that defeats the purpose. I want hands-off automation.

So I built a skill that intercepts my dictation and fixes ambiguities before Claude starts executing.

The Ambiguity-Fixing Skill

Create this file at .claude/skills/fix-ambiguity/prompt.md:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

You are a preprocessing layer for voice-dictated development prompts.

The user has dictated a prompt using speech-to-text, which may contain:
- Misheard technical terms (e.g., "a pie" should be "API")
- Unclear abbreviations or run-together words
- Missing punctuation that changes meaning
- Ambiguous references that need clarification

Your job:
1. Identify likely speech-to-text errors in technical context
2. Fix obvious mishearings (pytest, API, async, await, etc.)
3. Clarify any genuinely ambiguous instructions by asking ONE focused question
4. If the intent is clear after fixes, proceed directly to implementation

Common corrections:
- "a pie" -> "API"
- "pie test" -> "pytest"
- "Cooper Nettie's" -> "Kubernetes"
- "dang go" -> "Django"
- "type script" -> "TypeScript"
- "my sequel" -> "MySQL"
- "post gress" -> "Postgres"
- "redis" (correct) vs "read is" -> "Redis"
- "doc strings" -> "docstrings"

After applying corrections, restate the clarified prompt and begin implementation.

Now when I dictate something garbled, Claude fixes it automatically before starting work.

1

mkdir -p .claude/skills/fix-ambiguity

Making It Even Faster With Shortcuts

I experimented with Apple Shortcuts to chain the entire flow: dictate, transcribe, send to Claude for correction, then execute. The automation looked something like:

1. Shortcut captures voice input via dictation
2. Passes transcribed text to a shell script
3. Shell script prepends the fix-ambiguity skill invocation
4. Result goes directly to Claude Code

It worked, but honestly the simpler approach is better. Just dictate into Claude Code directly and invoke the skill when needed. Over-automation creates its own maintenance burden.

When Voice Input Works Best

Voice dictation shines for:

• High-level task descriptions: “Refactor the authentication module to use JWT instead of session cookies”
• Multi-step instructions: “First update the database schema, then modify the model, then adjust the API endpoints to match”
• Explaining bugs: “The login form submits but the session isn’t being persisted, I think it’s something with the cookie domain”
• Code review requests: “Look at the payment processing function and check if there are any race conditions”

It’s less useful for:

• Dictating exact code syntax (though Claude handles that anyway)
• Complex regex patterns or mathematical formulas
• Anything requiring precise special characters

The Habit Shift

The hardest part wasn’t the technical setup. It was breaking the habit of reaching for the keyboard.

For the first week, I had to consciously stop myself from typing. My fingers would start moving automatically, and I’d catch myself mid-keystroke. But once voice input became muscle memory, going back to typing felt painfully slow.

There’s also a thinking benefit. When you speak your prompts, you naturally structure them more clearly. You can’t type half a thought and then backspace—you have to articulate the whole idea. This leads to better prompts and better Claude output.

FAQ

Conclusion

The fastest keyboard in the world is still slower than speaking. Once you’ve trained yourself to describe what you want instead of typing it, you won’t go back. The setup takes ten minutes. The productivity gain lasts forever.