Voice dictation in Cursor: write clearer coding prompts

A spoken coding request is useful when it preserves the problem, the relevant code and the limits of the change. A long prompt with a missing “do not” can be worse than a short typed one. In Cursor, treat the inserted text as a draft you review before sending.

This workflow is based on Wispr and Cursor documentation checked on September 11, 2026. The example is an original writing exercise, not a recording, measured speed comparison or demonstration of a completed code change. Our Wispr Flow review explains the product's broader trade-offs.

Separate dictation from the coding task

Wispr's IDE integration guide documents dictation, variable recognition and file tagging in Cursor on Mac and Windows. Flow supplies text to the focused input. Cursor then interprets the submitted request and works with the context available to it.

Cursor's Agent overview describes tools for reading files, editing and running terminal commands. Correct transcription does not establish that an agent's code change is correct, and a good code result does not establish that the dictation preserved every instruction. Check each stage independently.

Start in an empty Cursor chat input

Open the project and relevant file, then place the cursor in the chat input where you want the prompt. Use a small practice task in a project you can inspect. Before adding integrations, dictate one short sentence using the shortcut configured in your Flow app, stop recording and wait for the text.

Check that the text reached the chat input rather than the editor or integrated terminal. Do not switch windows while transcription is finishing. If no text appears, use the Flow insertion troubleshooting guide before changing language or vocabulary settings.

For IDE context, Wispr documents these additional steps:

1. In Flow, open Settings → Vibe coding.
2. Select Set up beside Variable recognition.
3. In Cursor, open the Command Palette with Cmd+Shift+P on Mac or Ctrl+Shift+P on Windows.
4. Run Toggle Screen Reader Accessibility Mode and confirm the Screen Reader Optimized indicator is on.
5. Complete the setup instructions in Flow and test a name visible in your editor.

Variable recognition is not a separate Flow on/off toggle: the documentation ties it to the IDE's screen reader mode and app detection. On Mac, Flow also needs Accessibility permission to read IDE context. If you do not need code-context reading, ordinary prompt dictation is still a separate thing to evaluate.

Give the spoken request four concrete parts

Use problem, location, constraints and verification. For an illustrative project containing src/lib/retry.ts, a request might be:

In the retry helper, requests keep retrying after authentication fails. Inspect src/lib/retry.ts and the related tests. Stop retries for HTTP 401. Keep the existing behavior for rate limits. Explain the cause before editing, then make the smallest change and run the relevant tests.

The file is a sample name, not a claim about your repository. Replace it with a real file you have selected in Cursor. The example's status codes are task requirements, not general advice that every application should handle authentication or rate limits this way.

Download the coding prompt worksheet to adapt this structure. Write the expected behavior down before speaking, especially the things that must remain unchanged.

Review the inserted text before submitting

Check these details against the task you intended:

• Location: does the attached reference point to the intended file, particularly when several directories contain the same basename?
• Exact values: does the text say 401, not 404, and is any identifier spelled with the correct casing?
• Constraints: does it preserve the existing rate-limit behavior and the instruction to explain before editing?
• Completion: does the agent have a clear change to make and a way to verify it?

The reviewed version for the example would still contain all four requirements. There is no supposed “raw Flow output” here because this article has not run that recording. When you test it, keep the raw inserted text separately from your edited prompt so you can measure the corrections.

Use typing or Cursor's file picker for exact tokens that dictation does not preserve. A mixed input workflow can be more practical than insisting every character must come from speech.

Check file tagging separately from dictionary changes

Wispr documents spoken patterns such as “at” or “tag” followed by a filename in Cursor chat. Keep the relevant file open in a tab or visible in the sidebar, and verify the resulting reference in Cursor. A textual @filename is not sufficient evidence that the intended file became attached context.

The current IDE guide says file tagging is suppressed in terminal panes and when a custom dictionary substitution occurred in the same dictation. If a filename stops tagging while a technical word is being corrected, try a separate dictation without that substitution or attach the file manually. Test the two features independently rather than adding more correction rules at once.

For repeated terminology errors, use the developer dictionary guide. For Vietnamese prompts containing English terms, check Vietnamese and mixed-language settings; language detection and file tagging are different mechanisms.

Review the resulting changes and measure the whole workflow

Before sending, confirm the agent's current mode and permissions match the task you intend. Cursor's agent security documentation says agent edits can be written directly to disk. Review the actual changed files and test results; an explanation in chat is not a substitute for inspecting the diff.

To compare dictation with typing, use comparable small tasks and include preparation, speaking or typing, transcript correction and file attachment time. Record agent execution and code-review time separately so a slow model response is not counted as dictation latency. Rotate which method you try first if repeating the exercise.

Keep the failed attempts. If names, numbers or negations require repeated corrections, shorten the spoken explanation and type those exact details. The useful outcome is a prompt you can trust with acceptable effort, not a high words-per-minute counter.

After the code change is ready, the voice-to-text commit and PR workflow helps turn your explanation into a message checked against the actual diff.

For a note with several actions, use the n8n transcript workflow to turn reviewed lines into task candidates.