DEVELOPER GUIDE · JULY 2026

Talk to your editor like it owes you money.

Developers now type more prose than code — prompts, specs, review comments, commit messages — and typing is the slowest part of the job. Voice fixes that. Code itself is harder, but solvable. Here's the honest state of voice-to-code in 2026.

The bottleneck moved to prompts

AI-assisted development quietly changed what the keyboard is for. The code increasingly writes itself; the prompts don't. Specifying a change to Cursor or Claude Code — context, constraints, what "done" looks like — is now a substantial share of a working day, and most of us still type it at typing speed.

An illustrative example, not a lab measurement: take a 300-word prompt, roughly the size of a real feature spec with constraints and acceptance criteria. At a typical 40–45 words per minute, that's about seven minutes of keyboard time. Spoken at a relaxed conversational pace, it's under two. Your numbers will differ; the gap won't. And prompts are pure prose — exactly what dictation handles best. No symbols, no casing, no syntax. Just say what you want.

The three levels of voice-to-code

1. Docs, comments, commit messages

Start here. Zero risk, immediate payoff. README sections, doc comments, PR descriptions, review feedback, commit messages longer than "fix stuff." If you adopt nothing else from this article, adopt this.

2. AI-assistant prompts

The big one. Cursor, Claude Code, and Copilot Chat all take natural language, and they reward thoroughness — the more context you give, the better the diff. Long context dumps are painful to type and trivial to speak: "here's the file layout, here's what's broken, here's what I already tried, here's what done looks like." This is where voice outruns typing the most, because the input is English and the tool owns the syntax.

3. Actual code

Possible, with the right commands — and worth it for boilerplate, tests, config, and SQL. Dense algorithmic code is still faster to type, or to generate and then correct. Anyone who tells you otherwise is selling something. The two things that make code dictation viable at all are casing and symbols, so let's do those properly.

The casing problem — and the commands that solve it

Ask any developer who tried dictation years ago what broke, and you get the same answer: variable names were tough. "getUserName" comes out as "get user name" or "Getusername." Identifiers were the wall, and most people quietly went back to the keyboard.

The fix is case commands: you speak the casing, then the words.

CommandYou sayYou get
camel case"camel case get user name"getUserName
snake case"snake case get user name"get_user_name
pascal case"pascal case get user name"GetUserName
constant case"constant case get user name"GET_USER_NAME
kebab case"kebab case get user name"get-user-name

With those five, identifiers stop being the reason you reach for the keyboard. It feels awkward for a day, then it doesn't.

Spoken symbols

The other half of code-shaped text. LockedIn Flow's code mode maps spoken names to the symbols programmers actually say out loud:

You sayInsertedYou sayInserted
open paren / close paren( )single quote / double quote' "
open brace / close brace{ }backtick`
open bracket / close bracket[ ]bang!
arrow->question mark?
fat arrow=>at sign@
dot.hash#
comma,dollar$
colon:star*
semicolon;slash / backslash/ \
equals=pipe|
plus+underscore_
dash-less than / greater than< >

Why local matters more for developers

Think about what codebase-adjacent audio actually contains: internal API names, unreleased feature names, customer names read off a ticket, the odd connection string you dictated instead of typed. With cloud dictation, all of it goes to a third-party server — an unlogged channel for everything said near a keyboard. Many employers disallow cloud dictation for exactly this reason, and "but I only use it for prompts" isn't much of a defense, because prompts are where the internals are.

With on-device dictation, the audio never leaves the Mac, and the compliance conversation gets very short: nothing to review, because nothing goes anywhere. LockedIn Flow runs recognition on the Apple Neural Engine and cleanup on a local model — the full architecture is in our Wispr Flow comparison, and if you want to verify the "nothing leaves" part rather than believe it, here's how to test any dictation app, including us.

A workflow that actually works

Dictate the prompt, generate the code, dictate the review. Use voice where it's strongest — intent, context, constraints, feedback — and let the AI tool own syntax. In practice: dictate a paragraph of intent into Cursor or Claude Code, let it write the code, then dictate your review comments on the diff. Keyboard for the fraction that's genuinely code-shaped; voice for everything that's English.

LockedIn Flow types at the cursor in whatever app is frontmost, so it works in editors, terminals, and chat fields with nothing to integrate. Free 14-day trial on the download page; one-time pricing on the pricing page.

FREE 14-DAY TRIAL · NO CARD · NO ACCOUNT

Your prompts are prose. Speak them.

Everything unlocked for 14 days. Case commands, spoken symbols, code mode — all on-device.

Download for macOS

Written July 26, 2026. Tool names and capabilities change fast — the workflow advice ages better than the version numbers.