Writing code by voice¶

Short answer: prose dictation is bad at code, because code is mostly symbols and identifiers rather than sentences. YazSes has a dedicated Spoken Code Mode that converts spoken symbols into punctuation and spoken words into cased identifiers, plus a git-phrase translator and a safety gate for the terminal. All of it runs offline.

Why ordinary dictation fails at code¶

Dictate "def sync open paren self close paren colon" into a normal speech-to-text engine and you get exactly that — an English sentence. What you wanted was:

def sync(self):

The engine has no way to know that "open paren" is a symbol rather than a word. Code mode is what supplies that missing intent. It runs in command mode, so turn it on and bind a command key (any key other than your dictation key):

yazses features enable code
yazses hotkey command right_ctrl
yazses restart

Then hold the command key and start the phrase with "code": "code def sync open paren self close paren colon" types def sync(self):.

Identifiers: say the style, then the words¶

Words stay words unless you name a case style in front of them. Say the style phrase, then the words of the identifier:

So "code def snake case get user name open paren snake case user id close paren colon" types def get_user_name(user_id):.

The identifier ends at the first of these:

• a symbol — "camel case user name equals none" types userName = none. Symbol words are converted first, so a word such as "dot" or "star" can never be part of an identifier;
• another style phrase — "snake case user id camel case account name" types user_id accountName;
• "end case", which is not typed — "return camel case user name end case if ready" types return userName if ready;
• the end of the phrase.

Words are lower-cased before casing, so "pascal case HTTP server" is HttpServer. A style phrase with no word after it, or followed by a number or punctuation, is typed as you said it. This only happens inside a "code …" phrase on the command key; ordinary dictation that mentions "camel case" is never touched. For existing text, yazses case (or the Voice Case Transform capability below) re-cases a selection. The grammar is unit-tested but has not yet been tried with a real microphone, so check what Whisper hears for the style phrase if one does not fire.

yazses features info code   # what it does and how to trigger it

Maths and LaTeX¶

If you write papers rather than programs, spoken maths is injected as LaTeX. It also runs in command mode, so it needs a command key:

yazses features enable math

Hold the command key and say "math x squared plus y squared" — it injects x^{2} + y^{2}. The leading "math" (or "maths", "formula", "equation") is required. Only the built-in grammar exists: Greek letters, the arithmetic operators, squared/cubed, square roots and the integral and sum symbols. Anything beyond it is typed as words, so check the output.

Driving git by voice¶

yazses gitvoice "create branch feature slash login"   # prints: git checkout -b feature/login

yazses gitvoice "<phrase>" turns a spoken git phrase into a git command and prints it with how to undo it; --run runs it, and a destructive one (force-push, hard reset, branch -D, discarding uncommitted changes) never runs without --yes. It is a command-line tool: there is no spoken confirmation and nothing is spoken back.

Say a branch name the way it is written: "create branch feature slash login" becomes git checkout -b feature/login, and the capitalisation you speak is kept, because git refs are case-sensitive. Most phrases it does not recognise are refused with a list of what it understands, but not all of them — always read the printed command before adding --run.

Terminal safety¶

Dictating into a shell is the highest-risk place a misrecognition can land. The terminal command safety gate exists for exactly that. It is on by default for new installs (the first start writes it into your config); yazses features enable cmdsafety turns it back on if you disabled it.

It intercepts commands that would be destructive before they run, rather than trusting that the transcription was correct.

Editor navigation and commands¶

Beyond text entry, a fast regex command grammar maps spoken phrases to real key sequences — "undo that", "save file", "go to line 42". Several optional capabilities extend this for development work:

Browse them all with yazses features, and see what any one of them does with yazses features info <name>.

Editor context¶

YazSes can prime the recogniser with context from your editor's language server, so identifiers already present in the file you are working in are more likely to be transcribed correctly. It is off by default:

[commands]
lsp_enabled = true
lsp_editor = "neovim"

You can also maintain a personal vocabulary of project-specific names the model keeps mishearing.

Honest limits¶

If voice coding is your primary interface, look hard at Talon. Talon is built around exactly this — a deep, scriptable voice-coding ecosystem with a large community grammar library. YazSes is dictation-first, with code mode and commands as strong built-in extras rather than a scripting platform. See the comparison; the two can coexist.

YazSes is the better pick when you want code dictation that works out of the box, is fully open-source, and shares one offline install with your prose dictation, meeting capture and transcription.

Related¶

• Macros & snippets
• Dictation over SSH — dictate into a remote dev box
• Personal vocabulary
• CLI reference