Humanising LLM output should happen at the boundary, not mid-task
A blog post on kuber.studio argues that the current wave of instructions telling AI agents to write like a person with ADHD, or in the ASD-STE100 Simplified Technical English standard used for aviation manuals, is solving a real problem at the wrong layer. The author's point: these style rules do not get applied after the model finishes its work. They sit on the same instruction list as the actual task, such as solve the problem, use tools correctly, preserve abstractions, do not break anything. Telling an agent to use short sentences, avoid jargon, never overwhelm the reader and include only the most important details means asking it to continuously compress its output into a lower-bandwidth format as it works, and that compression is lossy. The reader usually never notices what got dropped because the compressed output still reads smoothly.
The author extends the argument to agent-to-agent handoffs. A subagent investigates a bug and turns its findings into a human-readable summary, the parent agent reads that summary and turns it into another human-readable summary for the person waiting on the result, so the loss compounds at each step. His illustrative example: if a subagent ran six tests, he does not want a line like 'most tests passed, although there was one issue worth looking into'; he wants the actual per-test detail. More importantly, he argues, humanisation hides failure. Agents fail in useful, ugly ways: conflicting evidence, unresolved branches, stack traces, uncertain assumptions, and human prose is very good at smoothing all of that into a reassuring sentence like 'there are a few considerations here.' He says he would rather find out his agent is hallucinating or near its token window than be reassured by prose like that.
The proposed fix draws on an analogy with other kinds of software: databases do not store data in the format a dashboard displays it in, compilers do not make their intermediate representation pleasant to read, and APIs do not exchange friendly summaries between each other. Those systems keep the highest-fidelity representation as long as possible and transform it only at the boundary where a human consumes it, and the author's claim is that LLM tooling is increasingly doing this backwards, baking the human-facing tone into the agent's own working state. He is careful to say this is not an argument against accessibility or personalisation. Three-line answers or Simplified Technical English are fine, he writes, if they are applied at the end, at the rendering boundary, rather than threaded through the agent's operating instructions. In his framing, the current crop of viral 'talk to me like I have ADHD' style skills and instruction files makes sense as a renderer but much less sense as an operating instruction, and the durable version is agents whose native language is precise, machine-facing state, with a warm, concise human version generated only at the boundary. He concludes that these viral instruction sets are not the end state of the trend but a bug report pointing at an unmet need further down the stack.
The piece does not name any specific model, vendor, product, or the 'viral GitHub repositories' it references, and cites no data or study behind the lossy-compression claim; it is presented as the author's own reasoning. On Hacker News the submission drew 190 points and 118 comments within about 17 hours.
Key facts
- Folding style instructions (short sentences, no jargon, ASD-STE100 Simplified Technical English) into the same instruction list as the actual task turns the agent's own output compression into a lossy process, per the author.
- Readers usually do not notice what got dropped because the compressed output still reads smoothly.
- In agent-to-agent handoffs the loss compounds: the author's example is that for a subagent that ran six tests, he wants the raw per-test detail, not a line like 'most tests passed, although one issue is worth looking into.'
- Humanised prose hides failure signals such as conflicting evidence, unresolved branches, stack traces and uncertain assumptions; the author says he would rather learn his agent is hallucinating or near its token window than be reassured by smoothed-over prose.
- The proposed fix, by analogy with databases, compilers and APIs: keep an agent's internal state as precise, machine-facing schemas, diffs, exact errors, confidence and provenance, and apply humanising or simplifying instructions only at the final boundary where a human reads the result.
Why it matters
The post reframes a popular fix, telling agents to write more like a person, as a design mistake rather than a style choice. If tone instructions sit inside the same instruction list as the task itself, the compression they force happens during the agent's actual reasoning and work, not after it, so information that might matter gets discarded before anyone sees it. That has direct consequences for anyone relying on an agent's summary to judge whether a task actually succeeded.
Who it affects
Anyone writing custom instructions or 'skills' for coding agents and AI assistants, including the kind of Agents.md files and prompts that tell a model to 'talk to me like I have ADHD' or to answer only in short, plain sentences. It also affects people building pipelines where subagents report findings up to a parent agent, since the author argues each summarisation step compounds the same lossy compression.
How to use it
The author's practical suggestion is to keep an agent's native working state precise and machine-facing, exchanging schemas, diffs, exact error messages, confidence levels and provenance between agents, and to apply any humanising, simplifying or accessibility-driven style rules only once, at the final point where a human actually reads the output, rather than as an instruction the agent carries through the whole task.
How solid is it
This is an opinion and reasoning piece, not a study: the source cites no data, benchmark or measurement behind the lossy-compression claim, and presents it as the author's own argument. It names no specific model, company, product or 'viral GitHub repository', keeping every example generic. It gained traction on Hacker News, drawing 190 points and 118 comments in about 17 hours, which signals resonance with the argument rather than evidence for it.
Risks and caveats
The author is explicit that this is not an argument against accessibility or personalisation: three-line answers or Simplified Technical English are fine in his view, provided they are applied at the rendering boundary rather than baked into the agent's operating instructions throughout a task. No author name, publication date, or named tools appear in the article text itself; the piece's identifying details come only from surrounding metadata, not the article body.
“I’d rather find my agent is hallucinating or near its token window than be happy with that.”
— the post's author, kuber.studio