Emmanuel Akinfulubi

Voice and conversational coding

Speaking the work instead of typing it, to a transcript or to an agent that acts. Strong for plans, specifications and hands that cannot type all day, and every spoken word still needs editing as text.

Updated
Verified

Voice and conversational coding means speaking the work rather than typing it. It comes in two forms worth keeping apart. Dictation turns speech into text that you then edit: a plan, a requirement, a commit message, a review comment. Conversation is talking to an agent that answers and acts, so what you say becomes a change to the code. Underneath both sits a third use, driving the editor itself by voice, which for some developers is not a preference but the only way to work.

It is an emerging category with almost no teaching behind it. The conversation this section's taxonomy came out of was itself spoken, and its transcript shows where voice degrades: technical terms mangled, no control over punctuation, and everything needing an edit afterwards. Those three account for most of this page.

What it is for

  • Planning, where thinking runs ahead of the keyboard. Speaking a specification and then editing it can be a faster loop than typing one from a blank page.
  • Explaining a problem out loud, to an agent or to a transcript, which often finds the gap before anyone answers.
  • Review comments and descriptions, where what you say matters more than the wording of a first draft.
  • Working at all, for anyone whose hands make sustained typing painful.

Who it suits

Two groups. Developers with repetitive strain injury, a hand injury or another condition that makes typing all day painful, for whom voice is an accessibility need, served mostly by hobbyist write-ups rather than by teaching. And anyone planning a system rather than editing a function, whose ideas arrive faster than they can type them.

It is weakest at line-level code, where every symbol, bracket and exact identifier has to be spoken.

How to tell this is your category

  • Your input is speech, and the output is either text you then edit or an action an agent takes.
  • You plan, explain or brief by talking, and type to correct.
  • Voice is a way in, so it combines with other categories. If you speak to an agent in your editor, the costs on AI IDEs or terminal and CLI agents still apply. This page covers what speaking adds to them.

What it costs you later

  • Mangled terms become wrong names. Identifiers, library names, acronyms and anything in camel case tend to come out as the nearest ordinary words. In a transcript that is a typo. In a brief an agent builds from, it is a wrong name in the code, or a guess at what you meant. Read every transcript before it becomes a brief, spell out the identifiers that matter, and keep a short list of the terms your setup reliably mishears.
  • No structure. Speech has no punctuation you can rely on and no headings, so a spoken specification arrives as one long paragraph. Numbered acceptance criteria, a list of failure cases and a clear "done when" have to be added afterwards, as text. That editing step is the work, not a chore after it.
  • Spoken instructions are looser than written ones. Speech hedges and wanders: maybe, sort of, and also. A person listening fills the gaps sensibly. An agent acting on it fills them too, with decisions you did not make. Turn the transcript into a written brief before anything is built from it, and read the brief, not your memory of what you said.
  • A misheard command still runs. In a conversation with an agent that acts, a misheard word is an action. Keep a confirmation step for anything that deletes, migrates, deploys or touches money, and never let a voice session approve commands you have not read.
  • Where the audio goes. Speech may be transcribed on your device, or sent to a service and kept. Find out which, and for how long, before you speak client names, credentials or anything under a confidentiality agreement. The room matters too. An open office hears everything the microphone does.
  • A dependency, for the people who need it most. For someone who cannot type, the voice setup is the whole workstation. When the service is unavailable, changes its behaviour or shuts down, the work stops. Prefer a setup that works offline or has a fallback, and keep your custom vocabulary and commands in files you own.

Speak it, then edit it

Voice works best for the first draft of a plan or a specification, followed by an edit in text. Here is a refund rule as it was dictated:

Spoken, as transcribed
so refunds should only work inside the return window which is like thirty
days and if its outside that it should say so and also it shouldnt call the
payment provider until somebody approves it

And here it is after the edit, as requirements an agent can build from:

specs/refunds/requirements.md
1. WHEN a customer requests a refund within 30 days of delivery,
   THE SYSTEM SHALL record the request in the `requested` state.
2. IF a refund is requested more than 30 days after delivery,
   THEN THE SYSTEM SHALL reject it and state the return window.
3. THE SYSTEM SHALL NOT contact the payment provider until a person
   has approved the refund.

The edit took the transcript's three ideas and made each one testable. It also made a decision the speaker had not: that the window counts from delivery, not from purchase. Catching the decisions you skipped while talking is the point of reading the transcript back, not a side effect of it.