You can write in LLMese, but you don’t have to

While chatting with Sarah Deaton about the formats agents could use to talk to each other, we got to questions that might sound obvious: why should machines (say, LLMs) communicate with each other like we do? Do they need all the rhetoric we carry around? Or could they get by with a terser register, one that carries the same meaning but in far fewer tokens?

Heh, of course science fiction got there first

I’m a huge fan of Iain M. Banks’s Culture novels. In almost all of them, the Minds, almost god-like AIs, don’t talk between themselves like we do. Banks renders mind-to-mind messages as pseudo-technical headers; buried within, the actual message, which is usually dry and witty like a jab. Decades earlier, Isaac Asimov explored the same idea. Two of his robots, R. Daneel and R. Giskard, talk to each other in Robots and Empire using a highly compressed language.

They spoke in an abbreviated and Aesopic language. They understood each other well, with many decades of communication behind them, and it was not necessary for them to involve themselves in all the elaborations of human speech.

Daneel said in an all but unhearable whisper, “Clouds. Unseen.”

Had Daneel been speaking for human ears, he would have said, “As you see, friend Giskard, the sky has clouded up. Had Madam Gladia waited her chance to see Solaria, she would not, in any case, have succeeded.”

Our LLMs are not minds from the Culture, nor Asimovian robots (I wish they were). They’re not intelligent, nor have a will of their own. What they do have, though, is an appetite for tokens. This turns the question into a fairly banal logistical issue: could we rewrite the docs into a register meant for models and still get good answers? Could we write, for lack of an uglier word, in LLMese?

Trying to compress meaning in fewer tokens

I made a small prototype to find out, llmify. The prototype takes a document, compresses it into something an LLM can (supposedly) digest, and then measures two things: how many tokens you saved, and whether the model can still answer questions about the content as well as it could from the full doc, using the same set of questions for evals, and the same model.

I compared three ways of compacting docs. The first two are semantic rewrites: one outputs terse Markdown (have a look at the Claude Skill), while the other outputs a stricter line grammar suggested by GPT after exploring various ideas. The closest published analogue I found is Telegraph English, a prompt-compression protocol that also rewrites prose into structured, atomic statements, though I found out about it too late to include it in the experiment. The third method relies on LLMLingua-2, which uses a specially trained model to prune tokens. Although it is built for prompts, I included it to see how pruning performs against semantic rewrites.

I ran the experiment on two documents: the dense Admission Webhooks Good Practices page from the Kubernetes docs, and a doc made by GPT 5.6 on a piece of fictitious tech, VesperGate. The idea was to compare how the model fares when it has prior knowledge of the subject versus when it has none. Here’s an original rule from the VesperGate source (it reads like technobabble from a Star Trek episode, something I find quite amusing):

The Lantern receives a Twine and evaluates it against one Lockbook. A Twine is not an API token. It is a signed factual envelope created by the Oriole scheduler. If an operator sends a Twine directly to the Lantern CLI, the Lantern must reject it with VG4032 direct-twine-refused.

Do not summarize all non-clear locks as “deny.” pale does not deny. amber does not deny. mirror allows the request but records an alternate deny result. Only dusk, dim, and dark block the mutation, and each implies a different remediation.

The Markdown profile keeps it as terse bullets while retaining relevant distinctions:

- Lantern receives scheduler Twine and evaluates against one Lockbook. Direct Twine to Lantern CLI rejected: `VG4032 direct-twine-refused`.
- `pale`: `preflight` defer; rollback `vg lockbook thaw --reason pale-timeout`; only incomplete facts.
- `amber`: `bind` delay; rollback `vg lockbook release --class amber`; retry may use same Twine.
- `mirror`: `bind` shadow-allow; rollback/action `vg lockbook promote-mirror <id>`; admits and records would-have-denied.
- Do not summarize all non-`clear` as deny: only `dusk`, `dim`, `dark` block. `pale` defers; `amber` delays; `mirror` allows.

The line grammar turns the same material into typed records:

RULE direct.twine | IF operator sends a Twine directly to Lantern CLI | MUST reject with `VG4032 direct-twine-refused`.
DEF color.pale | `pale`; preflight defer; rollback `vg lockbook thaw --reason pale-timeout`; does not deny.
DEF color.amber | `amber`; bind delay; rollback `vg lockbook release --class amber`; does not deny.
DEF color.mirror | `mirror`; bind shadow-allow; admits request while recording would-have-denied; does not deny.

LLMLingua, pruning for tokens, reads like this:

Lantern receives Twine evaluates Lockbook signed factual envelope Oriole scheduler
operator sends Twine reject VG4032

The LLMLingua version keeps the entities but drops the relationships around them. That pruning can be quite destructive is not news: researchers have watched this happen already. In QUITO-X’s paper (2025), LLMLingua kept the main nouns of a sentence, “barn” and “farmhouse,” and threw away “near,” which was enough to send the model to the wrong answer about where a cat lived.

If you feel curious, you can find a full set of excerpts for all three methods in this gist.

You can be terse to LLMs after all

OpenAI’s GPT generated eight questions per original document, then generated the compressed versions for each of the three modes, and finally evaluated the answers against the full source. The results are in the following table (I used GPT 5.5 in all cases and for all operations):

The first thing that surprised me is that the semantic rewrites stood their ground pretty well. The first profile cut the tokens of the Kubernetes doc in half and the model received full marks on every question. The LLMLingua pruning, on the other hand, compressed aggressively but lost some facts, leading to lower scores and several regressions. The second interesting result is that with the fictional doc, the semantic methods couldn’t compress as much.

Could GPT compress meaning more effectively when it has prior knowledge of the subject? I find that plausible. The model could lean on its prior knowledge of Kubernetes to reconstruct omitted details, but it had no such advantage with VesperGate. The two documents differ in too many other ways to isolate prior knowledge as the cause, though.

My small experiment has other problems. One is that LLM judges tend to reward text that looks familiar to them, so a model grading its own output may be biased. A recent study of prompt compression argues that downstream accuracy alone is a poor gauge. Other problems include:

• The same model did it all.
• Questions weren’t inspected for coverage or difficulty.
• I ran this only once, so it’s impossible to detect variance.
• There might be a ceiling effect at play.

Still, in a model-to-model setting, the results are quite interesting. The semantic rewrites preserved enough information to answer the evaluation questions without regressions.

So, should we write in LLMese?

The comparison with Asimov’s robots and Banks’s Minds only goes so far. Their language rests on shared experience and a shared model of the world. The register in this experiment was generated externally from a source document and tested against a particular task. Good old garbage in, garbage out still applies: remove too much information and answers go banana.

Rewrites are an editorial, human choice. They belong to the same class of decisions a writer makes when selecting what goes in a quickstart and what gets left for the reference. This is also the case made by approaches such as SCOPE and Telegraph English: deleting tokens tends to cut the connective tissue between facts, so rewriting each passage fares better than deleting stuff.

So, my answer is yes: you can compile human writing to some dialect of LLMese, but only if you really need to save tokens, and only if you have ways of ensuring that meaning isn’t lost. If it makes sense in your pipeline, you might as well give it a go.

But didn’t I say not to write for machines?

I did. I argued that if you write well for humans you’re already writing well for machines, and that the only thing that really changes is how you package the output. “But Fabri, here you’re talking about a language tailored to LLMs. Isn’t that the definition of writing for the machine, of bowing to the whims of our new silicon overlords?!”

Yes, except nobody wrote in LLMese; it was “compiled”. The human doc is the source and the profile is built, much in the same way an llms.txt file or a PDF is, although what we’re dealing with here is probabilistic. The compiler only carry what the source holds. Here I’m treating LLMese as a new format for delivery, not as source, and certainly not as an authoring tool.

Perhaps influenced by my science-fiction leanings, I wanted to fall into the trap of pretending LLMs had their own parlance. I admit it: I wanted to see if GPT could read a compact register and still answer questions. But the model doesn’t really read like we do, because, well, it’s not human and it’s not able of understanding anything. A mind from the Culture would not be impressed.

My original advice still stands, enriched: do not author for machines, author for humans, then generate and test machine-oriented representations from human-oriented sources as required.