The workaround wants to be a philosophy
Asking Claude Code for HTML is a workaround for a layer the product doesn't have yet. "HTML is the new markdown" turns the workaround into a philosophy, and then nobody asks for the layer.
Thariq Shihipar from the Claude Code team wrote an essay on why he now has Claude write HTML instead of markdown. It comes with a gallery of twenty examples: a plan, an annotated PR diff, a module map, a design system, a status report. Most of them are good. A design system should show its colors, not describe them. A diff is easier to read with the notes next to it. He finds it hard to read a markdown file longer than a hundred lines, and anyone who has scrolled through a terminal knows the feeling.
Seven minutes after the essay, he posted this:
HTML is the new markdown.
I've stopped writing markdown files for almost everything and switched to using Claude Code to generate HTML for me. This is why.
Ten days later it was the title of a podcast episode. The essay is careful, but the line that traveled is the slogan, and the slogan claims a lot more than the essay does.
Where the product stopped trying
You ask for HTML, open it in the browser, and for the next ten minutes the browser is the Claude Code UI. It works. It’s also a workaround: the cognitive load grew bigger than the surface it’s delivered on, and you went around it.
A workaround tells you where the product stopped trying. At the end of the essay Thariq gives his real reason: he had stopped reading plans in depth, and was afraid he would have to just let Claude make its choices. In a reply that night he put it shorter: “people were just not reading the markdown files.” People stop reading a hundred-line plan in a terminal because the terminal is the wrong place to show one. When the product has no better place, the medium shaped the reader into someone who approves without reading.
The slogan keeps the fix and drops the problem it was fixing. It drops the costs too. The essay on X ends with an FAQ where he says HTML diffs are “noisy and hard to review”, calls version control “one of the biggest downsides”, and says HTML takes 2-4x longer to generate. The copy on the Claude Blog, dated May 20, says the extra cost is “not really noticeable” and, as it reads today, has no version control question at all. Nobody lied anywhere.. the short version is just the one that may go viral. A workaround admits something is missing, and only people missing the same thing get it. A philosophy hides the lack, so it fits anyone.
When a user works around a lack, it’s a complaint. Thariq builds the product, and he writes that more and more of the Claude Code team works this way. Conway’s law says a system ends up copying how the team that designs it communicates. I’d bet a looser version holds for habits: a product drifts toward how its own team uses it. When the people who build the product work around its lack and promote that as a philosophy, the complaint starts to look like the design, and everyone else’s workflow inherits the lack before anyone even pauses to ask.
Markdown already answered this
John Gruber wrote the split down when he made Markdown in 2004: “HTML is a publishing format; Markdown is a writing format.” You write the markdown, a converter makes the HTML. One is the file you edit and diff, the other is the file you read.
Thariq’s best argument goes right at this. He mostly doesn’t edit these files anymore. He asks Claude to, which “removes one of markdown’s largest benefits.” He’s right that the writing moved to the model, and he even agrees markdown still fits where people write: Obsidian, he told kepano, is “a tool for humans to write”. But the human didn’t leave. Their job changed from writing to review. When Claude writes the file, you check what it changed, and his own FAQ calls that one of HTML’s biggest downsides. For a team, a file that’s hard to diff is hard to trust, and a file nobody trusts either gets thrown away or becomes dangerous.
Agent work needs Gruber’s split, plus a little more. Agents make working objects: plans, specs, reviews, graphs, prototypes, reports. Each one needs what you keep (source, state), what you look at (view, interaction), and what happens over time (review, export). HTML is great at the middle pair, and the slogan stretches it over all three. The other two are the boring ones, which is why teams can’t live without them and why they never go viral. Thariq’s problem is in the boring part: review.
What the polish hides
Tabs, cards and color-coded severity make a plan look organized whether or not the thinking was. A box with an arrow to another box looks reasonable whatever is written in the boxes. Sometimes the thinking was organized and sometimes it was only styled, and HTML makes that harder to tell. Markdown is no better at catching a weak plan, but at least it doesn’t dress one up.
And polish doesn’t fix the problem he started with. He switched because he was approving plans he had stopped reading closely. A polished plan makes approving feel like reading. His own worst case, from a reply, is a report or deck that “expands on your thought too much, adds a lot of AI writing”, and HTML is very good at making that kind of report look finished. You still approve without reading. It just looks like you read.
Pave the cowpaths
The best case for the other side comes from HTML itself. The W3C’s HTML Design Principles from 2007 has one called “Pave the Cowpaths”: when authors already do something widely, adopt it instead of banning it or inventing something new. A lot of the web got built that way, and it was mostly right.
Paving is right when the path goes where people need to go. This one goes to what you look at. Pave it, and the browser becomes the official place agent output gets delivered, while what you keep and what happens over time get a little further away. The mistake is taking the first fix that worked and calling it the design.
What the workaround is asking for
Thariq’s workaround is a bug report, and a good one. It says the terminal is the wrong place to read a plan, and that people stopped reading. What it asks for is a place for the work to live, with all three parts: source you keep, a view you read, and a review you can trust. Claude Code made the work, so it’s the tool that could give the work that place. HTML is the part you can get today by asking nicely. The slogan says the asking was enough. Once a workaround is a philosophy, nobody files the bug.
October 2026. By early September, Claude Code (2.1.260) had an Artifact tool. It still publishes HTML, but now a page comes with a database behind it and a version history that won’t let you publish over a newer copy. That’s state and a bit of review, added under the view. The product has since gone further than the slogan.