When you type a prompt to an AI coding tool, you compress. You skip context. You leave out the reasoning. A prompt that should be 80 words comes out as 12.
When you speak the same prompt, something different happens. You explain. You include background. You describe what you already tried. The AI gets enough context to actually help.
The prompt length problem
Here's a typical typed prompt for building a pricing page:
"Add a pricing section with three tiers"
Seven words. The AI will ask follow-up questions or guess wrong about layout, styling, content, and behavior.
Here's what the same developer says out loud:
"I need a pricing section with three tiers. The free tier should highlight the trial limits. The paid tier is the main one — make it visually prominent with an accent border. Include a comparison with subscription competitors showing the long-term savings. Put a note at the bottom about version upgrades."
68 words. Same developer, same intent. Speaking removes the friction that causes compression.
Why voice produces better prompts
You describe instead of command
Typing encourages imperative language: "fix this," "add that." Speaking naturally produces descriptive explanations that include reasoning, constraints, and goals.
A typed instruction says what. A spoken instruction says what, why, and how it should feel. AI tools work dramatically better with the latter.
You don't self-edit mid-thought
When you type, you constantly rewrite. You delete half a sentence because it sounds too long. You compress a paragraph into a phrase. This self-editing strips context that the AI needs.
When you speak, the words come out in order. You might ramble. You might restart a sentence. But the full thought survives. AI tools handle filler words and conversational phrasing without issue — they extract the meaning regardless.
You front-load context naturally
When explaining something out loud, you instinctively start with background before getting to the request. "So we have this API that handles checkout, and right now it validates the email on the frontend, but we need server-side validation too because..."
This mirrors ideal prompt structure: context first, request second. When typing, most people skip straight to the request because adding context feels like work.
Techniques for voice prompting
Just start talking
Stream-of-consciousness speech works. A rambling 80-word prompt that wanders through the problem space often outperforms a crisp 15-word instruction. Include half-formed theories and constraints. The AI extracts what's relevant.
Don't clean up for the AI
Casual speech, contractions, and imperfect sentences are fine. You don't need to enunciate carefully or speak in complete sentences. Meaning matters more than formality.
Start with context, end with the request
Describe what exists, what's happening, why, and then what you want. This takes about 10 seconds and eliminates follow-up questions.
Include your preferences
Add aesthetic preferences, design opinions, and specific constraints. "I want it minimal, not bulky" or "Use the same spacing pattern as the hero section." Voice makes including this kind of nuance effortless.
Use voice for the first prompt, type for follow-ups
The initial setup prompt benefits most from voice — it needs the most context. Shorter iterative responses ("yes, but make it wider" or "add a hover state") may be faster typed.
Describe what you see
When you're looking at a layout issue or a bug, describe it out loud while looking at it. "The sidebar is overlapping the main content when the window is narrower than about 900 pixels." Pair with a screenshot for comprehensive context.
Real patterns from daily use
The context-setter
One comprehensive opening prompt (60–150 words spoken) followed by short follow-ups. Voice excels for the setup; follow-ups use whichever method is faster.
"Help me think through this"
Brainstorming prompts where you want ideas and analysis, not code. These feel too open-ended to type but sound natural spoken: "I'm trying to figure out whether to use a single table or split this into two. Here's the tradeoff..."
Relaying feedback as a story
Retell a bug report or feature request conversationally: "A user said the export is missing timestamps, and when they try to import it into Notion the formatting breaks." This is exactly how you'd describe the problem to a coworker.
Describing what you see on screen
"The chart is rendering but the labels on the x-axis are getting cut off on mobile. The legend is taking up too much space. I think we need to move it below the chart and truncate the labels after about 8 characters."
When to use voice vs. typing
Voice works better for:
- Initial prompts needing context and explanation
- Describing bugs, requirements, or desired behavior
- Brainstorming and thinking aloud
- Long-form writing — Slack messages, code review comments, docs
- Anything you can explain faster than type
Typing works better for:
- Short follow-ups ("yes," "try the other approach")
- Precise code snippets or syntax
- Copy-pasting existing content
- Situations where you can't speak (meetings, shared offices)
Most people settle into a mixed approach: dictate the substantive prompts, type the quick ones.
Try it
- Download Vext — free trial, no account required
- Pick a hotkey
- Enable YOLO Mode for terminal-based AI agents
- Start with one workflow and commit to voice prompting for a full day
The shift feels awkward for about 30 minutes. After that, typing prompts starts to feel like the slow way.