The Consumer Test for AI Output
Ask who reads it: machines get generated output, humans get your compressed thinking.
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 6
- Confidence
- 65%
The test is a single question asked before generation: who consumes this? Machine-facing artefacts — code, config, specs handed to another agent — are legitimately written by machines, because the consumer is a machine and the only criterion is that it works. Human-facing artefacts are different: the reader is spending attention, and generated prose is characteristically verbose and clinical, so handing it over transfers your work onto them. For those, AI is confined to the upstream role of brainstorming, generating synonyms, and pulling in tangential material, while you do the thinking, ruminate on it, and compress to the shortest form that carries the insight. The practical heuristic is brutal: if the prompt contained the whole idea, send the prompt.
Origin
Extracted from Naval. Naval defends his own practice on the panel — he uses AI to write code because code is consumed by a computer, but refuses to hand generated prose to a human reader.
Core principles
- 01Code is consumed by computers, so a computer may write it.
- 02Prose meant for a human is a claim on that human's attention.
- 03Good writing and good speaking are the output of good thinking.
- 04Volume is the tell; compression is the value.
- 05If your AI writes it and their AI reads it, neither of you is in the loop.
How to run it
- 1
Name the consumer first
Before opening a model, state plainly whether the output will be executed by a machine or read by a person. Everything downstream follows from that answer.
Pro tip Artefacts handed to another person's agent count as machine-facing — write the markdown brief, not the essay.
- 2
Generate freely for machine consumers
For code and machine-readable specs, use the model as heavily as you like. The consumer does not care who wrote it, only whether it runs.
Pro tip This is where the elaborate harnesses and agent fleets earn their keep.
- 3
Confine AI to the upstream role for human consumers
Use the model to brainstorm, offer synonyms, surface associated ideas and pull in tangential information — then close it before drafting.
Pro tip Arguing with the model is a legitimate use; it sharpens your own position.
Watch out Models on heavy guardrails will steer the brainstorm; treat pushback as a prompt to check the claim yourself, not as a verdict.
- 4
Do the thinking and write the draft yourself
Sit with the material, understand it, and produce the draft in your own words. The writing is where the thinking happens, and skipping it costs you the ability to think and speak well.
Pro tip If you cannot say it out loud clearly, the draft is not finished.
- 5
Compress until only the nugget survives
If you did start from generated text, rewrite it down rather than trimming it. Make the point as succinctly as possible out of respect for the reader's time.
Pro tip Very short writing is also the hardest thing to imitate, since summarisation is where generated prose is weakest.
Watch out Length signals to a reader that you spent their time instead of your own.
- 6
Send the prompt when the prompt is the idea
If everything of value was already in your instruction, forward that instead of the expanded output. It is shorter, more honest and more useful.
Pro tip This works as a habit for internal updates and briefs, not just for public writing.
In the wild
Naval concedes on the panel that he does use AI to write code, then draws the line explicitly: code is meant to be consumed by another computer, so a computer should write it. Anything intended for a human reader gets the opposite treatment — he wants to understand the material, ruminate on it, respect the reader's time, and hand over the insight rather than a generated draft. His stated fear is the end state where his AI writes to your AI and neither person is in the loop.
→ One consistent rule that permits heavy AI use in engineering while protecting the quality of everything human-facing.
In the middle of the debate, one panellist keeps pushing back on generated prose with the same line: why not just send the prompt? If the writer gave a model a short instruction and forwarded the expanded result, the recipient can read the instruction in seconds instead of wading through the expansion. Applied as a team norm for internal updates, the practice collapses long generated status documents back into the two or three sentences that actually carried information.
→ Internal comms shrink dramatically with no loss of content, and the padding becomes visible to everyone.
Common mistakes
Trimming generated prose instead of rewriting
Editing down a generated draft keeps its structure and its clinical register; the compression has to be done by you, from the idea, or the tell remains.
Assuming the reader cannot tell
Readers who value writing spot it, and once spotted the piece is discounted entirely regardless of whether the underlying argument was good.
Outsourcing writing and losing the thinking
Writing and speaking are outputs of thinking, so delegating the drafting atrophies the underlying skill along with the ability to argue well in real time.
Is it for you?
Best for
Anyone shipping both machine-facing artefacts and human-facing writing who wants one rule for when generation is legitimate.
Not ideal for
Purely internal scratch work, or contexts where the reader has explicitly asked for exhaustive generated volume.
From the transcript
“code is meant to be consumed by another computer. It's not meant to be consumed by a human.”
“Everything the AI wrote should instead be compressed down by you”
“Otherwise, their AI is gonna end up reading your AI, and neither of you are in the loop.”
From the episode
Live in the Future