The HTML vs Markdown War Is Over. Here's the Decision Tree Both Sides Needed.
Last week, the engineering lead for Claude Code told developers to stop outputting Markdown. The internet lost its mind.
Thariq Shihipar, who leads engineering on Anthropic's Claude Code, published "The Unreasonable Effectiveness of HTML" with 20 working examples. His argument: Markdown is a relic of the token-scarcity era. HTML gives you interactive navigation, collapsible sections, embedded visualizations, and shareable links.
The post hit 4.4 million views in 16 hours.
The response was immediate and tribal. Two camps formed overnight.
Team HTML said Markdown is dead. They pointed to Thariq's examples: code reviews with color-coded severity, stakeholder reports with collapsible sections, design systems with live swatches. "A Markdown file you scroll past is a file that doesn't exist."
Team Markdown fired back. Security risks from AI-generated JavaScript. Noisy diffs that break code review. Token overhead that bleeds your API budget. "HTML chases visual gloss at the expense of source readability, security, and reviewability."
Both sides are wrong. Not about everything. About what matters.
Team HTML got the direction right but ignored the costs. They hand-waved the 3-5x token overhead, skipped the security implications of AI-generated JavaScript, and never mentioned that Anthropic profits directly from the switch (more tokens = more revenue).
Team Markdown got the risks right but is solving a problem that expired. They're optimizing for token budgets that made sense when GPT-4 had an 8,000-token context window. Context windows are 1 million tokens now. The constraint is gone. The habit isn't.
The real question was never HTML vs Markdown. It's simpler than that: who reads the output, and what do they do with it?