Working by Voice

Meetings Were the Starting Point

I first learned to treat speech as working material in meetings. A long conversation contains decisions, open questions, explanations and corrections that no set of quick notes captures completely. A transcript gives me something to revisit after the meeting, extract from and check against what the participants meant. That fits the broader way I manage projects inside the repository: the conversation informs the record, but the reviewed decision lives where the work happens.

Live Work and the Meeting Record

While working on the validation documents for a life-sciences consultancy, we sometimes spent two hours together each day on the documents. I had multiple agents working during those sessions. When the stakeholders and I reached an understanding I could state clearly, I spoke it into a prompt on the spot and moved the drafting forward while everyone was still there. The meeting transcript stayed on as a fuller record of the discussion, including context I had not put into a live prompt.

Other times, a decision emerged during a longer exchange while I was working on something else. With meeting transcription running, I could ask an AI meeting assistant a focused question about what had just been decided, a workflow or a naming convention during the meeting. I did not have to wait for everyone to leave before acting on it. The same transcript remained available afterward for the context I had missed or needed to check. The assistant’s answer helped me find the relevant discussion; I still checked the wording and confirmed the resulting record rather than treating its summary as the decision itself.

Now I Talk to the Computer Too

On-demand transcription extends that loop into independent work. Much of my work now begins with speaking into a speech-to-text tool. I dictate a thought as it forms, use the transcription as a prompt, look at what the agent produces, and talk through the next correction. I estimate that roughly 95% of my direction on the Treasury Console started as speech transcribed on demand. That is my estimate of how I worked, not a measured productivity result.

Speaking lets me give the whole context while I am thinking about it: what seems wrong on a screen, why a number does not make sense, what the business rule should be, and the exception I remember halfway through the explanation. Typing can make me compress that into a short instruction before I have finished the thought.

The loop is similar in both settings. I can speak a conclusion while other people are in the room, or explain an idea aloud when I am working alone. An agent turns it into a proposed model, screen, document or code change; I inspect that concrete result and give the next round of direction. Voice does not make a first thought final. Transcription can miss a word, and a stream of thought can mix a decision with a question. The record and the application still need human review.

Voice Changed Where My Attention Went

The more interesting change was not only how quickly words entered a prompt. When a screen was open or a meeting was still underway, I could keep looking at the work and say what I noticed at the moment I noticed it. I could explain the surrounding context, a doubt, or an exception without first compressing it into a polished typed request. The agent’s first version then gave me something specific to accept, correct, or reject.

Speech also became a way to direct several threads of work. During a document session I could move one agent forward while another handled a separate piece, without losing the conversation happening in the room. On my own, I could keep a design or model moving through successive spoken corrections. That depended on having distinct tasks and reviewing what each agent changed; talking faster did not resolve conflicts or make a decision for me.

Those spoken inputs had different jobs. A meeting transcript kept the fuller conversation available. A live prompt turned the part I understood into immediate work. A reviewed document, model, or commit became the durable record. Keeping those roles distinct let me work quickly without making an uncorrected transcript, or an agent’s first interpretation, the authority.

Choosing What the Work Becomes

Once I have spoken the direction, I still have to decide what the agent should make and where I will review it. If I am sorting out a decision or organizing new information in a repository, a lightweight Markdown file gives the idea a structure I can revise. I can also think through a question with an AI conversational assistant before deciding whether it needs a file at all. The conversation is useful, but an important result should eventually have a home I can return to.

If I need to understand something visually, I may ask for an HTML page: a document I can read in a browser, a diagram I can examine, or a design study I can navigate. I can refine that directly instead of first turning it into a Word document or an Excel workbook. Those formats can still be useful when the deliverable calls for them; they do not have to be the starting point for the work.

When an application already exists, the result may be a change to its screen or data that I can inspect there. It might instead be an HTML design proposal at a route I can open, or a note kept in a review area until I am ready to act on it. I describe the outcome I want, where it should live, and what I need to see to judge it. The design workbench and review-mode project goes further into those visual review choices.

One Prompt, Side by Side

A recent prompt in this work is a useful scale example. I gave two long paragraphs of direction: update an automated-testing case study from its latest report, make a small report example people could open, and connect this voice story back to meeting transcripts and live work sessions. These are two short excerpts from that one much longer prompt, not the full message:

“The other piece that could be cool is you could maybe take like snippets of the HTML report and have a representative example that someone could interact with on the case study.”

“And then for the working by voice piece, just like transcription in [a speech-to-text tool] is one piece of it, and that’s kind of more recently like a continued development. And I don’t know if I already have like a case study that already talks about the general workflow, but it kind of all goes together.”

The full prompt contained 583 words of direction, excluding the file path at its start; the two excerpts above show only a small part of it. I did not time that dictation, but 150–160 words per minute is a normal speaking pace for me when I know what I want to communicate. A side-by-side estimate for entering the full prompt looks like this:

Method	Rate used for the estimate	Entry time for 583 words
Speak and transcribe	155 words per minute, the midpoint of my usual pace	About 3 minutes 45 seconds
Type	Illustrative 50 words per minute	About 11 minutes 40 seconds

That suggests a difference of roughly eight minutes in entering this one substantial prompt. It is an estimate, not a stopwatch result or a typing trial. It does not count thinking, pauses, transcription processing, corrections or editing. The practical change for me is that I can give the full context and nuance in one pass instead of cutting it down to what I feel like typing. This prompt led to a corrected 925-test report story and a clearer account of the voice workflow.

What I Took From It

Voice became useful when it stayed connected to the work in front of me. It let me supply more context, coordinate agent work while a conversation or a screen still had my attention, choose a form for the result, and return to it for a closer review. The comparison above estimates input time from stated rates, but the lasting change was a working rhythm: speak the thought, inspect what it became, make the decision explicit, and keep the reviewed result where the project can use it.