When I wrote last week that HTML was being rediscovered in the context of LLMs, the moment was already real: Thariq Shihipar's first piece had hit the top of Hacker News, Simon Willison had picked it up on his link blog, and the conversation was active inside the labs. Since then it has gotten louder and wider. Thariq's follow-up dropped a sharper title — HTML is the new Markdown — and a gallery of twenty self-contained HTML artifacts to back it. Andrej Karpathy endorsed the pattern: at the end of your query, ask the model to structure its response as HTML, then open the file in a browser. Theo Browne reacted on video, half praise, half pushback.
The arrow is the one the earlier post traced. Token windows used to be scarce, and Markdown won because it fit. Token windows are no longer scarce, and the format that wins is the format that expresses the most. That part of the rediscovery is now uncontroversial. What the new pieces don't reach is the verb that was missing.
The read side is settled
Thariq's argument and Karpathy's recommendation are about output. The model generates HTML, you open it in a browser, you read it. The format is richer than Markdown, so the read experience is better. Tables, diagrams, mockups, collapsible sections, color-coded status, occasional interactivity. The agent renders a better artifact. You consume it.
There are limits to that. Part of why HTML feels better than Markdown right now is novelty: we're saturated with Markdown reports and HTML reports stand out. If every spec, every PR writeup, every status update becomes an HTML page, the novelty thins. The version-control problem doesn't go away — HTML diffs are noisier than Markdown diffs and harder to review. The sharing problem doesn't go away either. Thariq's answer is "upload to S3, share the link," which routes the portability back through a cloud bucket and a URL. None of this invalidates the move. It marks its limit. HTML-as-output is a better output. It's still output. The agent makes; the human reads.
The write side
Tim Berners-Lee's original design had a second verb. The browser was an editor. HTML was the substrate for a read/write medium. The commercial web kept the read side and threw the write side away. Markdown carried the read side adequately for the GPT-4 era. HTML carries it better now. Neither replaces what was lost.
The move I'd add to the picture is one their pieces don't take up: the agent doesn't have to live outside the artifact. It can live inside it.
A single .html file that opens in any browser, contains its own modification surface, and rewrites itself on instruction is not a richer output. It's a different category. The artifact and the editor are the same object. ⌘K modifies the document; ⌘S commits the change back into the file on disk. No application, no install, no account, no server. The thing you email is the thing that edits itself.
This is what reWritable is. The three concerns above shift when you reframe what HTML is being used for.
Novelty. If HTML's appeal is partly that it's not Markdown, it wears off. If the appeal is that the document edits itself, it doesn't — it compounds. The format isn't the feature. The format-plus-agent is.
Sharing. A reWritable container is a file. You attach it to an email. The recipient opens it in a browser. No S3, no link to keep alive, no service to depend on. The portability isn't bolted on; it is the substrate.
Version control. HTML diffs are still noisy in general. A reWritable container, on commit, rewrites a single constant inside an immutable bootstrap — the inline snapshot of the document's state. The rest of the file is byte-identical between commits. Reviewable diffs return, not because HTML got better at diffs, but because the surface for change got smaller and more structured.
A second axis
Karpathy sketched a trajectory: raw text → Markdown → HTML → eventually interactive videos and simulations generated by a diffusion neural net, every pixel streamed live from a model. It's a progression along one axis: how rich the consumable is. Each step lets the model produce a more expressive output. The endpoint is a model-rendered pixel stream.
That trajectory assumes the artifact flows from the model to the viewer in one direction. The document is a render target. Make the rendering richer; make the output more expressive.
There is a second axis, perpendicular to that one, that the same capabilities make available. On this axis what changes isn't how rich the output is. It's whether the agent stays inside the artifact. A static HTML report sits at one end. A reWritable container sits at the other. The agent moves from a tool the user invokes to produce an output, into a process the document carries inside itself.
These axes extend independently. A self-modifying container can contain diffusion-rendered regions; nothing about the second axis precludes Karpathy's endpoint. Only the second axis brings back the write half. The first axis improves the read half.
The next sentence
Thariq closes his piece saying he feels more in the loop than ever. Karpathy says the input/output mind-meld between humans and AIs is still in early days. Both of those are true. Both also treat the artifact as what the agent produces, which is the assumption I'd push on. Commentary on Thariq's gallery has already started calling those HTML files "temporary thinking environments." The word doing the work in that phrase is temporary.
The next sentence in this rediscovery isn't HTML beating Markdown harder. Markdown lost the format argument the moment context windows got cheap; that fight is settled. The next sentence is what happens when the file the model produced contains the model — when ⌘K is a property of the document, not the application around it, and when the document outlives the session it was made in because anyone who opens it can keep editing it.
The format is back. The verb is the part still in flight.
Unlock the Future of Business with AI
Dive into our immersive workshops and equip your team with the tools and knowledge to lead in the AI era.