Why voice dictation mangles code terms, and what actually fixes it

Say “use effect” to most dictation tools and you'll get back “Use effect.” — capitalized like the start of a sentence, period added, because that's what good English grammar looks like. What you wanted was useEffect. The tool didn't mishear you. It heard you fine and then “fixed” what you said into something that looks more correct by the rules it was built to follow.

The cleanup step is the problem, not the transcription

Raw speech-to-text is honestly pretty good these days at just getting the words right. The part that breaks code terms happens after that, in the pass that's supposed to clean up filler words and fix punctuation. That pass is almost always tuned for prose — emails, messages, notes — where capitalizing sentence starts and correcting stray capitalization is exactly the right behavior. Applied to camelCase, snake_case, or a file path, the same rules are actively wrong. “Correct” English capitalization and correct code casing are different conventions, and a tool that only knows one of them will keep applying it everywhere.

It compounds with autocomplete-style spelling correction. Say “kubectl” or a library name that isn't a dictionary word, and a tool tuned to catch typos will sometimes swap it for the nearest real word it knows — silently, without flagging that it changed anything.

What actually has to be different

The fix isn't a smarter model — it's a different set of rules for a different kind of text. A dictation tool that handles code well has to treat identifiers, commands, paths, and URLs as text that survives untouched through cleanup, not text that gets run through the same grammar-correction pass as everything else. Casing that's already there — camelCase, PascalCase, snake_case — has to be preserved exactly rather than “corrected,” and the tool shouldn't invent new capitalization it can't justify from what was actually said.

VoxaType's developer mode works this way: technical terms are treated as protected content, and if a suggested cleanup would change one, that edit gets rejected in favor of a more conservative correction instead. The tradeoff is that developer mode is less aggressive about polishing your grammar than standard mode — which is the right tradeoff, since the whole point is leaving code exactly as spoken.