Ask a developer how much of their week goes into writing code and the honest answer is usually “less than you’d think.” The rest is prose: pull request descriptions, review comments, tickets, commit messages, design docs, incident updates, Slack threads. And since 2025, a growing share of it is instructions for AI coding tools, where the quality of the output depends almost entirely on how much context you bothered to type.
That prose is where voice dictation earns its place in a developer’s setup. Code itself is not, and we would rather say that in the first paragraph than let you find out after a week of fighting your editor.
Dikto is not a voice-coding tool. It will not write a for loop, a regex, or a shell command reliably, and its AI cleanup is designed to make language read well, which is exactly the wrong thing to do to syntax. What it does well is turn two minutes of talking into the pull request description, the review comment, or the agent prompt you would otherwise have shortened because typing it felt like a chore.
The short version
- Dictate the prose, type the code. PR descriptions, review comments, tickets, docs, commit bodies, and prompts for AI coding agents are all natural-language writing. Syntax is not.
- Prompting AI coding tools is the biggest win. Spoken prompts come out longer and more specific than typed ones, and specificity is what makes an agent’s first attempt usable.
- Teach the tool your vocabulary. Framework names, service names, and internal terms are where general transcription stumbles; a custom dictionary fixes most of it.
- Check what leaves your machine. Dikto is cloud-only. Anything you dictate or select for an AI action is sent for processing, so your company’s policy on source code and customer data applies. Never dictate a secret.
- If you need hands-free coding, use a voice-coding tool. Talon, Cursorless, and macOS Voice Control are built for that job. A dictation app complements them rather than replacing them.
Where a developer’s words actually go
Before deciding whether dictation is worth it, it helps to be honest about the inventory. In a typical week, the natural-language writing looks something like this:
- Pull request descriptions: what changed, why, what you considered and rejected, how to test it, what to watch after deploy.
- Code review comments: the difference between “nit: rename” and a comment that explains the failure mode you are worried about.
- Tickets and bug reports: steps to reproduce, expected versus actual behaviour, what you already ruled out.
- Commit messages: the subject line is short, but the body — the why — is exactly the part people skip.
- Design docs and ADRs: context, options, trade-offs, decision.
- Incident and status updates: written under pressure, read by people who were not in the room.
- Chat: the long Slack explanation you give the same way three times a month.
- Prompts for AI coding tools: Claude Code, Cursor, GitHub Copilot Chat, Codex, and the rest.
Almost all of it suffers from the same problem: it is written by someone who wants to get back to the code, so it ends up shorter than the reader needs. Conversational speech runs at something like 130 to 150 words a minute; even a fast typist is well below that, and most people’s typing slows further when they are composing rather than copying. The practical effect is not “you save X minutes.” It is that the thorough version of the PR description stops costing more than the lazy one.
Prompting AI coding agents by voice
This is the use case that has changed the most, and the one where dictation pays off fastest.
An AI coding agent is only as good as the brief it receives. The prompts that produce a usable first attempt tend to contain the same things: the goal, the constraints, where in the codebase to look, what not to touch, and how to know the job is done. The prompts people actually type are usually one line, because typing the full brief feels like writing a ticket for a colleague who is sitting right there.
Spoken, the full brief takes about as long as explaining it out loud to that colleague — which is what it is. A raw spoken prompt might go:
“okay so the retry logic in the payments webhook handler is swallowing the error on the third attempt um I want it to log the error with the event ID and then rethrow so the queue marks it failed don’t change the backoff timings and don’t touch the other handlers there’s a test file next to it add a test for the third failure and run the existing tests before you finish”
After cleanup, the agent receives:
The retry logic in the payments webhook handler swallows the error on the third attempt. I want it to log the error with the event ID and then rethrow, so the queue marks the job as failed. Don’t change the backoff timings and don’t touch the other handlers. There’s a test file next to it: add a test for the third failure, and run the existing tests before you finish.
Nothing in that prompt is code. It is a clear brief, and it took twenty seconds to say.
A few habits make spoken prompts better:
- Say the constraints out loud. “Don’t change the public API,” “keep the diff small,” “ask before adding a dependency.” These are the things people omit when typing and regret when reviewing.
- Name the verification step. “Run the tests,” “show me the diff before committing,” “explain the change in two sentences.” Agents follow explicit finish lines far better than implied ones.
- Type the identifiers afterwards if they matter. If the prompt hinges on an exact function or file name, dictate the sentence and then fix the name by hand, or paste it. Agents are forgiving about prose and unforgiving about a misspelled path.
One practical warning for terminal-based agents. Dikto inserts text wherever your cursor is, and a terminal prompt is a text field like any other. But terminals differ in how they handle multi-line input: in some, a newline in inserted text is treated as pressing Enter. Before you rely on it, dictate a two-paragraph test prompt into your own terminal and see whether it arrives as one message or submits halfway. The fix, when needed, is usually a setting in the agent or terminal, or simply dictating the prompt as a single paragraph.
What not to dictate
This list is short, and it is worth taking seriously.
Code syntax. Brackets, operators, indentation, and exact casing are not natural language. Dictation engines transcribe what they hear as words, and an AI cleanup pass then tries to make those words read like good prose — capitalising, punctuating, “correcting.” That is helpful in an email and destructive in a code block. If you want to write code by voice, you need a tool that treats speech as commands rather than as text; more on that below.
Commands you are about to execute. A shell command that was transcribed slightly wrong is worse than one you typed slowly. Dictate the explanation; type or paste the command.
Secrets. API keys, tokens, passwords, connection strings, customer data. Not in a dictation, not in a prompt, not in a custom dictionary. This is true of every cloud tool, but it bears repeating for dictation because speaking something aloud feels less like “sending” it than pasting does.
Anything your employer’s policy says stays inside. Many companies have rules about which third-party services may receive source code, internal architecture detail, or customer information. Dictating a sentence about a system, or selecting a block of text and running an AI action on it, sends that content to a cloud service for processing. If you are not sure what your policy allows, ask before you build a habit.
Setting it up for development work
Pick a shortcut that does not collide with your editor. IDEs claim a lot of key combinations. Choose something your editor, terminal, and window manager do not use, or map dictation to a spare mouse button so your hands never leave their resting position.
Build your dictionary on day one. The words a general engine gets wrong are predictable: framework and library names, cloud services, your product’s internal nouns, your colleagues’ names, and acronyms that sound like words. Add the twenty or thirty you use most — the database you run, the queue, the frontend framework, the monitoring tool, the service names in your architecture. In Dikto, dictionary terms and saved context are stored on our servers and sent for processing so they can improve recognition, which is precisely why they must never contain a secret. Use your judgement about internal codenames, in line with your company’s policy.
Use the selection actions on your own drafts. Dikto’s double press opens AI actions on selected text: rewrite, translate, summarise, fix spelling. For developers the useful ones are the unglamorous ones: tighten a rambling review comment, fix the spelling in a README section, or turn a long, stream-of-consciousness incident note into something a stakeholder can read. Be selective about what you select: an AI action on a block of proprietary code sends that code for processing, exactly like a dictation would.
Four workflows that pay off quickly
The PR description in ninety seconds. When the diff is done, before you open the review, dictate four things in order: what changed, why, what you considered and rejected, and how to test it. The “rejected alternatives” part is the one reviewers value most and authors write least; spoken, it costs almost nothing.
Review comments that explain themselves. Instead of “this could race,” say what you are worried about: which two paths, under what load, and what the user would see. A comment that explains its reasoning gets a better response and fewer defensive replies.
Commit bodies. Type the subject line in whatever convention your team uses. Dictate the body — the why — underneath. Six months from now, git blame will thank you.
Incident updates. Under pressure, typing becomes terse. Dictating “what we know, what we don’t know yet, what we are doing next, when the next update is” produces a status message people can actually act on.
For developers who work in a second language
A large share of the world’s developers write in English all day without it being their first language. The code is fine; the pull request description, the design doc, and the reply to a US colleague’s thread take longer than they should.
Dikto lets you dictate in your own language and have the text come out in another — speak French, German, Spanish, Italian, or Dutch, and insert English. For explaining a design decision or writing a detailed bug report, thinking in your native language and shipping in English is a meaningfully different experience from composing in your second language at half speed. We are not the only tool that does this — Typeless, Spokenly, and TypeWhisper all offer some form of speak-one-language-write-another — so try more than one. Our longer write-up is in how to translate with your voice.
If what you actually want is hands-free coding
Some developers come to dictation because typing hurts — wrist pain, tendon problems, RSI. If you need to write code without the keyboard, a dictation app is the wrong primary tool, and you should look at the category built for it:
- Talon is the long-standing voice-control system used by developers who code entirely by voice, with community command sets and eye-tracking support. It has a learning curve measured in weeks, not minutes.
- Cursorless is a VS Code extension, built on Talon, that lets you edit code structurally by voice — “take the next function,” “change that argument” — rather than dictating characters.
- macOS Voice Control, built into the operating system, gives you commands, clicking, and navigation without installing anything.
Check each project’s current status and platform support before committing to one. They coexist well with a dictation app: the voice-coding tool handles syntax and navigation, dictation handles the paragraphs. If pain is the reason you are reading this, please also talk to a clinician; tooling is a help, not a treatment.
Choosing a dictation tool as a developer
The general-purpose AI dictation apps on the Mac — Dikto, Wispr Flow, Superwhisper, Typeless, MacWhisper, and others — all handle the prose side of development work. They differ in ways that matter to developers specifically:
- Where processing happens. Some run small models locally, some are hybrid, some are cloud-only. Dikto is cloud-only: there is no offline mode, and audio leaves your Mac. The app’s “AI provider” setting uses “Mistral (EU)” by default, with OpenAI as an opt-in option; our privacy policy describes the processing and what is and is not retained. If your employer forbids sending anything to a cloud service, a local-only tool is the right answer and you should pick one.
- Developer-specific integrations. Wispr Flow, for example, markets features aimed at AI code editors, such as recognising file and variable names. If that is your main need, test it on your own codebase.
- Price and limits. Dikto’s free plan gives you higher daily limits for the first seven days, then 15 minutes of dictation (about 2,000 words) and 10 AI actions per week, with no credit card. Pro is €9 a month or €89 a year for unlimited dictation. The side-by-side comparison with the rest of the market is in our guide to the best dictation apps for Mac.
Frequently asked questions
Can I write code with Dikto? Not reliably, and we do not recommend trying. Dikto is built to produce clean natural language, and its cleanup works against syntax. Use it for everything around the code, and use a voice-coding tool if you need to write code by voice.
Does it work in my IDE and terminal? The global shortcut inserts text into the app that has focus, including editors, chat panels, and terminals. Test multi-line input in your terminal before you depend on it, as described above.
Will it understand technical terms? Common ones, usually. The long tail — your service names, niche libraries, acronyms — is what the custom dictionary is for. Expect to add terms during the first week.
Is it safe to dictate about proprietary code? That is your employer’s call, not ours. The facts you need are these: Dikto is cloud-only, dictated audio and any text you run an AI action on are sent for processing, and saved dictionary terms and context persist on our servers until you change them or delete your account. Never dictate secrets under any policy.
Is dictation actually faster than typing for a developer who types quickly? For short, precise text, often not. For long explanations — PR descriptions, design reasoning, detailed prompts — the gain comes less from raw speed and more from the fact that you stop abbreviating.
In summary
The code is the part of a developer’s job that voice handles worst, and the prose around it is the part it handles best. Dictate the pull request, the review, the ticket, the doc, and above all the brief you give your AI coding agent; keep typing the syntax, the commands, and anything secret.
If that split matches how you work, you can try Dikto free without a credit card, build your dictionary in the first week, and see whether your PR descriptions get longer before your days do.