Dictating Prompts to Parallel Agents, Lane by Lane

The first time you run two coding agents side by side, something feels off, and it takes a while to name it. Each agent is fast. Each one, alone, would be a clear win. Together they should be twice the win. Instead the day feels more fragmented than it did with one, and you end the afternoon with less finished than you expected.

The reason is not the agents. It is the shape of the input they need. A coding agent runs on prose: "split the handler, keep the public signature, add a test for the timeout path." Prose is cheap to think and expensive to deliver, because delivering it means putting your hands and your attention into the right window at the right moment. With one agent, that moment lines up with your natural rhythm. With three, the moments arrive whenever they arrive, and each one interrupts whatever you were in the middle of.

This post is about the delivery problem, not the thinking problem. It is a practical workflow for dictating prompts into parallel agent lanes on a Mac, with the honest limits included. If you have not read Driving Claude Code with your voice, that post covers the single-lane basics; this one assumes you already run more than one.

Why parallel lanes punish typing specifically

A prompt has three costs: forming it, delivering it, and recovering afterwards. Forming it is unavoidable and mostly happens in your head. Delivering it, when you type, means switching focus to the agent's terminal, finding the input line, typing forty to eighty words, and hitting return. Recovering means getting back to the thing you were doing before the agent asked.

With a single lane, the delivery cost is small because you were probably already looking at that terminal. With parallel lanes, you almost never are. Lane one asks a question while you are reading lane two's diff. The question is easy; the answer is one sentence. But answering it means leaving the diff, and when you come back, you re-read the last thirty lines to find where you were.

Multiply by every redirect, every "yes, continue," every "no, the other file," and the overhead compounds. Parallel lanes do not fail because agents are slow. They fail because you become the message bus, and a message bus that has to physically move between windows has terrible latency.

Voice removes most of the delivery cost. You keep your eyes on the diff, hold a key, say the sentence, release. The words land in the agent's input field. You never left.

The setup that works

Here is the setup, kept deliberately boring.

Hotkey, not a window. Keebye lives in the menu bar and listens for a hold-or-tap hotkey (Right Command by default; Fn and Right Option are the other options, and Escape cancels a dictation in progress). There is no app window to open and no mode to enter. Hold, speak, release. This matters more than it sounds: a dictation tool that needs its own window is just one more lane.

Insertion into the focused field. The transcript is inserted wherever your cursor is. By default that is a paste, with terminal-aware chunking so a long prompt does not overrun a shell. If you run agents inside tmux or over SSH, where paste behaves badly, there is an opt-in typing mode that injects the text as Unicode keystrokes instead; dictation that survives the terminal explains when to flip it.

Batch, not streaming. Keebye transcribes on key release, as one utterance. You will not see words appear as you speak. For prompting, this is the right trade: you want the whole sentence to land at once, cleaned up, rather than watch it materialise word by word while the agent's input already has half a thought in it.

Everything on-device. Transcription runs locally (an English-tuned default model, or a 25-language model if you opt in). After the model download, it works with Wi-Fi off. For agent prompting this is less about privacy theatre and more about latency: there is no round trip, so a short prompt is ready almost as soon as you release the key.

A lane-switching rhythm

The workflow that ended up sticking has three habits.

Eyes stay on the lane that needs judgment. At any moment, one lane is where your attention belongs, usually a diff or a test output. That is the lane you read. The others only get short verbal instructions. When lane two needs a decision, you glance, click into its input, hold the key, say the decision, release, and click back. The click is the only mechanical cost; the sentence itself is free.

Prompts get spoken as complete sentences. Agents handle full sentences better than telegraphic fragments, and dictation produces full sentences naturally because that is how people talk. "Revert the schema change but keep the API rename, then rerun the migration and show me the output" is a fine spoken prompt. It is a tedious typed one.

Fillers get stripped, meaning does not. Keebye's cleanup is rule-based by default: it removes the "um," the "uh," the repeated word, and leaves your wording alone. There is an optional on-device local-LLM polish for tidier sentences, backed by a fidelity guard that falls back to the literal transcript when the polished version shows severe token loss, expansion, or repetition. That guard is a heuristic, not a semantic check: it does not verify the polished text preserved your meaning or a negation. For prompting an agent, most people leave the polish off; a literal transcript is exactly what you said, and that is what you want the agent to run.

What voice is good for, lane by lane

Not every prompt wants to be spoken. After a few months, this is roughly the split.

Redirects and continuations: always voice. "Keep going." "No, the other config." "Add a test for the empty case and rerun." These are the highest-volume prompts in a parallel session and they are all one breath long.

Review feedback: mostly voice. Reading a diff and narrating what is wrong with it is natural. "The retry loop swallows the error, log it before the sleep, and cap the attempts at five." Dictation captures this at speaking pace while your eyes stay on the code.

Initial task briefs: mixed. A long, structured brief with file paths and constraints still benefits from typing, or from dictating a rough version and editing it. Voice is fine for the prose; exact identifiers are easier typed. The custom dictionary helps here: add your project's module names and recurring jargon once, and they stop being transcribed as their nearest English word.

Anything with code: typed. Dictating a regex is a bad time. Dictate the instruction ("write a regex that matches the version header"), not the artifact.

Honest limits

Some of these are Keebye's; some are the category's.

First-dictation latency. The microphone warms up after the first dictation of a session and keeps a 500 ms pre-roll after that. The very first hold of the day can pay a stream-start cost, and a word spoken before the buffer engaged can clip. Why dictation apps eat your first word covers the mechanics.

Accuracy on identifiers. Snake-case variable names and internal acronyms are where any speech model struggles. The dictionary reduces this, but it does not eliminate it. Read the prompt before you hit return on anything destructive.

Secure fields. Keebye refuses to insert into password and secure input fields. This is intentional and occasionally inconvenient when a terminal prompt is asking for a passphrase.

No voice commands. There is no "new line" or "select all" vocabulary. Keebye is a dictation tool, not a voice control layer. Navigation between lanes is still a click or a keyboard shortcut.

macOS only. The Windows build is not shipped.

Where to go next

If your agents live mostly in one editor, the Cursor and Claude Code guides have the per-tool specifics. If you are choosing between dictation apps for this workflow, Keebye vs Superwhisper is an honest comparison that includes where Superwhisper fits better.

The short version of everything above: parallel agents do not need you to type faster. They need you to stop being the slowest hop between them. Keep your eyes on the lane that needs judgment and speak to the rest.