DEV Community: Uri

Talking to an agent is not talking to yourself

Uri — Sat, 19 Sep 2026 02:12:08 +0000

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.

The idea survives the walk and dies in the editor

Uri — Sat, 12 Sep 2026 00:25:03 +0000

I build the whole argument walking the dog. Beginning, middle, the objection someone will raise, my answer to it. It is all there. I get home, open the editor, write the first sentence — and the second one does not come. I did not forget the subject. I forgot the sequence, which was the only hard part.

The easy explanation is speed: people speak three to four times faster than they type, so the thought outruns the hands. But that does not explain why an idea survives twenty minutes of walking and dies in thirty seconds of blank page.

What actually happens is that writing bills you twice at once. You have to decide what to say and decide how to say it in the same instant, and the second job interrupts the first. Every time you stop to pick between two words, you drop the thread. Speaking does not bill you twice. Out loud you are forced to be sequential — one thing after another — but you are not forced to be final. You can say "no, wait, it is the other way around" and keep going. The editor has no such sentence.

It is the same mechanism as the programmer's rubber duck: explaining the problem out loud to an inanimate object solves the problem, and it solves it before the object answers. It is not the conversation that works. It is being made to put things in order.

So what works is splitting the two jobs into two moments. Talk first, without editing — not even the repetitions, the false starts, the "I mean". Then, and only then, tidy up. Spoken text is not the text; it is the raw material for it. The part you kept losing was the part you could not reconstruct. Tidying up you always knew how to do.

And it is not all or nothing. Lists, tables, numbers, proper nouns — anything with an exact shape is faster to type than to say and then correct. What goes to speech is what has order: the argument, the objection, the reason. In practice you alternate inside the same piece of work.

Where it stopped being a method and became a tool problem

Walking the dog, dictating a piece of market research into the ChatGPT app: the sources, the theses, what was worth testing. Partway through, something on the screen suggests it is not going well. I stop, send what I have said so far, and keep recording the rest — because I had not finished. Then I submit it and see the error.

The first frustration is immediate, and the fix is a bad one. A stretch did not make it, so I have to walk back to where it dropped, repeat the points I had emphasised so they are not lost, and splice back into the argument. It costs more than it sounds: it is not repeating words, it is rebuilding order — and order is the expensive part.

The second one is worse, and it is the same as the opening of this piece. When I cannot walk it back right there, I leave it to pick up at home. Except by then it is not splicing, it is remembering from scratch. And the first thing to go is the sequence, which was the only hard part. The tool failing handed me back exactly the problem that speaking had solved.

It happened again on a different occasion, recording an account of a dream — one of those eight-minute ones you only get to tell once: I wake up, write keywords in a notebook so I do not lose them, and narrate it in detail later. The transcription hung. The notebook keeps the subject; it does not keep the account.

What a dropped recording costs you is not the text: it is the one pass in which that reasoning existed whole.

⭐ That is what the command-line version was written against, and the lesson that stuck is not a technical one. What it does differently makes the transcription no better at all — it exists so the whole thing arrives on the other side. A wrong word you reread and fix in thirty seconds. It is the other thing that has no fix.

Where this still does not work

A transcript is not a finished draft, and anyone promising otherwise is selling something. What comes out follows your order of thinking, not your order of writing — those are different, and the second one is still work.

And the bigger limit has no tool fix. Speaking preserves reasoning; it does not manufacture it. If you do not know what you want to say, twenty minutes of audio gets you twenty minutes of someone not knowing what they want to say — now in writing.

What to take from this

The step that changes the most and costs the least is not the recording. It is deciding, before you start talking, where the text goes when you stop.

Without that destination, the walk produces one more audio file in your life. With it, the walk becomes work already started: the text lands where the next step happens — the session you were going to code in, the project note, the open draft, the agent that picks it up from there. Which place does not matter. Having one does.

You can test it in a day: next time you build an argument while walking, decide the destination before you hit record. The walk is still where the thinking happens. The only thing that changes is that it stops dying on the way home.

This article was prepared with AI assistance.

Dictation is not long-form transcription — I tried five tools before writing my own

Uri — Sat, 05 Sep 2026 01:07:38 +0000

Dictation is writing with your mouth: you say a sentence, look at the screen, fix it. Transcribing long-form audio is a different problem — you talk for fifteen minutes without looking at anything, and you want the whole text afterwards. Almost every tool I had at hand solved the first case and broke on the second, each in its own way.

⚠️ All of this is as of when I tested it. These products change fast; recheck before deciding anything on this basis.

Dictation inside ChatGPT. The audio got cut off when it ran long. That hurt most, because long was exactly what I wanted: describing the whole context of a new project, or narrating a dream in detail. Losing that is losing minutes of speech that do not come back.

Audio in Claude. When I tested it, it captured English better than Portuguese.

Google Docs dictation. No punctuation. You get one running block — and in fifteen minutes of audio, a running block is unreadable.

The native iOS recorder. It records as long as you like and transcribes, but getting the transcript out of it and into somewhere else — a coding session, a chat — is enough friction to make you quit halfway.

I also tried Google Meet. Speaker identification worked well in my test, but getting the text meant starting a meeting, making sure transcription was configured and enabled, ending the meeting, waiting for the transcript email, and downloading it if I wanted a file. That is a lot of steps when all I want is to capture a thought.

What I was still missing after trying all five: a short path from a long spoken thought to text I could use somewhere else. Each tool added a different interruption, limitation, or set of steps to that workflow.

The two problems the script had to solve

It became a terminal script calling OpenAI's transcription API. The list was short — accept speech of any length, return punctuated text, leave the text where I was already working — and the first two items were harder than they looked.

First: the limit is not file size, it is duration. The model truncates its output somewhere around 8 to 11 minutes of audio, regardless of how many megabytes the file has. Slice by size and you find out the worst way: the upload succeeds, the transcript comes back, and the ending is missing. So the split is by time, in 6-minute pieces, with margin.

Second: where to cut. Cutting at exactly 6:00 lands in the middle of a word. The model gets half a word at each end and completes the fragment — you get an invented word, a lost word, or a duplicated sentence, once per seam. The fix is to push the cut to the nearest silence, inside a 45-second window.

Then came the part I did not expect. The silence threshold cannot be fixed, and it cannot be derived from average volume either. Measuring twelve real recordings, the noise floor ranged from −50 to −35 dB without tracking the mean: the loudest recording, averaging −25 dB, had the lowest floor of all. A hardcoded value either finds no pauses at all or marks the entire file as silence.

The way out was to search for the threshold instead of picking one: start strict and loosen in 5 dB steps until pauses appear. Each pass is analysis only — about 1 second on a 15-minute file — so the search is cheap. On a real 19-minute recording, all three cuts landed on a pause and the seams do not show in the text.

The cost, which was the doubt holding me back

US$ 0.003 per minute with gpt-4o-mini-transcribe, checked against the actual invoice. In the month I measured it came to 726 minutes of speech — a little over twelve hours — for about two dollars. Not all of it was one project: that is what I talk in a full month of work.

Where this does not work

What comes back is transcribed speech, not finished text: repetition, "I mean", the sentence abandoned halfway. It works as a prompt or a draft; it does not work for structured reading. And the script runs in a terminal, which means: only in front of the computer. The idea that arrives on the street kept getting lost — and that became the next problem.

This article was prepared with AI assistance.