Builders spending 20 hours a week inside Claude Code are generating mountains of tokens. Only about 1% of those tokens end up as production code, according to Anthropic engineer Thariq Shihipar on the How I AI podcast (Lenny's Podcast Network, May 2026). The other 99% are plans, context, throwaway tools, and thinking. The smartest teams have stopped wasting that 99% on plain Markdown. They render it as rich, interactive HTML instead.
This is not a formatting preference. It is an operating model. When tokens are cheap and context windows hold a million tokens, the right move is to make AI output you can click, scroll, and inspect. Plans you walk through. Design systems you preview live. Micro-apps you use once and throw away. The shift changes what it means to be an engineer in 2026.
Why Is an Anthropic Engineer Replacing Markdown with HTML?
Markdown became the default AI output during the GPT-4 era. Context windows were tiny. Every token mattered. You asked for bullet points and got bullet points.
That era is over. With million-token context windows in models like Opus 4.7 and Sonnet 4.6, HTML offers something Markdown cannot: interactive elements, visual mockups, scrollable sections, embedded code previews, and far higher information density per screen.
Thariq Shihipar, an engineer on the Claude Code team, published 20 self-contained HTML examples at thariqs.github.io/html-effectiveness. His companion essay, "The Unreasonable Effectiveness of HTML," hit the top of Hacker News in May 2026. The examples show project plans with collapsible sections, color-coded status boards, and live component previews. All in a single file you open in a browser.
The core argument is simple. AI output should be something you engage with, not something you skim. A side-by-side screenshot of the same project plan in Markdown versus interactive HTML makes the gap obvious. The Markdown version is a wall of text. The HTML version is a tool.
What Does a Claude Code HTML Workflow Actually Look Like?
The prompt pattern is shorter than you expect. Thariq's go-to prompt in Claude Code looks roughly like this:
"Create an HTML file with a plan. Help me visualize. Include excerpts, mockups, code, whatever is needed to give me maximum context."
That phrase, "whatever is needed," matters. It grants creative freedom instead of boxing the model into a rigid format. Over-constraining with elaborate system prompts often produces worse results than a clear, open ask. This connects to a broader pattern. Reducing hallucinations with context files works the same way: give the model the right boundaries, then let it fill the space.
Three use cases show up repeatedly in Thariq's public examples:
Living design systems. One HTML file holds your colors, typography, spacing, and components. You pass it as context across Claude Code sessions. No Figma link. No GitHub repo to clone. Just one file that renders in any browser.
Disposable micro-interfaces. Need to edit a data table? Ask for a gamified UI with drag-and-drop rows. Use it once. Delete it. The cost is near zero.
Weekly status updates. HTML reports sent to managers get read. Markdown reports get skimmed. The difference in engagement is real.
What Does "1% of Tokens Are Code" Mean for Engineers?
As of May 2026, Claude Code has crossed 4.2 million weekly active developer users. The average developer spends 20 hours per week with the tool. That is a lot of tokens. The 1% stat forces a question: what is the other 99% doing?
It funds dashboards. Custom interfaces. Status updates. Understanding tools. Planning artifacts. All the thinking that happens before you commit a single line. The engineer's job shifts from writing code to allocating compute. You are deciding how to spend roughly $500 in compute per extended session, and the returns depend on where you point those tokens.
This is not theory. It is a budget problem. When you treat tokens as a resource to allocate, you stop asking "write me a function" and start asking "help me understand this codebase well enough to know which function to write." The HTML workflow fits here because rich, visual output is a better thinking tool than flat text.
Success in this model depends on three things. First, deciding what is worth building at all. Second, defining the boundaries of what the model knows and does not know. Third, staying in sync with the agent during planning, not just reviewing output after the fact. This maps directly to how daily Claude Code workflows already work for experienced developers.
How Does This Change Testing and Documentation?
When most tokens go toward thinking and planning, the old testing and documentation playbooks need an update.
Traditional unit tests still matter. But Thariq describes a shift toward verification rubrics and managed agents that evaluate outcomes rather than line-by-line test coverage. You define what "correct" looks like in plain language. The agent checks its own work against that rubric. This is closer to how a senior engineer reviews a pull request than how a CI pipeline runs.
Documentation changes too. Claude can record its own actions. It can produce annotated walkthroughs. It can generate HTML docs with live code samples embedded. When the cost of making documentation approaches zero, the bottleneck is no longer "who has time to write docs." The bottleneck is "who has good ideas worth documenting."
Centralized, templated documentation matters less in this world. A bespoke HTML document made for one project, one audience, one moment is often more useful than a standardized wiki page. The quality of the idea matters more than the format. This connects to how MCP links AI to your tools. When context flows freely between systems, rigid templates become overhead.
How to Start Using HTML Outputs in Your Own AI Workflow
You do not need to overhaul your process. Start with one change and expand from there.
Step 1: Replace your next project plan with HTML. Before writing any code, ask Claude Code to generate an interactive HTML plan. Use the prompt pattern above. Open the file in your browser. Click through it. You will notice gaps in your thinking that a Markdown outline would have hidden.
Step 2: Build a living design system file. Ask Claude Code to generate a single HTML file with your project's colors, fonts, spacing, and key components rendered live. Save it. Pass it as context in future sessions. This gives the model visual grounding without linking to external tools. If you are building for multiple clients, one design system file per client keeps things clean.
Step 3: Use "whatever is needed" instead of elaborate prompts. The instinct is to write long system prompts specifying every detail. Resist it. A clear goal with open-ended format permission often produces richer output. The model will choose tables, charts, interactive toggles, or embedded code based on what the content needs.
Step 4: Treat every HTML artifact as disposable. The value is in the thinking the file helped you do, not in the file itself. Delete it after use. Make another one tomorrow. When creation cost is near zero, hoarding artifacts is waste.
Note: The examples referenced in this post are sourced from Thariq Shihipar's public artifacts and the How I AI podcast episode. A GenAI Club team member replication with documented prompts and time-spent data would strengthen these recommendations. That test has not been completed yet.
Where Does This Fit in the Bigger Picture?
The HTML workflow is one piece of a larger shift. AI app builders in 2026 are all moving toward richer, more visual output. AI automation workflows benefit from the same principle: the more context you give a system, the better it performs. HTML is just a better container for context than Markdown.
The 1% stat is the thing to remember. If only 1% of your AI tokens become production code, you should care deeply about what the other 99% produce. Flat text is a waste of that budget. Rich, interactive, visual output is not. The engineers who figure this out first will move faster, think more clearly, and build better products.
For more on how builders are using AI tools in production, explore the community at genai.club or join us at the GenAI Summit Asia to see these workflows live.
FAQ
Why would I use HTML instead of Markdown with Claude Code?
HTML lets Claude Code produce interactive elements, visual mockups, embedded code samples, and scrollable sections that you can engage with in a browser. Markdown is flat text. With context windows now exceeding a million tokens, the extra richness of HTML helps you actually understand complex plans and specs instead of skimming them. Anthropic engineer Thariq Shihipar argues this is especially valuable for project plans, design systems, and code reviews where information density matters.
What does it mean that only 1% of Claude Code tokens become production code?
It means the vast majority of what an AI coding agent generates is not final code. It is plans, dashboards, throwaway interfaces, status updates, and exploration. This reframes the engineer's role: instead of writing code, you are allocating compute toward the thinking and visualization that leads to better code. The 1% that ships is higher quality because the other 99% helped you understand the problem.
What is a living HTML design system in Claude Code?
Instead of maintaining a Figma file or a Markdown style guide, you create a single HTML file that contains your entire design system: color swatches, typography scales, spacing tokens, and component previews. You pass this file as context to Claude Code across projects. Because it is both human-readable (open it in a browser) and machine-readable (Claude can parse the HTML), it transfers design knowledge without any extra tooling.
What prompt should I use to get HTML output from Claude Code?
Thariq Shihipar's recommended pattern is simple: 'Create an HTML file with a plan. Help me visualize. Include excerpts, mockups, code, whatever is needed to give me maximum context.' The key phrase is 'whatever is needed,' which grants the model creative freedom. Over-constraining with elaborate system prompts tends to produce worse results. Start broad and refine from there.
Do I need to know HTML to use this workflow?
No. The entire point is that Claude Code writes the HTML for you. You describe what you want in plain language, and Claude generates a self-contained HTML file you open in any browser. You never edit the HTML directly. If you want changes, you describe them in your next prompt. The file is disposable. The value is in the thinking it represents, not the markup.