CC-201b · Module 3
Dictation Workflows
3 min read
Speaking is three to five times faster than typing. That speed difference compounds into a qualitative difference in prompt quality. When typing is the bottleneck, developers write the 80% that conveys the core idea and skip the 20% that provides nuance, edge cases, and micro-instructions. When dictation removes the bottleneck, that 20% flows naturally. You describe the happy path and the error cases. You mention the constraint you almost forgot. You add the "oh, and make sure it handles null inputs" that would have been a follow-up prompt if you were typing.
The brain dump pattern makes dictation reliable. Start with a framing statement: "I am about to dictate my entire thinking on this feature. I might contradict myself. Once you process everything, come back and interview me with clarifying questions before doing anything." This creates an intentional two-phase workflow. Phase one: you speak freely without worrying about structure or consistency. Phase two: Claude identifies the conflicts, asks targeted questions, and builds a clean specification from your raw input. The result is a prompt that captures your full thinking without the rough edges.
Do This
- Use the brain dump preamble: "I might contradict myself — interview me to clarify"
- Speak freely and include edge cases, constraints, and preferences you would skip when typing
- Pair dictation with Plan mode for complex features — dictate the requirements, plan the approach, then execute
- Ask Claude to summarize your dictation back in 3-4 sentences before executing
Avoid This
- Dictate directly into CLAUDE.md — voice transcripts are low information density and waste tokens
- Assume Claude understood a rambling 500-word dictation perfectly — always verify understanding
- Type half-hearted prompts when you could dictate richer ones in less time
- Skip the clarification step for complex requirements — one misunderstood intent derails everything