Voice coding session pace: batch the prompts, then go quiet during the run

A voice coding session moves at only two real speeds: the burst, where you spill your ideas into prompts, and the run, where the agent works and you stay out of its way. Most frustration in AI-assisted work comes from living in a third speed that does not exist, which is the micro-interrupt, where you send a new instruction every forty seconds because a thought just occurred to you. The micro-interrupt feels productive, but it resets the agent's context, thrashes the thread, and produces a diff that belongs to no single idea. Recognizing that bursts and runs are the only speeds is the first half of learning a voice coding session pace that actually steers the work.

Why does voice make this worse? Because speaking is so fast that a thought arriving becomes an instruction in five seconds, and the tool happily executes it. With typing, the friction of the keyboard naturally filters thoughts; with voice, every spark is a command, and the agent dutifully chases them all. The fix is not a slower voice; it is a deliberate two-phase rhythm. During the burst, allow all the sparks out. During the run, close the microphone metaphorically and let the work happen. The discipline of the closed mic is the entire art of living with a capable agent, and it is a discipline you can practice in a single afternoon.

The run length is where beginners and veterans diverge. A beginner lets the agent run to completion and then panics at a giant diff. A veteran cuts the work into runs that end at reviewable boundaries, such as one function, one test file, or one screen, and treats each boundary as a checkpoint. Say the boundary out loud as you start the burst: I want the pricing logic done and one test for it, nothing else. Speaking the boundary is what keeps the run honest, because the agent cannot read the size of your ambition from made-up commands; it can only read the words you give it. Voice pace control is mostly boundary control.

There is a rhythm you can feel: burst, run, read, decide, burst again. The read and decide step is not dead time, and treating it as dead time is exactly what drives people back into micro-interrupting. If a check pull takes ninety seconds of reading, that is ninety seconds of the most valuable work in the session, since it is the only part where your judgment touches the code. When you finish a run and the next burst does not come naturally, that is a signal, not a failure: either the task needs a walk, or the agent's work needs a second read. Both are legitimate next steps that deserve to be said out loud and scheduled.

The burst works best as a ritual: before the agent starts anything, spill every idea you have about the task, even the half-formed ones, in one uninterrupted block. The classic productivity author would call this brain-dumping; the practical benefit here is that a voice coding session begins with your complete mental model rather than with whatever thought is loudest. Say the five ideas each in one sentence: add the retry, rename the module, extract the parser, cover the empty state, and remove the dead path. Five sentences, maybe ninety seconds, and the agent now holds the landscape of the change before it writes a single line.

Ideas that are not spilled usually get re-injected mid-run by the micro-interrupt, so spilling is not just organization, it is defense. When every idea is already on the record, the thought I still need to handle retries arrives as a reminder rather than an emergency, and you can add it to the next burst with a sentence and a breath. Announce the spill to the agent explicitly: here are five ideas, do not start yet, just acknowledge them. Then number them so the follow-ups can refer to them by name: idea two is the retry. Numbered ideas survive long runs without ambiguity, and they give the agent a stable vocabulary to check decisions against.

Spilling also reveals the conflicts between your own ideas, and it is much cheaper to discover the conflict in the burst than in the run. Say: idea one says move the parser into its own module, but idea five says delete the dead path that the parser serves, which means the parser might be the dead path, and now I need to check the callers. The agent can answer that check immediately, or you can let it run afterwards. A spoken self-contradiction is the most productive moment in a session, and it happens more often when you are allowed to think out loud instead of polishing a prompt for a minute before sending it.

Time-box the burst: ninety seconds for a small task, three minutes for a big one, and do not let the spill become a planning meeting with yourself. If ideas keep coming past the time-box, capture them as a list for later rather than reopening the burst, since the point of the burst is a complete start, not a complete design. Tell the agent what is out of scope too, because what you leave unsaid is what it will confidently invent: no tests today, no refactor of the payment part. A burst that states inclusions and exclusions in five sentences is the strongest possible briefing.

This is the hard section for most people, because staying quiet while an agent works feels like losing control, and the urge to add commentary is nearly physical. The run is where your instructions become a diff, and every instruction you inject mid-run becomes a competing edit in the same file. Instead, use the run as a collection time: watch the warnings stream and note each one, with a numbering shorthand you can say back later: warning one is about the nullable field, warning two is a lint rule, warning three is a test collision. Collecting instead of reacting is the subtle skill that separates a session that flows from a session that thrashes.

Fifteen warnings is a realistic count for a medium run, and the sheer number is why reacting in real time fails. If you fix each warning as it appears, the agent's context fills with corrections and the actual feature stalls; if you collect all fifteen and then decide, you gain a classification that tells you what matters. Say the classification out loud as you go: warnings one through five are cosmetic, six is a real bug, seven through ten are the same root issue in three places, eleven through fifteen are the old tests that will need updating. One spoken sentence per group, and the run ends with a plan instead of a panic.

Quiet is also for the agent's benefit: a run that is not interrupted can finish its own decomposition, and agents produce better code when they are allowed to complete a unit of thought. If your tool shows you a progress timeline, watch it the way you would watch a build in the old days, with your hands still. The right analogy is being on site with a contractor: you inspect at agreed checkpoints, you do not redesign the kitchen mid-trowel. Set one checkpoint per run boundary, and list the warnings you collected to that point, read aloud, before deciding whether the run continues.

What if the run clearly goes off the rails? That is the one legitimate interruption, and it has a spoken form: stop, this is not what I asked for, here is the difference. Interrupt once, name the divergence precisely, and then resume quiet. The divergence is usually a misunderstanding of one sentence in your burst, so check your own briefing first and note the sentence to rewrite. If the agent has derailed twice in the same run, cancel the run and re-burst with a tighter boundary, rather than trying to steer a runaway context back on course one warning at a time. Knowing the difference between steering and babysitting is, after all, this article's whole premise.

The diff is the dialogue between your burst and the agent's run, and reading it is a separate discipline from writing prompts. Read the diff out loud at its natural rate: added, removed, moved, renamed. The spoken version of the diff makes the size of the change audible, and you will hear in your own voice whether a five-line change is actually a forty-line change in disguise. Ask the agent to run the tests before you read, and read the diff with the test results beside it, because a diff is only a conversation when you know whether its claims are true.

Classify each change into one of three buckets as you read: exactly what I asked, close but needs a correction, and none of us saw that coming. The third bucket is where you must slow down, because an agent that invents behavior usually invents it confidently, and the invention becomes part of the codebase as soon as you accept it. Speak the invention back: you added a truncation that I never mentioned, and I am not sure that is right. Then decide in the same breath whether to keep it or ask for it gone. A spoken decision on an invention is recorded in the conversation and survives as a justification for the reviewer.

Not every correction deserves the next burst. Group the returns into one of two categories: things the agent can fix from a one-line instruction, and things you need to re-brief. The first group you dictate as a batch, single burst, and let it run. The second group usually signals a gap in the original burst, so say what was missing: I said validation but I actually meant blocking validation, and that distinction is why the empty state is broken. Re-briefing with a sharper sentence is much more effective than sending five corrections, and voice makes it easy, because you can say the sentence ten different ways until it sounds right and pick the best one.

Finish each diff reading with an explicit spoken verdict: this run is good, next burst is the tests; or this run is close, one correction needed; or this run is wrong, re-briefing from the validation sentence. The verdict forces a classification, and the classification becomes the session's skeleton. Keep a tally of verdicts across the day: mostly good means your bursts are well-briefed, while mostly wrong means you are front-loading ambiguity and the fix is more time in the burst, not more time fighting the agent. The diff is feedback on you as much as on the tool, and reading it that way is how your voice coding session pace improves week over week.

Different tasks want different rhythms, and the pace habit that works for a bug fix will wreck a refactor. Exploration, where you do not know what the codebase does yet, wants short bursts and short runs, maybe a burst of one sentence followed by a run that ends at the first test result. Architectural work wants long bursts and long runs, because the agent needs the full shape before it writes anything coherent, and the mini-run cadence would build the wrong thing in five wrong increments. Say the task type out loud before you pick the rhythm: this is exploration, so small steps and verify as we go. Naming the rhythm is what makes it a choice instead of a default.

Bug fixes are the special case where a quick failing run is itself the valuable artifact. Here the burst can be a single sentence: reproduce the error with a test. Let the run produce the failure, then burst again only after reading the error and naming the hypothesis. The rhythm is burst, fail, name, use appropriate pace, fix, run. The pacing is deliberately slow, because in bug work the intelligence is in the naming, not in the writing. A coder who speeds up through a bug fix by issuing rapid instructions is asking the agent to guess, and the guess is usually wrong, so slow the rhythm down on purpose.

New-feature work wants the full ritual: five idea burst, quiet run, diff reading, verdict. Refactoring wants a dependency-aware burst, and here the boundary is the module name spoken before each run: move the pricing calculator, keep the interface, do not touch the callers, nothing else. The spoken boundary is what keeps a refactor from sprawling outward, and refactors are where micro-interrupts are most catastrophic, since every extra instruction is a chance to change behavior you were trying to preserve. For refactoring, the burst is longer, the run is quieter, and the diff reading is slower, because behavior preservation deserves the attention.

The meta-skill is noticing when the rhythm is wrong and saying so. A session that feels like babysitting is a session running too fast, with too many micro-interrupts and too few real runs; a session that feels like a carousel ride is running too slow, with runs that end nowhere and bursts that never commit. Say it out loud at the midpoint: I have been micro-interrupting for forty minutes, this task wants a different pace, let me re-burst with a boundary. The voice is the instrument that notices, since it records the number of interruptions as an audible list. Choosing the rhythm deliberately, checking it halfway, and adjusting with a sentence is the entire skill of working with an agent without being run by it.