Post
Agents Explain Better in HTML
Markdown is still great for notes. But when an AI agent needs to explain a messy thing, a tiny HTML page can beat another wall of bullets.
So maybe the problem is not Markdown.
Maybe the problem is that we ask for Markdown by reflex.
The latest nudge came from Thariq Shihipar, who works on Claude Code at Anthropic. His argument is simple: when you ask an agent to explain something complicated, stop defaulting to Markdown every time. Ask for a self-contained HTML artifact instead.
Simon Willison picked up the idea on Friday and immediately had the same reaction a lot of us had: wait, why am I still asking for everything as a linear document?
I get it. Markdown is the house mug of technical writing. Cheap, sturdy, always within reach. But sometimes you are not trying to drink coffee. Sometimes you are trying to lay a messy circuit board on the table and point at the burned part.
That is where HTML gets interesting for agents.
Markdown is a hallway
Markdown is wonderful when the shape of the answer is mostly words:
- a summary
- a checklist
- a changelog
- a short explanation
- a post like this one
It is less wonderful when the shape of the answer is spatial.
A pull request is spatial. There is a diff, then a note beside the diff, then a severity label, then a jump link to the file that matters.
A system architecture is spatial. Boxes, arrows, hot paths, boring paths, scary paths.
A design review is spatial. Swatches, component states, spacing, typography, the thing you need to see next to the other thing.
Markdown can describe all of that, but it tends to turn the room into a hallway. Everything becomes a vertical stack. You scroll, remember, scroll, compare, forget, scroll back.
HTML lets the agent put the table back on the table.
The browser is the agent's sketchbook
Thariq's example gallery is the useful part. It has little single-file HTML outputs for code review, implementation planning, design systems, incident timelines, feature flag editors, slide decks, and concept explainers.
None of this is magic. That is the point.
An agent can already write:
- a
<table>with sortable columns - a small diagram with inline SVG
- collapsible sections for noisy details
- tabs for alternate code paths
- a slider for a parameter
- a copy button for the final result
The difference is that those primitives change what you can ask for.
"Explain this PR" becomes "show me the risky files, annotate the diff, color the findings, and make the module map visible."
"Summarize this incident" becomes "build me a timeline where I can expand the log lines."
"Help me choose a design direction" becomes "render three directions side by side so I can react with my eyes, not my imagination."
That is not a replacement for writing. It is a replacement for pretending every thinking task wants to be a memo.
The funny part
We spent years making the web app feel more like a document editor.
Now the agents are reminding us that a document can feel more like a tiny web app.
There is a very 2026 loop here. We ask the model for prose because prose is easy to paste into chat. The model is capable of building a little interface, but we do not ask for one because the chat box makes us think in paragraphs. Then someone says "try HTML" and the whole room remembers that the browser has had layout, color, interaction, and links for decades.
The future arrived, looked around, and asked for index.html.
When to ask for HTML
My new rule is pretty simple:
| If the output needs... | Ask for... |
|---|---|
| reading in order | Markdown |
| comparing choices | HTML |
| inspecting code | HTML |
| sharing plain notes | Markdown |
| explaining a moving part | HTML |
| saving durable docs | Markdown first, HTML if useful |
There is one important caveat: HTML artifacts are still generated code. If the page includes JavaScript, treat it like any other script. Do not paste secrets into it. Do not run random artifacts from strangers. Do not confuse "looks like a document" with "cannot execute anything."
But for your own agent, in your own workspace, on a boring explanation task? This is low-friction and weirdly delightful.
Next time you are about to ask for "a detailed explanation in Markdown," try this instead:
Explain this as a self-contained HTML page. Use layout, tables, diagrams, color, and small interactions where they make the idea easier to inspect. Keep it readable without external assets.
Worst case, you get a slightly overstyled note.
Best case, you remember that the web was an interactive medium before chat convinced us everything had to be a scrollback.
Happy Sunday. Go make a tiny page.
Sources
- Simon Willison — Using Claude Code: The Unreasonable Effectiveness of HTML — the link post that surfaced Thariq Shihipar's argument and Simon's own GPT-5.5 HTML experiment
- The unreasonable effectiveness of HTML — examples — Thariq Shihipar's companion gallery of single-file HTML agent outputs
- Anthropic Help Center — What are artifacts and how do I use them? — official context on Claude artifacts, including single-page HTML outputs
- Claude Code overview — official docs for Anthropic's coding agent