Bandwidth: Intent and Understanding Per Minute

You type a prompt, get a wall of text back, skim it, approve it. When the next turn is still off, you blame the model.
I do this, and Opus 5 makes it worse. Its replies are long, and I have stopped reading them in their entirety. The model may have produced something useful and I didn’t fully understand it, so the next prompt I send is no sharper than the last.
In this format, the bandwidth of both channels is constrained: intent going in and understanding coming back.
Four steps
I used to type and read back. Dictation tools came next, then full back-and-forth audio, then the agent showing me things. Each step changed a specific channel of the loop.
Type in + read back. This is where most people still live. You hunt for the words, type them one letter at a time, then wait and read. The bandwidth in both channels stays constrained. I have shipped plenty this way before I ever dictated anything. It works. It also throttles how much of what I meant gets across, and how much of what came back I absorb.
Dictate + read back. Speech widens the intent channel first, so more intent makes it in. But understanding still comes back through text. I can say more, but I still have to extract the understanding from a wall of words.
Talk both ways. This is the jump I felt. Dictation widened the intent channel. But being able to listen to a clear explanation while still reading the spec, the code, or whatever the agent is working on dramatically widened the bandwidth of the understanding channel. I’ve been using voice-tunnel, my agent voice tool, for everything. With both channels widened, I can send far more context, and enough understanding comes back to sharpen my next turn.
Talk both ways + show me. Hearing a description still leaves me extracting the understanding from it. However, the agent can put the actual output in front of me: the data, the plot, the running system, a recording of the feature being driven. The understanding channel carries evidence instead of a write-up.
Intent per minute
Intent per minute is how much of what I mean gets through to the agent per minute.
Typing forces me to compress my thought before the agent sees it. Speaking lets me send the examples, constraints, tradeoffs, corrections, and reasons as they occur to me. What sounds like rambling is often where the context lives. I state the goal, catch a missing constraint as I hear myself say it, and explain why one tradeoff beats another.
Doug Engelbart argued in 1962 that our effect on the world is limited by what we can transmit through our motor channels, while what we understand is limited by what comes back through our sensory channels. A keyboard constrains the intent channel. A wall of text constrains the understanding channel.
Understanding per minute
Understanding per minute is how much of the result I actually take in per minute. Reading a reply is not the same as hearing it and immediately responding, “No, not that, the other thing.”
Opus 5 can hand back a long response full of technically good arguments that I can barely understand. If I skim it and approve the next step, the agent gets almost none of my judgment on the next turn, and my taste starts disappearing from the artifact.
Show me widens the understanding channel because I can inspect the result instead of extracting understanding from another explanation. That understanding becomes judgment, which sharpens intent on the next turn.
What reaches the artifact
More intent in and more understanding back means more of my taste reaches the output.
I wrote that taste debt is shortcuts in the judgment you apply to what gets built, the decisions you let the AI make because the output looked fine. It is the gap between the taste I have and the taste that reached the artifact.
Show me
I don’t trust diagrams. I trust data.
That’s why I built a way for my agents to drive live notebooks: they can show me the data while we keep talking. I don’t need to understand every line of code or reconstruct every input before I evaluate the result. Tables and plots land in front of me, and I inspect what the computation produced. Inspecting the output is how I verify what the artifact did and understand its behavior.
Here is the loop running. I ask for the plot out loud, the agent writes the cell and runs it, and the chart in this post appears in front of me. Then I ask for the section word counts and inspect those too. The waits are cut, and each cut says how many seconds it removed.
An AI-authored picture or diagram can explain what the agent understands. That is useful, but it is not an objective representation of what was built. Claude Code artifacts, Thariq Shihipar’s HTML approach, and the ELI5 plugin make those explanations easier to take in. Verification is different. I need to see the actual data, computation, or system state behind the work. That is what widens understanding per minute for me.
A chart of the real output can still mislead me. A bad transformation or the wrong slice can misrepresent something technically real. In a notebook, the chart sits beside the cell that produced it, so I can inspect the transformation and fix it. That trace is what I trust.
The next channel
The next channel is the one between the agent and my environment. I widened it through my second brain and the tooling around it. I will write about that soon.
For now, I keep asking the agent to show me the notebook. I can see the data, decide what I think, and tell it what to change while the decision is still fresh.