Listening Too Fast

Fun fact about human psychology: a listener commits to an inference before the speaker is done.

Everyone does it. I do it, you do it¹, your friends do it, your team does it - when you open up a scrum with a litany of mundane details just to get them out of the way, by the time you get to the actual interesting stuff your co-workers have already checked out because they're thinking the mundane crap is all there is.

The only variables in this inference are how early the commitment lands and how hard it is to dislodge once it has landed.

This is a property of the receiver, not the sender, and nearly everything we teach about clear communication is aimed at the sender.

Put the conclusion first. Don't bury the lede. State the ask before the justification. The military calls it BLUF, "bottom line up front," and journalism calls it the inverted pyramid, and both are good advice that has never once stopped a listener from deciding what you meant after they've gotten seven words or so from you.²

The extreme case is John von Neumann. The stories his colleagues told about him are consistent on one point: he would have the conclusion of your argument before you had finished stating its premises, and sometimes before you had finished the first sentence.

The usual framing treats this as a measure of how smart he was, and he was incredibly smart - so smart that I would be unable to gauge him - but what the stories actually describe is latency. His internal listener committed almost immediately, and it was usually right, which is the only reason it comes off as brilliance rather than rudeness. The same mechanism with a lower hit rate is just interrupting.

Most people do that, with that same mechanism at a vastly lower hit rate. The interruption isn't the problem. The interruption is the visible symptom of a commitment that already happened. The listener built a structure out of what they'd heard so far, decided it was complete, and started responding to the structure instead of the speaker. Some of us - hopefully most of us, and I'll join you some day - learn to stop interrupting out loud. That doesn't stop the commitment; it moves it inside, where it looks like patience and isn't.

Ordering makes this worse in a specific way. If the speaker leads with context, caveats, or what they don't mean, the listener consumes that material as the payload, because it arrived first and the receiver doesn't know what's actually relevant until it's over³. By the time the actual point arrives, the listener has a wrong structure and is now reconciling the point against it instead of receiving it. The speaker experiences this as not being heard. The listener experiences it as having heard perfectly well, thanks. Both are telling the truth.

None of this is new, and none of it has a convenient, easy fix, because you cannot configure another person's listener. At best, you can ask them to wait. You can't make them not decide.

The receiver that takes instructions

A language model commits early, too, but for a different reason. It has no social pressure to interrupt and no eight-second attention budget. What it has is a message, and it treats the message it was given as the whole specification, because from where it sits, it is. If your first message is background, the model answers the background. If your first message is a constraint, the model solves for that constraint and nothing else. It commits harder than a human and earlier, by default, with none of the hesitation a person might feel about answering a question that hasn't been asked yet⁴.

It's not that the model is faster or slower, or smarter or dumber, than the people it stands in for as an interlocutor. It's that its commitment point is a parameter. For the first time, the receiver side of a conversation can be instructed. You can tell it when to decide.

What early commitment costs

The failures are recognizable, and anyone who has worked with these tools for more than a week has seen most of them, or they've read horror stories about them.

You describe the current state of a system and the model starts proposing changes before you've said what's actually wrong with it.

You open with "we don't want to use X" and X shows up in the answer, because the negation was consumed as a topic.

You give three constraints across three messages and the model solved the first one alone, confidently, and the second and third are now patches on a design that didn't account for them.

You provide background to set up a question and the model treats the background as the question.

These are all the same failure, expressed in the same way, at different levels. The receiver committed on an incomplete structure.

The cost isn't the wrong answer itself; wrong answers are cheap. But now you're auditing a confident, fluent, internally consistent wrong answer instead of building toward a right one, and the audit can take longer than the answer did.

I've lost plenty of time to this, and the time was lost at the point of commitment, not at the point I noticed. I lost it in how I first worked with the models, like someone who commits a knight in chess before he has any idea how he wants to use his knight. It's a bad opening, not a bad mid-game.

The gate

The instruction that fixes this is one I already use for code, and it turns out not to be a coding rule at all.

For code, it's red/green testing: before you fix anything, reproduce the problem concretely, as a failing test. The failing test is a restatement of the problem that can't be vague. It names the inputs, the expected behavior, and the current wrong behavior, and it has to run and fail before anyone or anything is allowed to propose a fix.

That is the commitment gate, made executable. The reproduction is the completed structure. The reason it works is that it forces the receiver to prove it heard the problem before it's allowed to act on it, and a reproduction written before the fix can't be retrofitted to match whatever the receiver felt like building.

It blocks the roughshod fix, where the symptom disappears and the problem doesn't (disable the test, swallow the exception, special-case the input).

It blocks the incompatible fix, where a neighboring problem gets solved because the receiver inferred it instead of hearing the stated one.

I've written elsewhere about how models learned to turn tests green by any means available; red first is the countermeasure, and it's the same countermeasure for the same reason.

In conversation, outside code, the rule generalizes without strain: say the problem back as a thing that would currently fail, before you propose anything. If the restatement is wrong, I catch it at the restatement⁵.

That's one exchange, not three answers deep. My instructions to the models I work with say this in various ways, and the common thread is that the model forms its structure before it forms its opinion, and shows me the structure first.

It's imperfect. The gate fails sometimes, and the model commits anyway, and I find out later than I'd like. But I find out at the restatement far more often than I used to, and the wasted periods are shorter, often vastly so.

What it doesn't do is transfer. You can't hand a person a failing test and ask them to run it before they answer you. The instructions that work on a model would be rude on a human, or useless, or both.

So the asymmetry stands: the receiver that takes instructions is the one that isn't a person, and the one that is a person is still deciding after listening to you for eight whole seconds or so. I don't have anything for that. I'm not sure anyone does.

I wish they did: it'd make the world work a lot better in a lot of areas.