Anthropic’s HTML manifesto : a tax on intelligence disguised as progress

On 8 May 2026, Thariq Shihipar, a product engineer on the Claude Code team at Anthropic, published a manifesto on X that has been circulating ever since across the whole AI-developer nebula: drop markdown, switch to HTML for your specs, your implementation plans, your reports, your write-ups. The full piece is hosted on his GitHub Pages example gallery and defends the thesis with eight arguments, seven use cases and a FAQ session that tries to defuse the obvious objections.

The text is well written. It is clever. And it is, by construction, an act of strategic marketing by Anthropic dressed up as personal experience. It’s this dual nature that’s worth pausing on, because an engineer at a company rarely preaches by chance the practices that maximise consumption of his own product.

What the post gets right: throwaway interactivity

Let’s start by conceding what deserves to be conceded. Shihipar is right on a narrow but real subset.

His most convincing argument concerns what he calls custom editing interfaces: those small, throwaway HTML editors you ask Claude to produce for a specific, bounded purpose. Reprioritising thirty Linear tickets with a four-column drag-and-drop, tuning an animation easing curve via sliders, testing a regex in real time against a set of examples, prototyping a checkout button with knobs to explore several variants. For these uses, the interactivity of HTML isn’t an aesthetic nice-to-have. It’s precisely the core of the value. Attempting this in markdown would be absurd, and the final copy as JSON button that feeds the result back into Claude Code closes the loop cleanly.

Likewise, for purely visual prototypes (designing a component, exploring several onboarding-screen variants in a comparable grid), the richness of HTML produces a deliverable no markdown can approach.

On this perimeter, which one might estimate at between ten and fifteen per cent of a developer’s real-world uses, he is right. That’s exactly what makes the rest more credible to dismantle: a true argument about a narrow subset, extended without caution to everything else.

Token cost waved away

First charge. Shihipar admits verbatim in his FAQ that generating HTML takes two to four times longer than markdown. And that it consumes proportionally more tokens. There’s a sentence that, in any serious enterprise setting, ought to trigger a budget debate and a usage review. Here’s how the author handles it: “with Claude Opus 4.7’s 1M window, the increase in token usage isn’t really noticeable within the context window”.

The sentence, read carefully, is a carefully built fallacy. It shifts the objection (cost) onto unrelated ground (the room available in the context). These are two different variables. The context window measures what Claude can read as input at a given moment. The bill measures what you pay for what Claude writes as output over the year. The first can be generous while the second explodes. That’s precisely the case here: doubling to quadrupling the length of every generated artefact multiplies the billed tokens accordingly, independently of the context available.

The argument only holds in one scenario: when the author doesn’t pay for his tokens. Which is, by construction, the situation of an Anthropic engineer.

The timing makes it sharper still. In April 2026, Anthropic quietly changed the terms of its prompt caching, imposing a multiplier of two on the long-TTL option. That commercial signal is crystal clear: the company needs consumption to climb, not to fall. On this very trend, a recent article I devoted to Understand-Anything shows exactly the opposite direction, that of a technical community optimising tokens by indexing the codebase locally. Two simultaneous movements, one from the vendor, the other from the community, pushing in opposite directions. It’s no accident. It’s the very structure of the market.

Presentational HTML is not semantic HTML

Here’s the angle closest to my heart, and one that, as far as I know, has been developed nowhere in the criticism of the post.

When you defend HTML in general, you’re implicitly defending two very different things. On one side there’s semantic HTML: <article>, <section>, <nav>, <aside> tags, a rigorous hierarchy from <h1> to <h6>, Schema.org microdata, ARIA attributes. It’s that HTML I defended in my article on AI accessibility debt as a bulwark against the unreadability of the modern web for LLMs. Semantic HTML is machine-readable because the structure is declared there, not simulated.

On the other side, there’s presentational HTML: stacks of <div> elements dressed up with Tailwind classes, CSS that simulates structure rather than declaring it, nested SVGs that look like diagrams but don’t parse, inline JavaScript standing in for logic. It’s the HTML you generate fast, that renders nicely, and that is semantically opaque. A human reader sees a clean layout; a machine sees a bag of meaningless tags.

Now, the HTML that Claude produces for those famous rich specs is, in the overwhelming majority of cases, presentational HTML. Look at the examples in Shihipar’s gallery: they’re visually polished artefacts, structured by CSS, with no genuine semantic hierarchy. A big <div class="..."> with an <h2> lost in the middle of a sea of styled divs. The SVG diagrams are drawings, not interpretable graphs.

It’s a dizzying reversal. For ten years, the web industry abandoned semantics for presentation, and it took a decade to realise that search engines, screen readers and now LLMs no longer knew how to read what we were producing. We invented Schema.org, JSON-LD, microdata, to inject meaning back where we had drained it. HTML maximalism as Shihipar defends it makes exactly the same move, but inside a developer’s workflow. We sacrifice the semantics of clean markdown for the presentation of styled HTML, and we call it progress.

Version control sacrificed for artefacts that are supposed to be reviewed

The post addresses versioning in its FAQ, in two sentences: “It’s honestly one of the bigger downsides of HTML, HTML diffs are noisy and hard to review compared to markdown”. And then the author moves on.

That sentence, slipped into a FAQ, is in fact the dealbreaker objection. The entire purpose of a spec, an implementation plan, an incident report, a PR write-up, is to be read, amended, reviewed, archived. All of that goes through a versioning system. If the diff becomes illegible, collaboration collapses. You no longer review the detail of the changes, you review the overall render, which means re-reading the whole document every time rather than its differences. On a team of five people reviewing ten specs a week, the cumulative cost is astronomical.

Sacrificing the reviewability of an artefact whose entire reason to exist is to be reviewed is not a defensible trade-off. It’s a renunciation of the very principle of asynchronous collaboration. The whole Git ecosystem, from pull request reviews to tools like Reviewable and the workflows I detailed on Claude Code hooks, rests on the idea that you can cleanly visualise what changed between two versions. Generated HTML breaks that property.

The obvious workaround would be to generate minimal, normalised HTML, whose diffs would stay readable. But that’s precisely what the post’s examples are not. On the contrary, they’re visually rich artefacts, dense with CSS, that a Claude reflow will make entirely different at the next commit with no substantive change.

The self-fulfilling prophecy: “I no longer read markdown”

In passing, Shihipar drops a sentence that deserves to be framed. “In practice, I’ve found I tend to not actually read more than a 100-line markdown file.” His proposed solution is to wrap these files better in HTML, so they become more appetising to read.

This inversion is worth pausing on. The question isn’t why do I no longer read my specs in markdown?. The question is why are my specs more than a hundred lines long?. And the answer, which isn’t in the post, is well known: because Claude Code, whose system directive favours execution over reflection, produces verbose artefacts by default. When the thinking isn’t condensed, the document grows. When the document grows, no one reads it any more.

The right response to this drift isn’t to wrap the file in a more seductive presentation. It’s to ask for a shorter spec, better thought through, denser. Fifty lines of markdown you actually read are worth more than three hundred lines of HTML you skim. The technical industry has known this rule since Brooks; it doesn’t change because we’ve got a new generation tool.

Wrapping a symptom of a verbose spec in HTML is treating the bandage rather than the wound. And the worst of it is that the bandage costs two to four times more.

The security risk never raised

One gap stands out when you read the post through a security lens: not a word about execution.

A markdown file is an inert object. You open it in a reader, it displays, that’s it. An HTML file, by contrast, is an active object: it potentially contains executable JavaScript, fetches to arbitrary domains, image references that trigger requests, CSS that can leak information via attribute selectors.

And the generation chain carries specific risks. Claude Code reads your source code, your Slack or Linear MCP, your git history, your local files, sometimes your configuration secrets. It then produces an HTML file you’re invited to open in a browser. If a portion of the content read upstream contains an indirect prompt injection, that is, instructions hidden in a ticket, a code comment, an ingested web page, then the agent can, unbeknownst to its user, embed in the generated HTML a silent exfiltration: a fetch call to a domain controlled by the attacker, carrying as a parameter a fragment of session cookie or an extract of local content.

This scenario isn’t theoretical. The family of indirect prompt injection attacks has been extensively documented by Simon Willison and several offensive security teams since 2024. The shift to LLM-generated HTML artefacts, opened in the end user’s browser, opens an attack surface that didn’t exist with read-only rendered markdown files.

That the official post of an Anthropic engineer doesn’t mention this question even once is itself a signal. It’s not that the author is unaware of it: it’s that it’s not within the scope of the message he’s carrying. A product manifesto doesn’t bother with security blind spots.

HTML for Claude-to-human, but who pays for Claude-to-Claude?

One last angle, an architectural one. The post uniformly presents HTML as a Claude-to-human communication format. But many, probably the majority, of the generated specs and plans aren’t read once and thrown away. They’re re-read by another agent at the start of the next session, by another team member through their own Claude Code, by a CI agent validating an implementation, by an analysis script aggregating several reports.

For all these downstream consumptions, HTML is a hostile format. Asking Claude to re-parse styled HTML to extract the semantics from it is imposing on it a de-fogging step that clean markdown spared it. Markdown has a formal grammar, a deterministic parser; presentational HTML is a bag of divs where the logical structure is drowned in the formatting. The re-ingestion cost is mechanically higher.

This logic is exactly the one I set out on MCP as a question of architecture rather than protocol: the right transport format is the one that serves the consumer, not the one that flatters the producer. Optimising for the human eye at the expense of the downstream chain of agents is the wrong trade-off if the document is meant to be re-ingested. And in a mature Claude Code workflow, almost every document is meant to be re-ingested.

The strategic subtext: lock-in by artefact

Let’s gather the pieces. Anthropic has every interest in its users consuming more tokens. Anthropic softened the terms of long prompt caching by imposing a factor of two. Anthropic pushes Claude Design, the frontend-design plugin, rich visual artefacts. Anthropic pushes Skills (whose mechanics I’ve documented elsewhere) that load specialised code on demand. And an engineer on the Claude Code team publishes a manifesto that preaches, across the eight use cases he lists, the output format that is the most expensive and the hardest to port elsewhere.

Let’s read this last point through the lens of lock-in. A markdown file opens in any editor, renders in any browser, converts to PDF, to docx, to a Reveal.js presentation. An HTML file generated with Tailwind, nested SVGs, interactive JavaScript and references to a proprietary design system is de facto tied to the ecosystem that produced it. It only opens cleanly in a recent browser; it can only be modified through Claude Code, because no one is going to fix hundreds of utility classes by hand; it doesn’t port to another tool without costly re-ingestion.

This is precisely the dynamic of replacing standard objects with artefacts generated on demand that I described in my article on Claude Opus 4.6 as a threat to SaaS. Except that here, the object being replaced is even more universal: it’s the text file. Markdown had become the pivot format of a decade of digital productivity, from the README to the RFC by way of Obsidian notes. Generated HTML wants to take that place. And every artefact re-engages the user in the next Claude Code session, because the next modification will necessarily be made via the agent that produced it.

The post says nothing of all this. It’s sincerely written, no doubt. It’s nonetheless, structurally, an instrument of product marketing. It’s the classic trap of high-quality content marketing: an expert publishes a point of view that’s also a sales pitch, and the quality of the text serves to mask the function of the text. This grammar is now ubiquitous in the AI nebula, and I’ve already described elsewhere how the French-speaking bubble picks up Anglo-Saxon manifestos without putting them through the minimal filter of cui bono.

The real decision matrix

Here is the pragmatic grid the post should have produced instead of its blanket enthusiasm.

Use HTML when interactivity is the value: throwaway editors for reprioritising, drag-and-drop, sliders for adjusting parameters, playgrounds with copy as prompt, animation prototypes with parametric exploration. For these uses, HTML isn’t a format, it’s a throwaway software product, and it has no substitute.

Stay in markdown for everything else: versioned specs reviewed as a team, implementation plans amended across sessions, archived reports, PR write-ups, documents read once and then stored, and above all any document meant to be re-ingested by another agent. Markdown diffs, versions, ports, transforms, re-ingests. It doesn’t flatter the eye, but it serves the entire chain.

Never generate HTML with JavaScript execution from an LLM that has read your session secrets, your authenticated MCPs, your local files, without a prior audit. The indirect prompt injection attack surface is too real to be ignored. At a minimum, open these files in an isolated browser, in incognito mode, with no extensions or active session.

And read the manifestos of Anthropic engineers for what they are: well-written strategic signals, whose author’s sincerity changes nothing about the commercial function. That’s no reason to reject them wholesale. It’s a reason to put them through the filter that any product discourse deserves, and that my own AI stack for 2026 applies systematically before adopting a practice.

HTML maximalism is a good idea applied to the wrong perimeter, carried by an employee who doesn’t pay the bill he prescribes. On the ten to fifteen per cent of uses where he’s right, follow the advice. On the remaining eighty-five per cent, keep your markdown, keep your diff clean, keep your bill under control. And bear in mind that the next best practice pushed by Anthropic deserves the same critical reading as this one.