Skip to content
SpeakribeGet Speakribe
Use case

Dictation for Cursor

Prompting an AI editor is writing, not coding: long, specific, plain-English instructions. That is the part of the day where typing slows you down most, and where speaking is fastest. Hold a shortcut, describe the change you want, and it lands in Cursor's prompt box.

Cursor

export const TodoList = () => { ... }

In TodoList.tsx, load the todos from api.ts. Add loading and error states.

Why it helps here

Good prompts are long. You know exactly what you want changed, but describing it precisely costs two minutes of typing, so you type a short prompt instead, get a worse result, and iterate. Speaking removes the incentive to be terse.

Longer prompts, no extra effort

Speaking runs around four times faster than typing, so the detailed prompt costs about what the terse one used to. Better input, fewer rounds.

Your code stays on your machine

Transcription happens on your Mac. Whatever you describe about a private codebase is never sent to a transcription service, a distinction that matters if your employer has opinions about where source code goes.

Works in the terminal too

Speakribe types wherever the cursor is, so the same shortcut works in Cursor's prompt box, a commit message, or a terminal pane.

Things people say into Cursor

  • “In TodoList.tsx, load the todos from api.ts. Add loading and error states.”
  • “Refactor this into a custom hook, keep the same public API, and add JSDoc.”
  • “Write a test for the empty-input case and the duplicate-name case.”
  • “Explain why this effect re-runs on every render and suggest the smallest fix.”

Setting up for Cursor

Cursor is the one app on this list where the setup step that matters is not the shortcut — it is teaching the transcription your project's proper nouns, because a codebase is mostly proper nouns.

  1. Bind a chord your editor doesn't own

    Cursor inherits most of VS Code's keymap, which is dense. A modifier-only binding — holding both Option keys, say — sidesteps the whole map, and matters more here than in a browser because a collision inside an editor triggers a real command rather than doing nothing.

  2. Add your project's nouns to the custom-words list

    Open settings and add the names transcription has no way to guess: your repo, your internal packages, the two colleagues whose surnames appear in commit messages. This is a five-minute job you do once and it is the difference between a usable prompt and one you have to repair.

  3. Click into the prompt pane before you speak

    Text goes to the focused field. In Cursor that means the chat or composer pane specifically — if focus is still in the editor, your prompt gets typed into the file you are looking at, which is a memorable way to learn this.

  4. Say the file names, don't spell them

    Speak "TodoList dot tsx" the way you would to a colleague. Spelling out letters produces worse results than natural pronunciation, because the transcription is tuned for speech and not for dictated characters.

One dictation, start to finish

A refactor request, spoken in one take of about twenty-five seconds. The typed version of this is the prompt nobody writes — which is why the prompt people actually send is 'refactor this' and the result needs three more rounds.

You said
In TodoList.tsx there's a useEffect that refetches the todos every time the filter changes, and it's causing a flash of empty state. Move the fetching into a custom hook called useTodos, keep the same public API so the component doesn't change shape, and keep the previous data on screen while the new request is in flight. Add a test for the case where the filter changes twice before the first request resolves.
What landed

In TodoList.tsx there's a useEffect that refetches the todos every time the filter changes, and it's causing a flash of empty state. Move the fetching into a custom hook called useTodos, keep the same public API so the component doesn't change shape, and keep the previous data on screen while the new request is in flight. Add a test for the case where the filter changes twice before the first request resolves.

  • "useEffect" and "useTodos" kept their camel case. Hook names follow a pattern common enough on the web that transcription handles them; a name like "useOrgSeatQuota" is where the custom-words list starts earning its keep.
  • "TodoList.tsx" was spoken as "TodoList dot tsx" and came back punctuated correctly. Saying "T-O-D-O-List" would have come back worse — spelling is the failure mode here, not the fix.
  • The last sentence stayed a separate sentence rather than being glued to the one before it. That boundary came from a half-second pause, which is the only formatting control you have and, in practice, enough.

What it won't do in Cursor

It won't operate the editor

Speakribe types. It cannot accept a diff, open a file, run a terminal command or click Apply by voice. Everything after the prompt is still keyboard and mouse, and this is not a hands-free coding setup.

Code dictation is a bad idea

Speaking actual syntax — brackets, semicolons, camel case boundaries — is slower and less accurate than typing it. Dictate the intent and let the model write the code; that division is the whole reason this works in an AI editor and not in a plain one.

Unlisted internal names will be wrong

Anything invented inside your company is a coin flip until you add it to the custom-words list. The failure is quiet: you get a plausible near-miss like "Auth Kit" for "AuthKit", which reads fine and sends the model somewhere slightly wrong.

Terminal panes can block the shortcut

macOS lets an app stop other software from watching the keyboard, and terminals that enable Secure Keyboard Entry do exactly that. Speakribe shadows the binding through a second mechanism when it detects this, but a modifier-only shortcut is the arrangement that never notices the problem.

Questions people actually ask

Does Speakribe integrate with Cursor?
There is nothing to integrate. Speakribe types into whatever app has focus, exactly like a keyboard, so it works in Cursor without a plugin or extension.
Can it handle technical terms and file names?
Largely, yes. It is tuned for natural speech including technical vocabulary. Unusual internal names are the common miss, and the app has a custom-words list for exactly that.
Is my code sent anywhere?
No. Speech is transcribed entirely on your Mac. Speakribe has no server and no account.
Should I dictate code itself?
No, and it is worth being blunt about it. Speaking brackets and camel case is slower and less accurate than typing them. The reason dictation works well in Cursor is that you are describing a change in English and something else writes the syntax.
Will it type into the terminal inside Cursor?
Yes, the same as any other focused field. The exception is a terminal with Secure Keyboard Entry turned on, which macOS uses to stop apps reading the keyboard; Speakribe falls back to a second mechanism there, and a modifier-only shortcut avoids the situation entirely.

Ready to stop typing?

One payment. Every future update included.