Do You Need Dictation, Editor Voice Commands, or an AI Coding Agent?

Start with what you want your words to do. If they should appear in a note or prompt, you need text entry. If they should select and change something in an editor, you need an editing action with a known target. If they should ask a system to work out a change, you are delegating an AI task.

These roles can appear in the same workflow. You might dictate an explanation, use a configured command to select text, and ask an agent for a candidate patch. Choose the role for each step before choosing software for the whole job.

A public question about dictation for coding makes the distinction concrete: the author wants speech transcription and coding-related commands while explicitly declining an LLM that guesses the implementation. That is a useful selection question. Speaking about code does not necessarily mean asking AI to write it.

The worked example below uses one fictional scratch task and three complete routes to the same result. The histories and text states are authored teaching materials; no voice software, editor or coding agent was run to produce them.

Define the result before deciding how to speak

Open a disposable scratch buffer containing this exact text:

function seatsLeft(capacity, taken) {
  const freeSeats = capacity - taken;
  return Math.max(0, freeSeats);
}

const guidance = "replace freeSeats with availableSeats";

Also imagine a separate, initially empty note field. The task has two parts:

1. Enter the literal line replace freeSeats with availableSeats in the note.
2. Rename the local variable in the function from freeSeats to availableSeats, changing its declaration and its return-expression reference.

Keep the function name, parameters, calculation and source layout unchanged. Keep the quoted guidance string exactly as it is. There is no repository search, new feature, terminal operation or test execution in this exercise.

The expected source is:

function seatsLeft(capacity, taken) {
  const availableSeats = capacity - taken;
  return Math.max(0, availableSeats);
}

const guidance = "replace freeSeats with availableSeats";

The expected note is still:

replace freeSeats with availableSeats

This tiny task contains the important ambiguity. The same words can be a sentence to retain, a description of an editing action, or an instruction asking an agent to propose that action. Their destination and interpretation determine which one happens.

Route A: dictate the note, then edit the two tokens yourself

First identify the separate note field and place the insertion point there. Dictate the line, inspect the editable text, and correct or paste the exact identifier spellings. The note should now contain replace freeSeats with availableSeats.

At this point, the source has not changed. The text-entry step has done its job; it has not completed the rename. A sentence describing an edit is useful text even when it performs no editor action.

Next, manually select the declaration's freeSeats on source line 2 and replace only that token with availableSeats. Then select the reference on line 3 and make the same replacement. There is a short intermediate state where only the declaration has changed; finish both edits before treating the source as the target result.

Finally, inspect the source and note together. Both code references should use the new name, while the quoted string and separate note should retain the old-and-new phrase exactly. That completes the scratch task through dictation plus manual editing.

This route fits when speaking helps you capture prose but exact selection is already straightforward with your existing editor. You can use typing or paste for the names. You do not need a new command system or an AI-generated patch to make two edits you already understand.

Route B: use configured editor actions and literal text entry

Direct voice editing needs more than recognition of the words. It needs a mapping from a recognized request to an editor action, plus a way to identify the current target and inspect the selection.

For this history, assume a hypothetical configuration can select an exact displayed token, replace that selection with supplied text, and enter literal text into the separate note. Those are the example's prerequisites. The action descriptions below are not spoken-command recipes for Talon or any particular IDE.

Start from the original source and empty note:

The final comparison is the same as Route A: two code-token changes, an unchanged quoted string, and an exact note. What differs is how the edits are requested. Here the person has already chosen the edits; a configured command route performs the specified editor actions.

If the selection cannot be established at step 1 or 3, leave the replacement unissued. Use manual selection and typing to finish the remaining explicit edit. If step 2 already happened, preserve that intermediate state and inspect what remains rather than starting a blind global replacement.

For an actual installation, check the relevant configuration. Talon's first-party source reference lists text-entry, key and mode definitions separately. Its dictation-mode description still distinguishes commands from other speech. A mode label alone therefore does not tell you that every phrase will be treated literally.

That reference is a documented example, not evidence that your editor has a particular selection or rename command installed. Before adapting this route, identify the exact operation your setup supports and how it enters command-like words as text. If that capability is missing, keep the manual route for that step.

Route C: ask an AI agent for a candidate change

In the third route, the words go to an AI conversation. You supply the complete source, the exact names, the literal note and the limits of the change. The requested output is a candidate patch for inspection, so the scratch buffer remains unchanged while you consider it.

You can dictate the explanation into a request draft, then paste the precise material. Inspect the assembled request before submitting it. Here is a complete version:

Prepare a candidate change to this exact six-line source as text only.
Rename the local variable freeSeats to availableSeats in its declaration
on line 2 and reference on line 3. Keep line 6's quoted string unchanged.

function seatsLeft(capacity, taken) {
  const freeSeats = capacity - taken;
  return Math.max(0, freeSeats);
}

const guidance = "replace freeSeats with availableSeats";

Also return this exact separate note line as literal text:
replace freeSeats with availableSeats

Preserve seatsLeft, capacity, taken, subtraction, Math.max(0, ...),
guidance, the quoted string, punctuation, spacing and ordering.
Change only the two specified source tokens.

Return a unified diff for fictional scratch/seat-note.js, the note in
its own text block, and a brief explanation. Separate any check actually
performed from proposed checks. All source needed is pasted above.
No repository access, file edits, commands, tests, network or deployment.

The candidate you want is this two-token patch, shown here as an authored expected result:

 function seatsLeft(capacity, taken) {
-  const freeSeats = capacity - taken;
-  return Math.max(0, freeSeats);
+  const availableSeats = capacity - taken;
+  return Math.max(0, availableSeats);
 }

Compare the candidate with the full source, including the unchanged guidance line outside this excerpt. Check the returned note separately. Once those match the task, you can manually adopt the candidate into your disposable scratch buffer and compare the final text with the common target.

In an actual agent workflow, inspect what the agent returns rather than assuming it will match this example. Extra cleanup, a changed string or a missing note should bring the candidate back to the same small task. A persuasive explanation does not make an incorrect patch correct.

This route is useful when you want help working out or proposing a change. For a rename this small, Route A may already be enough. The point of the example is to identify the delegation step, not to make AI generation a prerequisite for voice coding.

Keep literal words, editor actions and generated changes separate

The phrase alone cannot tell a tool which role you intend. Use a small boundary table:

A global text replacement is a useful counterexample. It might produce:

const guidance = "replace availableSeats with availableSeats";

That line violates the task even if the function's two variable references are correct. The old name belongs in this string because the string is literal guidance. “The new name appears everywhere” is the wrong completion rule.

Likewise, a note containing the correct phrase does not establish an edit, and an agent returning a patch does not establish that it was applied. Compare the artifact you actually wanted: the source and note together.

Choose software by the missing step

Use your smallest real task to name the gap before changing tools.

Record the environment and required behavior before filling in a command or shortcut:

Task and exact starting content:
Text that should be entered literally:
Editor action I want, if any:
AI-generated artifact I need, if any:

Editor / platform / version:
Speech tool / version / configuration:
Documentation for this exact operation:
How I identify the active target and inspect the selection:
How command-like words are entered literally:
What is documented, locally observed, or still unknown:
Manual selection/typing fallback:
Expected before/after text:
Actual observation after trying it:

Leave the observation blank until you have actually tried the route. A source example or someone else's recommendation can identify a candidate; it does not supply your result. You can also keep the parts of your current workflow that already fit. The same task may use speech for a note and a keyboard for two exact tokens.

The companion boundary and adaptation cards include a filled version for this example. For the separate choice of where a dictated AI request should land, see Voice Input Across AI Conversations.

Finish by comparing the same target

For SCRATCH-6, completion is concrete: the declaration and return reference use availableSeats; the quoted guidance string is unchanged; the separate note contains the exact requested phrase.

The calculation remains expressed as the maximum of zero and capacity minus taken. Under the example's non-negative integer inputs, the manually expected results are 7 for capacity 10 and taken 3, 0 for 2 and 5, and 0 for 5 and 5. These are reasoning examples, not executed tests.

The complete fixture, expected patch and full route histories keep the intermediate states and the same final target together. Choose the route by who should supply the text and decide the edit. Speaking can be one part of that choice without turning every sentence into a command or every coding task into AI generation.