Why I Talk to My Computer (And Why You Should Too)

I started using speech-to-text for prompting AI agents because I heard it might be easier. That was the extent of my research—someone said "try it," so I did. I built my own tool, found a better free one (Super Whisper), and haven't looked back.

The initial draw was convenience. Sometimes explaining a complex idea takes thirty seconds to say but five minutes to type. But after using speech-to-text for a few months, I discovered the real benefit: you get drastically higher quality information when you speak than when you write.

The Problem with Writing Prompts

When we type, we aim for complete sentences. We try to be coherent, follow grammar, express fully-formed thoughts. The bar is high—higher than it needs to be for prompting an agent.

When we talk, the bar sits much lower. Thinking happens first, then talking, then writing. Each tier gets more polished and more constrained. But here's the thing: prompts don't need polish. They need completeness.

There's no penalty for extra information in a prompt. There is a penalty for missing information. If you write a lazy prompt that doesn't explain the full picture, the agent does a bad job because it doesn't fully understand. When we write, we get lazy—we don't want to fully explain our idea because turning thoughts into coherent sentences takes effort. But turning thoughts into spoken words? That's easy. You just word-vomit the entire feature description.

"I think the big issue is that when we write, we get lazy. Because we don't want to fully explain our idea because it's kind of difficult to turn our thoughts into coherent sentences. But it is easier to turn them into words that we just say out loud."

The /interview Command

I built a slash command called /interview that triggers an interview process where an agent asks me questions. The key benefit: it asks the questions I don't know to answer.

When trying to define a feature or gather requirements, being asked "what should we build?" is useless. But having an agent that knows what questions need answers—without answering them for you—works incredibly well.

The /interview command prompts the agent to conduct an information-gathering interview. The goal: extract comprehensive raw information through natural conversation, not create a polished document. By the end, you have a Q&A document containing questions and answers—a massive dump of relatively high quality data that serves as source material for specs or creative writing.

(See the full /interview command prompt at the end of this article)

Direct Quotes Matter

Here's something I didn't expect: having direct quotes makes your writing sound more natural. When you're doing creative or formal writing, the interview process where you answer in complete sentences by speaking produces authentic human thoughts. A lazily spoken sentence is higher quality than a lazily written sentence. Even the laziest spoken sentences can be surprisingly potent.

I used this approach to build case studies for my portfolio. I didn't want to spend time becoming an expert at writing case studies—I just wanted high-quality case studies that didn't sound like AI slop. I had the agent interview me on each project: technical stack, greatest achievements, learning lessons. The result was about 750 lines of Q&A responses, which I fed to Claude to build actual case study pages (you can view them here).

Those pages looked good because they used actual words I spoke, including quotes, written in a style similar to how I actually speak about these projects. The entire thing took an hour or two. I'm slow at writing—always have been. This workflow changed that.

Speech-to-Text for Spec-Driven Development

This connects to spec-driven development. When I'm working on a new project, I've gotten into the habit of doing much more spec-driven development. Agents don't make mistakes if you have a comprehensive enough specification, research, and plan.

Building a good spec is hard—it's difficult to think of all the specifications for a new component or feature. But if I describe things at a high level and begin this interview process where the agent proposes options and asks follow-up questions, by the end I have details about exactly what kind of component it is because I've answered questions I didn't even know to specify.

When it writes out the spec based on all that, it's just much higher quality.

The Recall vs. Recognition Advantage

A friend from Kazakhstan needed a visa recommendation letter. I didn't know how to write one, didn't want to write one myself, but wanted to put in the time. I had things I could say about him—but recall is harder than recognition. Being asked to come up with all the positive memories about someone is difficult. Being prompted with specific questions like "what was your favorite thing that happened when you guys were in high school?" makes it easier.

These specific questions prompt more interesting answers. Because it feels like you're talking to a human, you speak like you're talking to a human. You end up with authentic sentences. The LLM, which excels at eloquence, can take these interview answers and reconstruct something that still sounds like you.

Higher Quality Brainstorming

There's a reason people have brainstorming sessions in person or voice meetings instead of over Slack. Being able to talk ideas at that speed matters—you can think and say your thoughts out loud as you have those thoughts. That frictionless workflow is critical.

The /interview command's goal is to provoke interesting questions. You use your human brain—which excels at insight and creativity—while the LLM does the grunt work of identifying what needs to be handled. Maybe you didn't even know you needed to handle something, but now you do because it brought it up. Now it's up to you to come up with a creative solution.

What Changed

The most surprising benefit: quality jumped up more than I expected. What started as convenience became a quality multiplier. The output I get now is more likely to give me exactly what I want because I've specified it more. I've given more instructions, more constraints, more clarification. The rate at which it correctly interprets my request is just higher.

Going from 50 input tokens to 200 input tokens—even if 100 of those are filler words from speaking—is worth it. Those extra non-filler words provide clarity that improves the agent's response.

The Mental Shift

People aren't scared of talking to their computer—they're just not used to it. But voice models are now accurate enough to be reliable. In a quiet environment, they don't mess up. You can talk to them like a human and get a direct transcript.

Treat it like you're talking to a human. Have that casual "oh, actually also this" mindset. It opens you up to being way more vocal about random thoughts going through your head that might be relevant for the output. All those minor thoughts you wouldn't bother to include in a written prompt because it's too lazy—they get included in the vocal prompt.

When It Doesn't Work

Sometimes it's really loud and transcribes wrong—that's a pain. For quick things, typing is easier. With Claude Code, you can't use speech-to-text for special syntax like adding files and context with @ symbols, so I type those parts and speak the rest.

But for anything requiring detail, explanation, or creative thought? I talk to my computer. And you should too.

Appendix: The /interview Command Prompt

You are conducting an information-gathering interview. Your goal is to extract comprehensive raw information through natural conversation, not to create a polished document.

## Phase 1: Setup (Clarify Requirements)

Before starting the interview, clarify with the user:

1. **Subject**: What are we interviewing about? (e.g., "case study for Project X", "requirements for authentication system", "personal history for About page")
2. **Category/Depth**: What level of detail? (e.g., high-level overview, deep technical dive, user-facing content, internal documentation)
3. **Target Volume**: How much material do we need? (e.g., "enough for 2-page case study", "comprehensive feature spec", "5-minute read")

Present these as clear questions, gather answers, then confirm understanding before proceeding.

## Phase 2: Interview Process

Now conduct the interview:

- Ask **one question at a time**
- Let the user answer fully before moving to the next question
- Ask follow-up questions based on their answers
- Probe for specifics when answers are vague
- Track what ground you've covered and what still needs exploration
- **Do NOT** try to polish or rewrite their answers - capture them raw

Types of questions to ask:
- **Opening**: Broad questions to establish context
- **Probing**: Dig into specific areas they mention
- **Clarifying**: Ensure you understand what they mean
- **Comparative**: "How did this compare to...", "What made this different from..."
- **Concrete**: "Can you give an example?", "What specifically did you do?"
- **Completeness**: "What else should I know about X?", "What am I not asking about?"

**Keep going** until you have enough material to meet the target volume from Phase 1.

## Phase 3: Summary & Confirmation

When you feel you have sufficient information:

1. **Provide a brief executive summary** in this format:

​```
## Coverage Summary

**What we covered:**
- [Topic area 1] - [1-2 words on depth]
- [Topic area 2] - [1-2 words on depth]
- [Topic area 3] - [1-2 words on depth]

**What we didn't cover (but might be relevant):**
- [Potential gap 1]
- [Potential gap 2]
- [Potential gap 3]

Ready to wrap up? Or would you like to continue exploring any areas?
​```

2. **Wait for confirmation**: User can either:
   - Confirm we're done → Proceed to Phase 4
   - Continue interviewing specific areas → Return to Phase 2

## Phase 4: Save Document

Once confirmed, compile the interview into a structured document:

**Format:**
​```markdown
Question: [Your original question]
Answer: [User's answer - if they answered this across multiple exchanges, combine them together here]

Question: [Next question]
Answer: [Combined answer]

[Continue for all questions asked]
​```

**Important compilation rules:**
- Group all content related to the same question together, even if discussed at different times
- Preserve user's language and phrasing - don't polish or rewrite
- If a question led to multiple sub-questions, you can either:
  - List as separate Q&A pairs, OR
  - Combine under the main question with sub-bullets

**Filename**: Generate an appropriate name from the subject, formatted as `[relevant-name]-interview.md`

Examples:
- Subject "case study for Project Falcon" → `project-falcon-case-study-interview.md`
- Subject "requirements for authentication system" → `authentication-requirements-interview.md`
- Subject "personal background for About page" → `about-page-interview.md`

**Save location**: Save to the current working directory.

After saving, confirm with the user: "Saved to [filename] - [X] questions covering [brief subject description]"