Voice dictation for Cursor and Claude Code on Mac

AI coding tools get better when the prompt includes the messy context around the task: what you are trying to change, what you already tried, which files feel risky, what tradeoffs matter, and what kind of answer you want back.

That context is often too slow to type. So people send thin prompts instead: "fix this bug", "refactor this", "why is this failing?" Then the assistant has to guess, ask follow-up questions, or make changes against the wrong mental model.

Voice dictation is useful here, but only if it has a review step. The first spoken version of a coding prompt can include private roadmap details, customer names, half-formed opinions, or irrelevant notes you needed to say out loud. Treat dictation as a capture layer, not an automatic send button.

Here is a workflow for using voice with Cursor, Claude Code, ChatGPT, or any coding assistant on Mac without dumping every raw thought straight into the tool.

Start with the change you want

The easiest spoken prompt to edit starts with the job.

Say the task first, then the background:

Help me diagnose why the marketing build fails. The likely area is the blog MDX loader. I changed frontmatter recently. I want you to inspect the schema, find the smallest fix, and avoid unrelated styling changes.

That is much better than starting with five minutes of history and hoping the actual request appears near the end. A clear opening gives the rest of the dictated prompt a shape.

For coding work, useful openers are plain:

"Find the bug in this failing test."
"Plan the smallest refactor for this component."
"Review this diff for regressions."
"Explain why this TypeScript error happens."
"Generate a patch, but do not touch unrelated files."

You are not trying to sound polished. You are giving the assistant a target before you add context.

Dictate context in short chunks

Long monologues feel efficient while you are speaking. They are slow to clean up afterward.

Break coding prompts into chunks instead:

Goal: what should change.
Scope: files, modules, or routes involved.
Constraints: what must not change.
Evidence: error messages, failing tests, screenshots, or behavior.
Output: plan, explanation, patch, review, or command.

This is especially useful in Cursor or Claude Code, where a prompt can turn into file edits quickly. The assistant does not just need more words. It needs the right boundaries.

For example, a dictated prompt might become:

Goal: make the onboarding modal keyboard accessible. Scope: only the modal component and tests. Constraint: keep the visual design the same. Evidence: Escape does not close it and focus escapes behind the dialog. Output: patch the issue and add a focused test.

That prompt is not fancy, but it is hard to misunderstand.

Use a local scratch space when the context is sensitive

Many developer prompts include things that should not be shared casually: unreleased product plans, customer examples, incident notes, internal API names, private repo details, or blunt assessments of a design.

If the prompt is sensitive, dictate into a local scratch document first. Clean it there. Then paste only the version you mean to send into Cursor, Claude Code, or a browser-based AI tool.

This review step matters because voice makes it easy to over-include. You may say a customer name while explaining why a bug matters. You may mention a private deadline. You may talk through two discarded ideas before finding the one useful instruction.

Local dictation keeps the speech-to-text step on your Mac while you decide what belongs in the final prompt. In SpeakLane, that usually means using the push-to-talk hotkey with auto-copy, dictating into Notes or a local editor, then pasting the cleaned prompt into the AI tool.

Say the section labels out loud

Section labels feel awkward for the first few attempts. They are worth it.

Say labels like "Goal", "Context", "Files", "Constraints", "Avoid", and "Output" while you dictate. They survive transcription well, and they turn a rambling prompt into something you can scan.

Try this pattern:

Goal: find a minimal fix for the failing checkout test. Context: the payment status now updates after a webhook. Files: the test file and the payment status helper. Avoid: changing the API route unless it is actually wrong. Output: explain the cause first, then patch it.

The labels do two jobs. They help the AI assistant follow your intent, and they make your own review faster before you send the prompt.

They also reduce the temptation to ask for everything at once. If you cannot name the output, you probably need a planning prompt before a coding prompt.

Keep exact tokens on the keyboard

Voice is good for context. The keyboard is still better for exact strings.

Be careful with:

File paths.
Function names.
CLI commands.
Environment variables.
Version numbers.
Error codes.
Feature flag names.

If the exact token matters, type it, paste it, or inspect it before sending. A dictated prompt that turns NEXT_PUBLIC_API_URL into a similar-looking phrase can waste more time than it saves.

A good hybrid workflow is to dictate the reasoning and paste the precise evidence:

Explain this error and propose the smallest fix. Here is the command I ran, and here is the exact output.

Then paste the command and output manually.

Choose speed or accuracy based on the prompt

Not every AI coding prompt deserves the same dictation setup.

Use a faster local model for rough ideation, product notes, or early debugging where you expect to edit heavily. Use a stronger model when the prompt includes technical words, names, acronyms, or long context that you do not want to correct sentence by sentence.

In SpeakLane, the practical controls are in Settings > Models. If your prompts often include repeated project terms, snippets can also clean up phrases before the transcript is inserted or saved.

The goal is not perfect transcription. The goal is a prompt that preserves the important context with less typing.

Keep a recovery trail

AI coding sessions move quickly. You dictate a prompt, edit it, paste it, run a command, change your mind, and realize the first version had an important detail.

That is where local history helps. A transcript history gives you a way to recover a dictated prompt without reconstructing it from memory. It is also useful for turning a good spoken debugging explanation into a ticket, PR comment, or handoff note later.

If you are experimenting with voice prompts, leave history enabled at first. You can adjust retention once you know how much of that trail you actually want to keep.

A repeatable coding prompt workflow

Use this the next time a coding assistant needs more context than you want to type:

Open a local scratch document or the prompt field.
Dictate the job first.
Add context in short labeled chunks.
Type or paste exact tokens, paths, commands, and errors.
Remove sensitive or irrelevant rough thinking.
Decide whether you want a plan, explanation, review, or patch.
Send the cleaned prompt.

That last distinction matters. A voice prompt can be rich enough to trigger a big response. Be explicit about the output you want before you hand it to the assistant.

Voice dictation will not make vague coding prompts good. It will make it easier to include the context that usually gets skipped. Speak the rough version locally, clean it into a real instruction, then send the prompt that gives your AI coding tool enough direction to be useful.