Talking to a codebase: notes from a week of voice sessions

A small experiment: one of us spent a working week using Sesori with the keyboard off. Not entirely off—there was still typing on the laptop at a desk—but every interaction with the assistant happened by speaking: prompts, approvals, and “no, undo that, try the other thing.”

These are the notes from that week.

Day 1: the symbols problem

The first day was rough, as any new modality can be. Transcription could not reliably tell that “underscore” meant _ rather than the literal word, or whether “open paren” should be punctuation. We spent much of the morning correcting the interpretation of our dictation.

The fix wasn’t a technical one. It was just: stop dictating code. Let the assistant write the code. Use voice for the things voice is good at — intent, direction, evaluation — and let the model handle the syntax.

By lunchtime on day one, the rhythm had shifted from

“function space get user space open paren id colon string close paren…”

to

“Add a getUser helper that takes an id and returns the row from the users table. Throw if not found.”

The second version is shorter to say and easier to think about, and the result is the same.

Day 3: the rhythm

By Wednesday, voice felt natural for a particular slice of the work — the slice where you know what you want and you’re directing a more-or-less competent collaborator who can do the typing. The assistant writes a draft. We read it on the screen, decide whether it’s right, and either approve it or describe what’s off. “That’s good, but pull the validation into its own function.” “That’ll work. Add a test.”

The eyes still do all the reading. The voice does all the steering.

In retrospect, the shape resembled a senior engineer pairing with a junior one: one person directs, the other drives the keyboard. Here, the model occupied the second role.

The surprising thing

Voice forced us to be more deliberate before speaking, because we couldn’t do the thing we usually do — start typing a sentence, see how it comes out on the screen, hit backspace, restructure mid-thought. With voice you commit. So we found ourselves pausing for a second before each prompt, working out what we actually wanted, and then saying it.

The prompts improved. The same instinct behind rubber-duck debugging—the act of putting a problem into words—helped when those words were spoken to an AI assistant.

Where it broke down

Two places, both unsurprising.

The first was dense refactors. When we needed to move five things between four files in a specific order, the verbal description got tangled almost immediately. “Move the validation from user.ts line 14 — no, the second occurrence — into the new validators module, but keep the import in user.ts because the auth flow still…” It was easier to describe by pointing, which voice does not do.

The second was naming. We are particular about names, and the difference between getUser, findUser, loadUser, and fetchUser is real to us in a way it isn’t to the assistant. Negotiating naming over voice — when there’s no easy way to say “no, italic fetch, with the connotation of going somewhere to get it” — was harder than it should have been.

So: useful?

Yes, in a specific way. Voice is not a replacement for typing. It is useful for the direction phase of work and less useful for fine-tuning. Voice for intent plus a screen for review worked better for us than either alone.

That is the working theory after one week. For setup and the broader workflow, read the OpenCode mobile guide.