Teaching a speech model to spell Claude Code

Say “can you check Claude Code for me later” to a good English speech model and there is a fair chance it writes “clawed code”. The model knows English very well. It knows product names coined in the last two years much less well, and when it is unsure it writes the words it does know.

For anyone who dictates prompts about software, that is most of the problem. The sentence comes out fine and the one word that mattered is wrong.

Two patterns

Once we started collecting mistakes, they fell into two groups. Compound names come back split into ordinary words: “Whisper Flow”, “Deep Seek”, “Mac OS”, “Data Dog”, “Distro Box”. And some names get written the way they sound: “clawed code”, “11 labs”, “Olama”, “Bazite”.

The tempting fix

The obvious approach is a long list of tech names and a fuzzy matcher that snaps anything close enough onto the nearest one. It works in a demo. Then someone says an ordinary word that happens to be one letter away from a product, and the correction becomes the mistake. With a long list, near-miss matching is exactly where wrong corrections come from.

So the built-in list only fixes mishearings that were actually observed. No fuzzy matching, no guessing. If the model has never been seen writing “Olama”, there is no rule for it.

Measuring it

We started from 138 candidate terms (AI products, developer tools, apps, operating systems) along with how a person actually pronounces each one. A synthetic voice read every term inside two carrier sentences, such as “Yesterday I tried … and it was pretty good.” The installed app transcribed those recordings with the same model and the same segmenting as a live dictation. Then the term was cut back out of each transcript and compared with its real spelling.

A synthetic voice is not your voice, which is a fair objection. But how a name is spelled depends on what the model knows about the language more than on the accent saying it, and that is the part this measures. Our own dictations agree: one of them came back with “Bazite”, the same mishearing the measurement had found.

Not breaking ordinary text

A correction list is only useful if it leaves everything else alone. Every version of the list is run over a pile of ordinary text, and every line it would change gets printed and read. A few rules came out of that. Text inside paths, URLs and identifiers is never touched. Casing is only restored for multi-word names and for words that are not ordinary English, so “fedora” the hat never turns into Fedora the distribution.

The list also stays out of the cleanup model's prompt. It runs before the model and again after it, so the model has no chance to undo a name.

The result

The rest is what your own dictionary is for. Your entries run before the built-in list, so your spelling always wins, and you can turn on sound-alike matching for a word you know you mumble. Next on the list is learning those entries from the corrections you already make by hand.