When you record an idea to document something or to tell someone, what comes back is a draft: you will reread it and tidy it up. When you record something to hand to an agent — a coding session, an assistant that will act — what comes back is the instruction. Nobody rereads it in between. What you said becomes what happens.
That changes how you should talk, and it took me a while to notice that it does.
Three things loose speech drops, and an instruction needs
Constraints come out as asides, and asides get lost. Out loud, we state the goal clearly and bury what must not happen inside a side remark — "oh, and without touching the database". For yourself that is enough: you know. For whoever executes, a constraint said in passing carries the same weight as any other sentence. Say the constraint as a full sentence, and say it before the goal. It is the part whose absence you only discover once the work is done.
The same thing gets three names in one paragraph. Speaking, you call it "the file", "that thing", "the config", and nobody blinks — a listener follows by context. But this listener treats each name as possibly something else. Pick one name and repeat it, even when it sounds dumb. The repetition that grates on the ear is exactly what removes ambiguity from the text.
Speech has no visible structure, and you cannot rely on formatting. On the page, "first, second, third" show up as a list. In speech they are intonation — and intonation does not survive transcription. If the order matters, say the order out loud. "There are three things. The first is…" It is ugly, and it works.
What does not change, and why speaking is still worth it
None of this undoes the advantage. Speaking is still how you dump dense context without stopping to pick words — and dense context is exactly what an agent needs and what you least want to type. The three corrections above cost seconds each. Typing that much context costs the afternoon.
One case of mine, and the half of it that was not the speaking
I recorded a walkthrough of a user journey: what the person would do, what should show up on each screen. Halfway through I started deciding out loud — changed the order of the steps, picked which detail belonged where. What came back had things on the wrong screen and, as a bonus, a feature I had stressed simply not built.
Half of that is the three points above coming due: deliberating out loud arrives on the other side as instruction — nobody knows which version of the order won — and "stressing" something is intonation, which does not survive transcription.
The other half was not the speaking, and it took me a while to admit: the session was carrying too many subjects at once. A good instruction delivered into an overloaded place gets lost all the same. That is what made me separate two things I used to treat as one:
How much context your speech must carry depends on where the project is. Early on I explain the gotchas and give long context. Later I speak by reference — "like we did on that screen" — and the same instruction fits in less talking. It is the difference between explaining to someone who joined yesterday and someone who has been on it for a month.
One subject per session. When execution, review and decisions from different fronts compete for the same conversation, no speaking technique makes up for it — and the bill arrives as extra rounds before you get what you meant. Speaking well does not fix an overloaded listener.
Where this does not work
If the task has an exact shape — a filename, a path, a command, a number — speaking is slower and riskier than typing. The gain from speaking is in context, intent, and why. The literal part you type, and you type it afterwards.
And there is a limit no speaking technique fixes: if you have not decided what you want, talking does not decide it for you. A vague instruction delivered fluently is still a vague instruction. The agent will execute your indecision very efficiently. You could waste multiple iterations with the agent before finding out the system never actually ran, stalling progress due to a lack of direction, clarity, specs, and structure. Being able to run manual tests in short cycles is a strong indicator that the shared specifications are detailed and clear enough.
This article was prepared with AI assistance.
Top comments (0)