Demonstrate Over Tell

Your AI now writes more than your people can read. The fix isn't shorter summaries or more pictures — it's handing them something to recognise instead of something to reconstruct.

Scott Farrell · LeverageAI · September 2026

The best website our agents ever built had a row of fake text messages laid over a photograph of people pouring tea.

It was a wide, shallow image across the top of the page. On the right, the people and the cups — the human side of the business. On the left, a short thread of messages, styled and floating over the photo: someone asking for something, the service replying, the thing getting sorted. I looked at that page for a long time. It was obviously better than everything else the agents had produced. I couldn't say why.

I'm not a graphic artist or a website designer. I'm not a brand expert. I struggle to even judge which of two pages looks better. So I asked Claude, and it looked at the page and said: it's because it's demonstrating the product. It's not just telling you what the product does. It's demonstrating it.

Oh.

We turned that sentence into a nudge — four words, demonstrate over tell — and added it to the prompt. Any time we put it in, every model we tried got the idea. They put a demonstrating element on the page: messages over an image, a filled-in form, a before-and-after. We never told them how.

That's a finding about websites. It's also, I've come to think, the finding I'd been circling for months in three other places: the whiteboard images we generate after meetings, the way I want my coding options presented, and the little menu that pops up when I reject an image. They're all the same move. This article is about that move, because it's the thing most organisations are getting wrong now that their AI writes more than their people can read.

The model got faster. Reading didn't.

Chris, who I work with, has been telling me for a while that he doesn't read things. He skim-reads. As far as he's concerned, writing more than about 20 words is pretty useless. That's Chris's rule, not a law of nature. But it describes the receiving end of most AI output better than anything in the vendor decks.

We transcribe all our meetings now and put them into our IP wiki. Chris wants them more and more summarised, and then he wants to-dos out of them. And I know people don't follow the to-dos, so that's pretty useless too. Worse: summarising in increasing levels just means you've lost anything that was useful there.

The research on reading has been blunt about this for decades. In Jakob Nielsen's early studies, "79 percent of our test users always scanned any new page they came across; only 16 percent read word-by-word."¹ A later analysis of 45,237 page views estimated that "on the average Web page, users have time to read at most 28% of the words during an average visit; 20% is more likely."² That's a time budget, not a comprehension score — but it's the time budget your AI output is competing for.

Meanwhile the volume went vertical. An agent will write you a 3,000-word analysis before you've finished your coffee. It'll summarise every meeting, extract every action, draft every status report and build every page of a company's website. When that output lacks substance, researchers now have a word for it — "workslop" — and the cost they describe is exactly the one I mean: it "shifts the burden of the work downstream, requiring the receiver to interpret, correct, or redo the work."³

My version is simpler. Whenever I've got options in coding — a few different ideas — I say: don't wall-of-text me. Write me a web page about it and let's discuss it. I don't mind reading things that are valuable. I sometimes listen back to a detailed AI description for twenty minutes and immerse myself in it. But I don't always have that twenty minutes, and a wall of text makes me pay it up front just to find out whether it was worth paying.

The objective isn't to abolish depth. It's to stop making a wall of text the price of admission.

So change the scoreboard. The measure of AI communication isn't words produced, summaries generated or tasks extracted. It's correct shared understanding per unit of human effort. That's the same economics as The Mature Token Law — spend machine cognition lavishly, spend human attention ruthlessly — applied at the one place most teams never look: the moment the output meets a person.

The reconstruction tax

Here's the mechanism, and it's the whole article in miniature.

When an AI tells you something in prose, it's handing you a description of a thing it already has — a product experience, a set of relationships, an hour of discussion, a trade-off between options. To understand it, you have to rebuild that thing in your head, one sentence at a time, holding the early parts in memory while you read the later ones. I call that work the reconstruction tax. The reader pays it, every time, and shortening the prose doesn't refund it. A three-line summary of a complex trade-off still has to be reconstructed; it just has fewer pieces to do it with.

Larkin and Simon described the tax almost word for word in 1987. Diagrams "display information that is only implicit in sentential representations and that therefore has to be computed, sometimes at great cost, to make it explicit for use."⁴ In a diagram, "information is organized by location," so "problem solving can proceed through a smooth traversal of the diagram."⁴

Recognition is the cheap operation on the other side of the ledger. "Recognition is easier than recall because it involves more cues."⁵ When you can see the thing, the thing supplies the cues. When you have to build it from a description, you supply them yourself.

This is why my whiteboard images work, and it's worth being precise about why, because the easy explanation is wrong. When someone in a meeting gets up and starts drawing on the board, it's for a reason. You've learned it's a way to get a lot of meaning across without sitting there, monotone, giving a speech. But a whiteboard isn't an alternative to text. It's text, spatial arrangement and relationships working together. The words are still there; they've just been placed so the relationships between them are visible instead of narrated.

I wrote about the machine side of this in The Skeleton of a Visual: the shape of a thought is a first-class representation, distinct from both its prose and its rendering. Feed a model a slab of text and it has to reconstruct the shape you threw away. It turns out people are the same. Hand a person a slab and they pay to rebuild the structure the machine already had.

So the working question isn't "should this be visual?" It's: what arrangement makes the relationship or choice easiest to inspect? Sometimes that's a diagram. Sometimes it's two options side by side. Sometimes it's a demonstrated moment. And sometimes it's still one excellent sentence.

Demonstrate over tell

Back to the tea-pouring page, because the most revealing detail is easy to miss: the winning visual still contained text. It wasn't images instead of words. It was words placed inside a recognisable situation, where they demonstrated something happening.

Each half did a different job. A photograph alone could have been pleasant but generic. The messages alone could have looked like a software feature. Together they made the connection between the machinery and the human outcome visible. The visitor didn't have to construct an imaginary product from a description. They saw a useful moment of it happening.

Call it a miniature worked example. It doesn't move and it isn't interactive, but it lets someone follow the sequence: this happens, the service responds, this is what I get. Education research has a name for why that works. The "worked example effect" is "the widely replicated finding that novice learners who are given worked examples to study perform better on subsequent tests than learners who are required to solve the equivalent problems themselves" — one meta-analysis put the effect size at 0.52.⁹ A visitor to a new company's homepage is a novice. Show them the worked example. Nielsen said the web version of this in 2002: "Don't just describe what lies beneath the homepage. Specifics beat abstractions."¹⁰

What I'd spent months calling "use images" was one step short. Everyone knows a website should communicate the value to the customer in the customer's language — what's in it for me. I'd learned you don't want too many words on there, because they don't get read, and that you want to communicate with images. But the next step was demonstrate, don't tell. It saves so much prose. People think in terms of screens and tick boxes and checklists and text messages. As soon as you put one on the page, it's "oh right, yeah, yeah, yeah."

Don't make the reader construct an imaginary product from your description. Let them see a useful moment of it happening.

Demonstrate is one member of a family

"Demonstrate" was the move that fixed the hero. But being visual over text is a complex thing, and demonstrating is probably just one part of it. The governance page on one of our agent-built sites was just text, text, text, text, text — until the agent drew it as a responsibility diagram, RACI-style, and it instantly became something you could read. That's a different move: not "show it happening" but "show how the parts connect".

The useful way to organise the family is by the work each move saves the reader — the question they'd otherwise have to answer by reconstruction:

Treat those as candidate nudges to test, not a checklist to impose on every page. The question behind all seven is the same: where are we making the reader do unnecessary interpretive work, and what representation would remove it?

Give me something to react to

Everything so far has been about the AI talking to the human. The same mechanism works on the way back, and it's the half most systems ignore.

I built an interface with a dynamic visual canvas that the AI and I both operate on. When it shows me an image I don't like, I click no, and it asks me why — but not with an empty text box. It offers five or six reasons, pre-generated by the AI for that particular image. And often the reason I didn't like it is sitting right there. It increases the bandwidth.

An open "why don't you like it?" is a recall task: it asks you to generate an explanation from nothing. The menu turns it into recognition. NN/g makes the same point about search suggestions, which "partly transform the query-generation task from one of recall to one of recognition."⁵

But something slightly more is going on. The person may not have a fully formed explanation waiting to be recalled. They may only have a reaction. The AI supplies candidate interpretations of that reaction, and the person recognises, combines or corrects them. I'd call that assisted articulation: the machine helping a human say something they'd otherwise struggle to express. Research on critiquing-based recommenders found the same benefit — when users were offered system-suggested critiques they "more frequently picked suggested critiques" and "significantly saved their task time and interaction effort."¹²

That same research is the reason the escape hatch is non-negotiable. The best suggestion accuracy it reports was 66.9%, and "in the failure situations, because users have no chance to build critiques on their own, they would have to take more effort."¹² Suggested reasons should help people find their meaning, not quietly replace it with the model's framing. Allow several reasons, none of them, "not sure", and the person's own words. And treat one rejection as evidence about this moment, not a permanent preference.

The deeper change is that the output stops being a message and becomes an object both sides can point at. A diagram is no longer the illustration accompanying the answer; it's the thing the conversation is about. "That part's right." "Not that relationship." "Keep this, but change those two things." Each of those is a sentence you can only say about something visible.

Gergle, Kraut and Fussell measured the value of a shared visual object in human pairs: with an immediate shared view of the work, pairs "were approximately 30% faster," and people could say "the one on the left" instead of a long description. A three-second delay in updating the view left them "only 7% faster" than having no view at all.¹³ That was a physical puzzle, not an AI canvas, so it supports the mechanism rather than my interface. But it explains why my canvas runs on a fast-slow split: the fast agent keeps the exchange moving while the slow one does the digging, so the shared object stays live. And it's why the rule is to keep a shared object available long enough to inspect, challenge and change it.

One more thing the canvas taught me. I'm not "a reader" or "a skimmer". Some days I want the glance, some days I want to inspect the evidence, and some days I want the twenty-minute immersion. Design for different depths at different moments — not for a permanent classification of the person.

Keep the depth, change the doorway

Which brings me back to Chris's to-do lists.

Instead of summarising our meetings with text, I summarised them with images. Every major subject got a new whiteboard-style image. Under each one, I linked the original audio you can click on, and I pulled out a few exact quotes. No big walls of text to read.

And here's the funny part. We'll have a discussion about a bunch of stuff — we've both put a bit into it — and then it produces one image, and the image is like: oh yeah, that's what we were talking about. It's freaky accurate. It might have been an hour's discussion, and it puts up one whiteboard, and it's "oh yeah."

The tempting explanation is that the picture compressed the hour. I don't think that's what happened. We already had the hour. We'd supplied the examples, the objections and the changes of direction. What the image gave us was a shape we could recognise, and the recognition brought the rest back into reach. It's the same mechanism as The Recognition Loop — hand the rememberer a small cue and let their own memory do the remembering — working at the scale of a team.

That matters, because it tells you what the image can and can't do:

The same image can succeed brilliantly at the first job and need help at the second. The picture can be a key to the conversation without being a replacement for it. Which is exactly why the depth has to stay reachable.

Here's the precise version of my complaint about summaries. Compression itself isn't the enemy — a whiteboard is selective too. The problem is losing the route back, or letting the compressed view become the only surviving account. Summarise the transcript, then summarise the summary, then extract the to-dos, and each hop compresses along whatever the previous hop kept. I've written about that topology in Your Company Speaks Five Languages: serial re-encoding kills the useful shape early, and the fix is to generate each view directly from the preserved source, so nobody is more than one hop from the truth. The meeting index does that across media rather than audiences: the image, the quotes and the audio each sit one hop from the recording.

The strongest external evidence I've found points the same way. In Microsoft's study of an LLM-powered meeting-recap system, "all participants used the ability to expand the 'context' of a summary into the original dialog," and "many participants also requested deep links to video recordings to review the discussion quickly."¹⁴ It was a small qualitative study — seven participants — but it's telling what they reached for: the route back. The same paper notes earlier work where people who skimmed transcripts ended up "missing the high-level picture of meetings while being overconfident in their recall."¹⁴ Nielsen named the general pattern decades ago as progressive disclosure: "Initially, show users only a few of the most important options. Offer a larger set of specialized options upon request."¹⁵

Two practical consequences. First, to-dos are a different product. An extracted task list isn't yet an agreed commitment, which is why nobody follows it. If work was actually accepted, give it an owner and a completion condition in a separate commitment view — and stop pretending the rest of the meeting was packaging around the tasks. Second, Chris photographs our real whiteboards and I haven't been ingesting them. I should. Not because they're prettier than the generated ones — the generated ones are much cleaner — but because the originals may hold crossings-out and groupings that never made it into the transcript. Keep the photographed board as source; keep the clean board as an interpretation people can check. That's Keep the Bronze, applied to a whiteboard.

One nudge beats a page of rules

Now the machine side, because this is where builders are quietly making things worse.

The website trial happened inside our minimum viable companies — MVCs, completely agent-built companies that start from an idea and then work out their own marketing, build their own websites and so on. (I've defined the term properly in The Three Parts: a small company-shaped model that makes an offer and its work inspectable.) The websites were coming out boring. They looked like someone doing an introductory HTML course. Not quite that bad, but close.

So I set up a loop. I had Claude Code try different ways to improve them — extract what made some good sites good, vary the prompting, vary the models, vary the harnesses — against a static judge scoring how good the sites looked, how interesting they were and how well they communicated. I went away for a couple of hours. I came back and the most amazing-looking website had come out. I couldn't believe it. I told it: yep, that's your gold standard now. (How you turn a run like that into something repeatable, rather than a lucky afternoon, is its own discipline — I've written it up as The Exemplar Ratchet. Here I only care about what it taught us about communication.)

Holding the judge static, here's what enough testing showed. Prompting was the most important thing. The model was next. We could send Opus a pretty vague prompt — it had to be reasonable — and it would still produce the amazing sites; the very first spectacular one came from just chucking the job at Opus 5.5. And the harnesses almost didn't make a difference, including our own hand-built one in Python.

But "prompting was the most important thing" doesn't mean "more prompting". We experimented with more and less prescription, and the over-prescriptive sites came out bad. What worked was less prescription plus that one nudge: demonstrate over tell.

Four words about the kind of move beat a page of instructions about the layout.

Why would that be? Because "demonstrate over tell" changes the kind of solution being sought, while "rounded card, image on the right, these colours, these sections" specifies an implementation before the model has found the communication idea. Prompt quality isn't prompt quantity. The model builders are saying the same thing in their own guidance. OpenAI: "a single sentence firmly and unequivocally clarifying your desired behavior is almost always sufficient to steer the model on course."¹⁶ Anthropic: "Prefer general instructions over prescriptive steps."¹⁷ And on frontend design specifically, Anthropic warns that "without guidance, models can default to generic patterns" while recommending prompting "at the right altitude, avoiding the two extremes of low-altitude hardcoded logic like specifying exact hex codes and vague high-altitude guidance."¹⁸ "Demonstrate over tell" sits at exactly that altitude. It names the move, not the pixels. It's the same instinct as The North Star Prompt — tight intent, loose method — pointed at communication.

None of that research tested website communication. I found no controlled study showing over-specified prompts lower design quality; the evidence is practitioner guidance plus trials like ours. But one independent report came close: Prithvi Rajasekaran at Anthropic, building a design harness, found that "the wording of the criteria steered the generator," and that a phrase like "the best designs are museum quality" "pushed designs toward a particular visual convergence."¹⁹ A few words, every output moved. That's the power of the nudge — and, as we'll see, its risk.

Aim, eyes, canvas

The harness result has an important boundary, and it's the most useful thing in the whole trial for anyone building agents. The harnesses only stopped mattering once they could all do two things. Our internal harness couldn't screenshot the web pages to review them. Once we fixed that, it was equal to the others. And Claude had done some clever image work so the hero wasn't 16:9 but 2.4:1, so we had to build that composition tooling in too.

Screenshots improved what the agent could inspect; composition tooling improved what it could express. Anthropic reports the same about eyes in long-running agents: giving Claude browser-testing tools "dramatically improved performance, as the agent was able to identify and fix bugs that weren't obvious from the code alone."²⁰ An agent that can't see its page is painting blind. Once aim, eyes and canvas are in place, the harness is mostly out of the way and the model's own design judgement shows through. That's a more useful finding than either "the harness is everything" or "the harness doesn't matter".

Test understanding, not applause

How do you know any of this worked? Not by whether people click, nod or say they like it.

That sounds obvious until you see how easily the two come apart. A 2026 study of 204 people compared text and graph-shaped explanations of AI reasoning. Graph rationales "do not help uniformly," and — the line I'd put on the wall — "in each modality, the format that better supports calibrated decisions is not the one users prefer."²¹ People liked one format and decided better with the other. Our fixed AI judge was a fine instrument for comparing sites against each other. It isn't evidence that customers understood them.

So add a test of understanding. The simplest is the cold-arrival reader: someone — or a fresh AI context — with no authoring context, who spends about twenty seconds with the page and then answers two questions: What does this company do for you? and What would you do next? If they can't answer, that's evidence about a reader, not a matter of taste. A fresh AI context is a cheap screen for confusion; it isn't proof that real customers will respond the same way.

Run it with people who were in the meeting and people who weren't. Compare the wall of text, the structured page and the source-linked visual on the same material. And hold one standard above the rest: faster confident misunderstanding is a failure, even when the interface feels excellent.

What to do this week

• Pick one recurring AI output your people don't read — the meeting summary, the weekly status, the agent's analysis — and ask of each section: what is the reader having to reconstruct here?
• Rebuild it around a doorway. One recognisable object per subject — a drawn relationship, a before-and-after, a demonstrated moment, options side by side — with exact quotes and a link to the source. Delete nothing underneath.
• Separate commitments from knowledge. Accepted work gets an owner and a done-condition in its own view; the rest of the meeting stays navigable.
• Add one nudge to your agents — "demonstrate over tell", or whichever move from the table your readers most need — and remove the layout rules it replaces.
• Give your agents eyes. If they produce anything visual, they should screenshot it and look before they hand it over.
• Offer reasons, keep the hatch. Wherever people reject AI output, give them candidate reasons to pick from, plus "none of these", "not sure" and their own words.
• Run the cold-arrival test on the before and after. Two questions, twenty seconds.

The same move, everywhere

A website is a communicator. So is a meeting summary, a status report, an agent's answer, a board paper. In every one of them, the AI has the thing and the human gets a description of the thing — unless someone decides otherwise. The whiteboard makes the idea's relationships visible. The demonstrated moment makes the service experience visible. The shared canvas makes the current understanding visible, and correctable.

None of that means writing less of substance. The depth stays. The recording, the transcript, the full analysis, the twenty-minute audio — all of it is still there for the moment someone wants it. What changes is what they meet first, and whether they can find their way back.

Don't merely reduce the number of words. Reduce the work required to understand — and make it easier to show where the understanding is wrong.

Scott Farrell builds AI-native systems and advises Australian leadership teams on turning AI output into decisions at LeverageAI. scott@leverageai.com.au · leverageai.com.au