What happens when humans compress information before prompting an LLM?

When someone describes a bug, a symptom, or a problem to an LLM, they aren't transmitting the full state of what they observed. They're transmitting a summary — one already filtered through what they noticed, what they judged relevant, and what they had the vocabulary to describe. That compression happens before a single token reaches the model.

This is easy to overlook because it's invisible in most evaluation setups. Benchmark prompts are usually written carefully, with the relevant information already extracted and stated plainly. Real prompts, written by people mid-task, look nothing like that: they're partial, sometimes mis-prioritized, and shaped by whatever mental model the person already had going in.

The open question is how much this human compression step actually degrades — or occasionally improves — downstream model performance, compared to giving the model more complete, less-filtered information. It's plausible that human summarization helps, by discarding true noise. It's equally plausible that it hurts, by discarding a detail that only looks irrelevant to a non-expert but is exactly what the model needed.

This sits at an unusual intersection: it's not purely a prompting question, and it's not purely a human-factors question — it's about the interface between the two, where a lossy human channel feeds into a model with its own separate failure modes. Studying it well requires holding the model fixed and varying only the compression step, which is a harder experimental design than it sounds, since 'the same information, less compressed' has to be defined and produced deliberately rather than assumed.

It's an early, exploratory line of thinking rather than a settled result — but it points at something that matters for anyone building AI tools for non-expert users: the gap between what a person experienced and what they typed might be a bigger source of downstream error than anything about the model itself.