July 18, 2026

I Would Not Let a Voice Tool Press Enter in My Terminal

Developer dictating near a keyboard with a subtle safety lock motif
Editorial illustration: In a terminal, voice input should insert text for review, not decide when a command runs.

The line I would not cross

I am happy to dictate a rough prompt. I am happy to dictate a commit message. I would not hand a voice tool permission to decide when a terminal command is ready to run. One bad transcript in Slack is awkward. One bad transcript followed by Enter can be a mess.

A developer in a ClaudeAI thread put this better than I could. They wanted terminal defaults that insert text only, a visible pre-send buffer, quick undo, per-app cleanup rules, custom vocabulary, and a record showing what was heard, cleaned, and delivered.

Code is not ordinary prose

The same cleanup that makes a rough note sound nicer can damage code, shell flags, filenames, quoted strings, and commands. I do not want a model tidying a symbol because it thinks the sentence will read better. That is not polish. It is an uninvited edit.

I would keep technical dictation in a mode that preserves the raw text. I would also teach the tool the names it keeps missing: repositories, packages, customer projects, command flags, and acronyms. That is less magical than generic AI cleanup, but it is much more useful.

The safe version of voice coding

For me, the line is simple. Voice can get text into the focused field. I decide when it is ready to send. That keeps dictation on the input side of the boundary and leaves execution where it belongs, with the person at the keyboard.

More automation is not automatically better. In a terminal, the boring control is the feature I want most.

The small pause that keeps me sane

There is a useful little ritual in coding: I say the thing, I read the thing, then I decide whether it should run. Voice does not need to remove that pause. In fact, I think the pause is the whole point. It gives me the speed of speaking without pretending that a transcription model understands the consequences of a shell command.

I would rather have a tool that feels slightly less magical and slightly more predictable. Put the words in the terminal. Leave the cursor there. Let me look at the flags, the path, the quoted string, and the command substitution before anything happens.

Where offline helps developers too

There is a privacy angle here as well. Sometimes the prompt contains a client name, a secret-looking path, an internal package, or a fragment of code I would not casually send to another service. A local model gives me a different option for those moments, while a cloud model can still be useful when I choose it.

That’s why the local-versus-cloud choice in DictaFlow interests me more than yet another autonomous feature. I want a fast input layer that stays under my control, especially when the thing in front of me can actually do something.

The threads I read