Voice to text for developers

If you tried to dictate code, you'd hate it within a minute. Curly braces, camelCase, exact indentation, a variable named usrIdx — none of that is speakable, and pretending otherwise is how voice-to-text articles for developers lose the room. So let's set that aside completely.

Code isn't where the writing in your day lives anyway. Look at an actual working day and you'll find a surprising amount of prose: commit messages, pull request descriptions, code review comments, the long Slack message explaining a decision, the prompt you're feeding an AI assistant, the doc nobody updated, the ticket you're closing with a note. That writing is constant, it's English, and it's exactly where voice helps.

The prose-to-code ratio is higher than it feels

Coding feels like the whole job because it's the hard part. But measure a Tuesday honestly:

A few commits, each wanting a real message, not "fix stuff."
One or two PRs that need a description so a reviewer understands the why.
A handful of review comments on someone else's PR.
Several Slack threads — explaining a tradeoff, answering a question, unblocking someone.
A growing pile of prompts to an AI coding assistant, which are just instructions in plain English.
Maybe a doc, a runbook note, a ticket update, a standup summary.

None of that is code. All of it is typing. And a lot of it gets done badly — terse, vague, written in a hurry — precisely because typing it feels like overhead between you and the real work. That's the gap voice closes.

Where voice genuinely speeds a developer's day

Commit messages and PR descriptions

A good commit message explains why a change was made, not just what changed. A good PR description gives a reviewer the context to review well. Both are worth writing properly, and both are routinely skimped because nobody wants to type three paragraphs after the actual work is done.

Talking is the unlock. You already have the reasoning in your head — you just did the work. Speak it: "This refactors the retry logic because the old version retried on 4xx responses, which it shouldn't; now it only retries 5xx and network errors, and the backoff is capped at thirty seconds." That's a real PR description, spoken in fifteen seconds, that you'd never have typed in full. We go deeper on this in dictate commits and PRs.

Prompts to AI coding assistants

This one has quietly become a big part of the day. Prompting an assistant well means writing a clear, detailed instruction — context, constraint, what you've already tried, what you want. The better the prompt, the better the output, and detailed prompts are tedious to type.

Speaking them is natural, because a good prompt sounds exactly like explaining a problem to a colleague. You ramble a little, you add the constraint you just remembered — and that extra context, the part you'd have dropped to save typing, is often what gets you a usable answer the first time.

Code review comments

Review feedback is better when it explains reasoning, not just verdicts. "This could deadlock if two requests hit it at once — consider a lock around the cache write, or make the write idempotent" is more useful than "race condition here." The longer, kinder, more helpful comment is the one people don't type because they're busy. Spoken, it costs you nothing.

Slack, chat, and the long explanation

Half of senior engineering is explaining things in writing — a decision, a tradeoff, why the obvious fix is wrong. These messages are real writing, and they're faster spoken. Same for status updates and standup notes: "Yesterday I finished the migration script and tested it against staging; today I'm on the rollback path; I'm blocked on the prod database credentials from infra." Thirty seconds, done.

Docs, comments, and tickets

The doc-block above a gnarly function — the prose part, the human explanation of intent — is dictatable even if the code around it isn't. So is the README paragraph, the ADR, the ticket you're closing with a note for whoever reopens it later. Documentation gets written when writing it is cheap. Voice makes it cheaper.

The realistic workflow

The trick is not switching tools or breaking flow. The keyboard stays under your hands for code. Voice is for the moment you finish a chunk of work and need to say something about it — a message, a commit, a comment, a prompt.

A pattern that works: keep coding at the keyboard, and when you hit a prose moment, hold a key, talk, release, and the text lands where your cursor already is — in the terminal, the PR text box, the Slack input, the assistant's prompt field. Then back to code. No window to open, no app to switch to, no copy-paste. The voice layer only exists for the seconds you need it.

Where voice doesn't belong

Being honest about the limits:

Code itself. Already covered. Don't.
Anything with exact symbols. Regexes, shell one-liners, config syntax, identifiers. Type them.
Precise edits. Renaming a variable, fixing one character — keyboard.
Open-plan offices. If you can't say "this nil-checks the response before parsing" out loud without disturbing four people, voice isn't available to you in that room. That's a real constraint, not a footnote.

The line is clean: English prose, yes; code and symbols, no. Voice fills the first bucket and stays out of the second.

A note on RSI

For some developers this isn't about speed at all. Years of typing take a toll — wrists, hands, tendons — and on a bad day, cutting your keystroke count is a way to keep working without making things worse. If that's you, the prose parts of the day are exactly the keystrokes you can offload. We wrote separately about voice to text for RSI, and it's worth a read if your hands are part of the reason you're here.

Where Lispr fits

Lispr is a small macOS app built for exactly this kind of use — a developer who lives in the keyboard and just needs the prose to go faster. Hold the right Option key, speak, release; the text appears at your cursor in any app — terminal, editor, browser, Slack. No window, no account, around a 200-millisecond round trip. Audio goes over an encrypted connection, gets transcribed, and is discarded — nothing stored, nothing used to train a model, which matters when you're describing a system out loud. It was built by an engineering team, Codebridge, which is partly why it stays this far out of the way.

The honest summary

Voice to text will not write your code, and you shouldn't want it to. What it does is take the writing around the code — the commits, PRs, reviews, prompts, messages, and docs — and make it fast enough that you actually do it well instead of skimping. For most developers, that's the writing that was slowing the day down anyway.