The Expression Gap: Better Models Do Not Fix Bad Input

Each model release arrives with benchmarks that suggest a jump in capability, and each release produces a familiar complaint: the answers still feel inconsistent. The reason is rarely the model. It is the request. A vague prompt gives a capable system too many valid interpretations, and the system picks one, often not the one the person had in mind. The disappointment is real, but it is misattributed. People conclude that the model is unreliable when what varied was their input. Stronger models raise the ceiling of what a good request can achieve. They do not raise the floor of what a careless request produces.

There is a version of this pattern in every interface upgrade. A better camera does not make a badly framed photograph good. A faster search engine does not fix an ambiguous query. Capability amplifies whatever it receives, including sloppiness. With language models the effect is more visible because the output is prose that sounds confident regardless of input quality. A weak prompt yields a fluent answer to the wrong question, which is harder to detect than an obvious error. That fluency is why input quality matters more than it did before, not less. The surface looks polished either way, so the difference hides in the details.

Users also adapt in ways that hide the problem. They learn a handful of prompt patterns that work, reuse them, and conclude the model is good at those tasks. Outside the patterns, results vary, and the variation gets blamed on the task being hard. Over time, people quietly narrow what they ask for, which caps the value they get. The tool appears reliable within a routine and unreliable beyond it. The constraint is not capability but the effort of composing a request that conveys the actual goal. That effort is the expression gap in practice. The remedy is not more practice but a channel that rewards explanation.

The practical implication is that investing in better input often beats waiting for a better model. A request that states the audience, the desired format, the constraints and an example of a good answer will outperform a vague request sent to a stronger system. This is not a claim that models do not matter. It is a claim that the returns are uneven, and the cheapest improvement is usually on the human side of the interface. Recognizing that changes what you buy, what you build and what you teach a team. That shift in attention is cheap, immediate and usually neglected.

The expression gap is the distance between what a person means and what their tools can receive. It has three parts. First, formulation: knowing what you want clearly enough to state it. Second, transmission: getting that statement into the system quickly and accurately. Third, correction: fixing what arrived wrong without losing the thread. Most discussion focuses on transmission, because it is the easiest to measure. But formulation and correction usually account for more of the gap in daily work. A tool that speeds transmission while making correction clumsy has solved a third of the problem. The three parts must be solved together to feel like progress.

The gap widens with the complexity of the task. A short request for a definition travels well through any channel. A request that specifies tone, constraints and an example carries much more information, and typing becomes a bottleneck because it is slow and encourages abbreviation. People drop context to save keystrokes, and the output reflects the omission. Speaking changes the calculus because it is faster and encourages fuller explanation. The gap narrows not because the person became clearer, but because the channel stopped penalizing clarity. Clarity is not a virtue the tool can demand; it has to be the path of least resistance.

The gap also has a social dimension. People under-specify requests to colleagues too, and the resulting back-and-forth is familiar. With a person, the recipient can ask a clarifying question. With a system, the clarification is often implicit, hidden in a wrong assumption. That asymmetry means the cost of unclear input is higher with software than with people, because nobody notices the misunderstanding until the output is already wrong. Designing for the expression gap means building in the equivalent of a clarifying question, either before generation or through an easy correction path after it. That is a design opportunity, not a limitation to accept.

Finally, the gap is not a personal failing. It is a design problem. Interfaces that require people to translate thought into a compressed syntax put the burden in the wrong place. Good tools meet people in the mode they already use, which for most thinking is speech. That does not mean every interaction should be spoken. It means the channel should not force a choice between speed and completeness. When an interface removes that tradeoff, the expression gap narrows without anyone receiving training. That is the standard worth designing toward. The alternative is training people to work around the tool.

Bad input is not usually stupid input. It is input written in a hurry, with assumed context, abbreviated terms and a goal that seems obvious to the writer. Sent to a capable model, it produces output that answers a slightly different question, and the writer edits heavily or tries again. The failure is easy to misread as a model limitation. In practice, the same model given a fuller request often performs well. The variable that changed was the amount of meaning in the input. That is a useful diagnostic: before blaming the system, check whether the request contained the information needed to succeed.

Context is the most common omission. A request to summarize a document without saying who will read the summary produces a generic result. A request to draft a reply without the relationship or the history produces something that might offend. People omit this because typing it feels like overhead, and because the context feels too obvious to state. Speech makes it cheaper to include, which is a small mechanical change with a large quality effect. The model cannot use what it does not receive, and the human cannot benefit from what the model does not know. Stating the reader and the goal takes seconds and changes everything.

Ambiguity is the second source of weak output. Words like soon, brief, better and professional each admit a wide range of interpretations. In conversation, tone and shared history narrow them. In a typed prompt, they are bare. A model resolves them by choosing a common default, which may be nothing like the writer's intent. The fix is not to avoid such words but to anchor them, for example with a deadline, a target length or a reference example. Anchors cost a few words when spoken and save a round of revision when written. The economics favor the spoken channel. Anchoring is cheap; ambiguity is expensive to repair later.

The third source is structure. A prompt that mixes goal, background, constraints and examples in one stream gives the model no signal about which part governs. Models are robust enough to extract a lot from a stream, but the result is probabilistic. A prompt that separates the parts produces a more predictable answer. Speaking structured prompts is easier than typing them, because people naturally narrate in a sensible order when they are explaining to a listener. The interface should capture that order rather than flatten it into a run-on sentence. Order is the cheapest structure available, and speech makes it natural.

Designing for human speech starts with accepting that speech is not text with sound. It includes rhythm, emphasis, restarts and implied context. An interface that treats speech as a dirty version of typing will always feel second best. An interface that treats it as the primary mode can be better than typing for many tasks, because it captures more meaning per minute. The design question is not how to make speech behave like a keyboard. It is how to preserve the richness of speech while producing the consistency that written work requires. Preserving it requires design choices that begin before the first word.

The first design requirement is speed of correction. Speech produces errors at a different rate and in different places than typing. Names, numbers and technical terms are the usual failures, and they are exactly the elements that matter in professional text. A correction path that requires re-recording an entire paragraph will not be used. A correction path that lets someone select a word and type over it preserves the advantage of having spoken. The best correction is one that costs less time than typing the whole sentence would have cost. Anything slower will be abandoned after the first frustrating week.

The second requirement is context awareness. A voice layer that knows where the cursor is can adjust formatting, tone and length to the destination. It can also use surrounding text to resolve ambiguity, such as whether a pronoun refers to a product or a person. This is the advantage of a system-level tool over a standalone recorder. The recorder sees audio. The system-level tool sees the document, the thread and the application, and it can use that to reduce the correction burden. Context is the cheapest source of accuracy available. A recorder has no such advantage, which is why it feels like extra work.

The third requirement is restraint. Human speech includes hedging that is meaningful, and a system that removes all of it can make a person sound more certain than they intended. Design should preserve signals of uncertainty where the destination calls for them, and remove them only where the format is casual. This is a judgment about the meaning of the text, not just its surface. Getting it right requires watching how people react to their own polished output, since the speaker is the best judge of whether the result still sounds like them. That feedback loop is the only reliable guide to restraint.

Closing the gap in daily work is less about installing a tool and more about building a habit. The first week should use voice for low-stakes writing: chat replies, short notes, quick prompts. The goal is to learn how the tool responds to your vocabulary and how much editing it requires. Keep the keyboard close, because switching modes is normal and should not feel like failure. By the second week, most people have a sense of which tasks suit voice and which do not. That personal map is more useful than a general recommendation. A recommendation ignores how differently people work.

The tasks that suit voice share a pattern. They require more words than decisions, they have a clear destination, and they do not depend on precise formatting. Drafting an email, summarizing a meeting, describing a bug, writing a status update and composing a prompt all qualify. The tasks that do not suit voice are the ones where every character matters, such as editing code line by line or adjusting a spreadsheet formula. A good routine uses voice for the former and the keyboard for the latter, without treating the boundary as fixed. The boundary moves as confidence grows, which is the point.

Teams that close the gap well do two additional things. They share vocabulary, so product names and acronyms are spelled consistently and corrections converge. They also set expectations about review, so nobody assumes a voice output is final simply because it looks clean. A short note in a team guide, covering the preferred tools, the sensitive topics to handle carefully and the review step for shared documents, prevents most problems. The goal is not to police usage but to make the default behavior safe enough that people keep using it. A short guide does more than a long policy, because people read it.

The measure of success is a reduction in the time between having a thought and having it in a usable form. That interval is where the expression gap lives, and it is observable. Track a few recurring tasks over a month and compare the time to a typed baseline. If the interval shortens and the edits fall, the habit is working. If the interval shortens but the edits rise, the tool needs better correction rather than more usage. Either way, the measurement points to the next improvement, which is more than most productivity changes can offer. Most tools cannot show that, which is why they are hard to defend.