"Humanising LLM Outputs is Dumb" landed on Hacker News on August 10, 2026 and pulled 155 points and 91 comments. The title is doing deliberate provocation work — as several commenters pointed out, nobody using an ADHD-mode skill thinks they are humanising anything. But the argument underneath it is precise, technical, and mostly correct.
Kuber Mehta's claim, in one sentence: style instructions are not post-processing. They sit in the same instruction list as "solve the task, use tools correctly, preserve abstractions, don't break anything" — so an agent told to be concise compresses continuously while working, not after.
TL;DR — the argument in six rows
| Question | Direct answer |
|---|---|
| What's the claim? | Style rules shape the work, not just the write-up — so the compression is lossy |
| Why don't we notice? | "You probably never notice what got dropped because the output still reads nicely" |
| Where does it hurt most? | Agent-to-agent handoffs — prose summaries of prose summaries |
| What's the failure mode? | Humanisation smooths stack traces and conflicting evidence into "a few considerations" |
| What's the fix? | Keep dense state internally; render for humans only at the boundary |
| What's the counterexample? | Claude Code output styles already don't propagate to subagents |
The architectural argument
The essay's strongest passage is an analogy, and it's a good one:
"Databases don't store data in the format a dashboard displays it, compilers don't make their IR pleasant to read, APIs don't exchange friendly summaries. We keep the highest-fidelity representation as long as possible and transform it at the boundary where a human consumes it, but LLM tooling is increasingly doing this backwards."
That's a real architectural principle, and it's one the agent tooling ecosystem has been quietly violating. The concrete example the essay gives is the multi-agent case:
"A subagent investigates a bug, turns its findings into a nice human-readable summary, the parent agent reads that summary, and then turns it into another nice human-readable summary for you."
Two lossy transforms, one of which no human ever reads. What the author wants at the first boundary instead:
5/6 PASS
FAIL: test_cache_invalidation
CAUSE: stale key survives TTL bump
REPRO: tests/cache_test.py:184
Rather than: "Most tests passed, although there was one issue worth looking into."
Anyone who has debugged a multi-agent run recognises the second sentence and what it costs. Prose is unusually good at smoothing away exactly the signals you need — conflicting evidence, unresolved branches, uncertain assumptions, the fact that the agent is near its context limit. The essay's line on this is the sharpest in the piece: "I'd rather find my agent is hallucinating or near its token window than be happy with that."
This is the same failure surface we mapped in graph engineering for multi-agent organizations: the edges between agents are where information dies, and prose edges lose more than structured ones.
The counterexample the thread produced
The most useful comment in the 91-reply thread wasn't agreement — it was a citation. One commenter pointed at Claude Code's own output-styles documentation:
"Output styles apply to the main conversation only: a subagent runs its own system prompt, so styles don't change how subagents respond. A fork is the exception, because it inherits the parent's full system prompt."
That is exactly the architecture the essay is asking for, already shipped. Claude Code's output styles are a renderer, scoped to the human-facing conversation, and deliberately not inherited by subagents. The essay's central multi-agent complaint doesn't apply to that mechanism.
Where it does still apply, and this distinction matters if you're configuring an agent today:
| Where you put the instruction | Does it leak into the work? |
|---|---|
| Output style (Claude Code) | No — main conversation only; forks inherit |
| CLAUDE.md project rules | Yes — part of the standing instruction set |
| A skill invoked during the task | Yes — it's in context while the work happens |
| A final summarisation step / separate agent | No — runs after the work is complete |
| Subagent system prompt | Only that subagent's own output |
So the practical version of the essay's advice isn't "stop asking for concision." It's put the instruction in the renderer slot, not the operating-instruction slot — a distinction our guide to steering Claude Code with CLAUDE.md, skills, hooks, and subagents breaks down mechanism by mechanism. One commenter arrived at the same conclusion independently: they liked the ASD-STE100 skill but wanted it "to only be used at the final step, when it finishes something." That's the whole thesis, restated as a feature request.
Is it actually "lossy"? The honest answer
The essay asserts lossiness. Two comments pushed back well enough to warrant qualifying it.
The direct objection: "Is it lossy though? You can tell it to use Simplified Technical Language and also still have it give you all the detail. It's not like there's 'pure' LLM output and then 'lossy' output guided by a prompt."
The better-calibrated defense, from a reply that gets the mechanism right:
"There's no way (currently) to give instructions for how to format the output that don't also affect all of the 'reasoning' along the way. So if you tell it to do everything normally, but to end every response with 'Cheers', you won't just get that; you'll get different responses than you would have otherwise... I think it's more likely to be harmful than helpful, given the models were tuned for their default state, but it is more of a random perturbation with a slight negative bias than a strict loss."
Random perturbation with a slight negative bias is the accurate framing. There is no formatting-only channel in a transformer prompt. Everything conditions everything. Whether that perturbation costs you depends on whether the instruction pulls against the task — "be concise" competing with "enumerate every failing test" is a real conflict; "use short sentences" while refactoring probably isn't.
Which means the essay overstates the mechanism and gets the prescription right anyway. That's a fine trade.
Why this went viral: the readability problem is real
The thread's energy didn't come from architecture. It came from people who cannot stand reading current-generation model output.
The top comment set the tone, describing the experience of parsing phrases like "direct model calls as replaceable semantic workers" as reading flowery literature where you finish a paragraph and realise you absorbed nothing. Their fix is a post-hoc prompt: "Go back and decompress any LLM-speak in light of the higher level task goals. Eliminate deictic language."
Others were blunter:
- "They constantly produce a huge wall of text no human expert on a specific topic would ever write. Extreme overuse of jargon and invented terms / metaphors."
- "Opus 5 [is] so bad on this. It often explain[s] it too verbose, and include[s] other things that isn't in the focus but related."
- A running joke about "load-bearing" as a stock modifier, including a reported dig from a rival model about "a lot of load-bearing prose without making a point."
One commenter contributed a poem assembled entirely from LLM tics — "Great question — real. Let's dive right in", "the quiet part out loud", "load-bearing heart", "your tapestry" — which is the most efficient demonstration of the problem anyone in the thread produced.
Where does the style come from? A comment citing research on base vs. instruction-tuned models makes the important correction: the quirks are not inherited from pretraining data. When you compare a base model against its instruction-tuned variant, it's the tuned variant that develops the characteristic style. The tics are a product of post-training — human rater preferences and the task mix used in instruction tuning — not of the web's writing habits. That matters because it means the labs can fix it and are choosing their current point on the trade-off deliberately. One commenter's read: OpenAI has pushed reasoning toward terse, token-efficient language while Anthropic has gone the other way.
The cost angle nobody frames as the main problem
One comment cut through the aesthetics:
"All that flowery, descriptive, metaphor laden language has a point. It is running up your bill."
This is the version of the argument that survives contact with a finance team. Output tokens are the expensive column in nearly every provider's pricing table, and verbose reasoning multiplies them. It's the same dynamic we covered in why AI companies want you using agents and in the cost-per-task analysis behind Sonnet 5's permanent pricing — per-token rates barely move compared to how many tokens a model burns to say the same thing.
There's an unresolved tension between the two arguments, though, and it's worth naming rather than papering over. The essay wants agents to keep more state internally — dense, structured, high-fidelity. The cost argument wants fewer tokens. Structured state is usually more compact than the prose describing it, so these mostly agree. But "preserve the raw findings through every hop" and "minimise tokens" will collide in long agent chains, and you'll have to pick per boundary.
What to actually change in your setup
Concrete, in order of leverage:
- Move style rules out of standing instructions. If concision lives in your CLAUDE.md, it's shaping every task. Move it to an output style or a final rendering step. See steering Claude Code for which mechanism has which scope.
- Make subagent returns structured, not narrative. Ask for test counts, file:line references, exact error strings, and an explicit confidence or uncertainty field. The subagents and multi-agent workflows guide covers how to specify return contracts.
- Add a dedicated final summariser. A separate step — or a separate agent — that reads the dense state and renders it. This is what the essay is actually arguing for, and it's a five-minute change. Package it as a skill so it's invocable rather than always-on.
- Keep the raw artifact. The top HN commenter's practice is worth copying: retain full agent output for future agent consumption, generate the readable version separately for yourself. Two representations, one canonical.
- Don't confuse this with the accessibility case. The author is explicit — "none of this is an argument against accessibility or personalisation... I just think it's better to do it at the end." Several replies objected to the ADHD framing in the title, which is fair criticism of the headline and not of the architecture.
Where I'd push back
The essay's closing line is that the viral skills "aren't the end state, but a bug report" — users patching at the prompt layer something that belongs further down the stack. That's a good line and I mostly agree with it. Two caveats:
- Part of the bug is already fixed. Output styles that don't propagate to subagents are the stack-level fix, shipped. The gap is that most users don't know which of their configuration surfaces are renderers and which are operating instructions — which is a documentation and defaults problem more than a missing-feature problem.
- The default isn't sacred. "Models were tuned for their default state" is a real argument for not perturbing them, but the default state is itself a post-training artifact optimised against rater preferences, not against your task. Sometimes fighting it is correct. Measure on your own workload rather than assuming either direction — the same discipline our context engineering guide applies to prompt structure generally.
Bottom line
The essay is right about the architecture and slightly overstated about the mechanism. Style instructions genuinely sit in the same context as the task and genuinely influence the work, though "random perturbation with a slight negative bias" describes it better than "lossy compression." The multi-agent prose-summary-of-prose-summary pathology is real — but Claude Code's output styles already avoid it by scoping to the main conversation, which is the fix the essay is asking for.
The durable takeaway is the one every other layer of computing settled decades ago: keep the high-fidelity representation until the last possible moment, then render. Agents exchange structured state. Humans get prose. Not the other way around.
Related on explainx.ai
- Steering Claude Code: CLAUDE.md, skills, hooks, subagents, and rules — which surface is a renderer and which is an operating instruction
- Claude Code subagents and multi-agent workflows — specifying structured return contracts
- Graph engineering for multi-agent organizations — where information dies between agents
- What are agent skills? Complete guide — packaging a summariser as an invocable step
- Context engineering: clean prompts that hold up
- Loop engineering for coding agents
- Why AI companies want you using agents: token economics — the cost side of verbosity
- Cognitive debt: what happens when you stop reading LLM code
- Claude Sonnet 5 pricing made permanent at $2/$10 — why token efficiency beats per-token rates
Primary sources: Kuber Mehta, "Humanising LLM Outputs is Dumb," kuber.studio (August 10, 2026) · Hacker News discussion, 155 points / 91 comments · Claude Code output styles documentation · ASD-STE100 Simplified Technical English specification
Accurate as of August 11, 2026. Comment quotes are reproduced from the public Hacker News thread; contributors are described by their argument rather than by username. Claude Code's output-style scoping reflects the documentation as quoted in that thread — verify against current docs before relying on it. Follow @explainx_ai for updates.