Builders who still ask Claude Code for Markdown bullet points are leaving the best output on the table. Thariq Shihipar, an Anthropic engineer, showed a better way. His post on HTML output in Claude Code hit 750,000 views and 30,000 bookmarks on X within 48 hours of publishing in May 2026 (reported by Lenny's Newsletter). The core idea is simple: ask Claude Code to generate HTML files instead of Markdown, and your planning artifacts become visual, interactive, and far more useful.
This is not a formatting preference. It is a workflow change. HTML output keeps you engaged during the phase that matters most: deciding what to build. The three workflows below, drawn from Thariq's approach and tested hands-on, show you how to put this into practice today.
Why Is HTML Replacing Markdown in AI Workflows?
Markdown became the default AI output format because early models had tight token budgets. Every token mattered. Brevity won over richness. That constraint is gone. As of May 2026, Claude's 200K-token context window makes the old token-economy argument for Markdown largely irrelevant during planning.
HTML can do things Markdown cannot. SVG diagrams. Interactive widgets. Color-coded diffs. Collapsible sections. In-page navigation. Sortable tables. These are not decorations. They are tools that keep your eyes on the plan instead of skimming past a wall of text.
The insight Thariq landed on: richer visual output keeps humans engaged during planning, which produces better final code. When your brainstorming doc looks like a product page instead of a grocery list, you actually read it. You catch gaps. You push back on bad ideas before a single line of production code gets written. If you are already using Claude Code workflows daily, HTML artifacts are the next step up.
What Are the Three HTML Workflows Thariq Recommends?
Thariq's post outlines three distinct use cases for HTML output. Each one solves a different problem in the build process.
Interactive brainstorming. Instead of asking for a bullet-point list of ideas, you ask Claude Code to generate an HTML file. The file displays each idea with a visual mockup, a short description, and a risk score. You open it in your browser. You scroll through a page that looks like a pitch deck, not a to-do list.
Disposable micro-apps. You have Claude build a temporary, purpose-built UI for one specific decision. Input fields, buttons, toggles, dropdowns. You use it to define complex rules or configure a spec. Then you throw it away. The app was never meant to ship. It was a thinking tool.
Living design systems. You keep a design_system.html file in your repo. It shows color palettes, type scales, spacing tokens, and component examples in one scrollable page. Claude references this file when generating new UI code. Multiple Anthropic engineers have now adopted this HTML-first approach as an internal default for plans, code reviews, and design systems within Claude Code.
How Does the "Compute Allocator" Mindset Work?
The shift to HTML output makes more sense when you change how you think about your role. You are not a typist. You are a compute allocator. Your job is to decide what is worth spending tokens on.
Roughly 1% of generated tokens become production code. The other 99% fund planning, communication, and alignment artifacts. That sounds wasteful until you see the result. The planning layer (HTML specs, micro-apps, design references) is the mechanism that keeps you in the loop. It is where misunderstandings surface. It is where you catch the wrong assumption before it costs you a full rewrite.
This connects directly to reducing AI coding hallucinations with context files. The richer your planning artifacts, the less likely Claude is to drift. An HTML brainstorm with mockups and risk scores gives the model (and you) far more signal than three Markdown bullets.
Complexity must earn its keep, though. If a planning artifact does not improve the final output, skip it. A quick function rename does not need an HTML spec. Save the rich artifacts for decisions that carry real weight.
How Do You Prompt Claude Code for HTML Output?
The key is to be specific about the visual format you want. If you leave it vague, Claude defaults to plain text. Here are prompt templates you can copy and adapt.
For brainstorming:
Brainstorm 8 demo ideas for [your project]. Output them as a single HTML file. Each idea should have a visual mockup (use inline SVG or styled divs), a two-sentence description, a risk score from 1 to 5, and a difficulty estimate. Make it look like a product catalog I can scroll through.
For disposable micro-apps:
Create an editable HTML artifact to help me define the decision rules for [your feature]. Design the ideal interface for this problem. Include input fields, dropdowns, and a live preview of the output. I will use this to finalize the spec, then discard it.
For PR reviews:
Help me review this PR by making an HTML artifact. Render the actual diff with inline margin annotations. Color-code findings by severity: red for bugs, yellow for style, green for nice-to-have. Add a summary table at the top.
For design systems:
Create a design_system.html file for this project. Include the color palette (with hex values and swatches), type scale, spacing tokens, and one example of each major component. Make it a single scrollable page I can open in any browser.
These prompts work because they tell Claude what the output should look like, not just what it should contain. For more on structuring prompts that connect AI to your tools, see our Model Context Protocol guide.
What Does a Living Design System Look Like in Practice?
A design_system.html file is a single, self-contained HTML page. No build step. No dependencies. It lives in your repo root and travels with your codebase across branches and projects.
Open it in a browser and you see everything at once. Color swatches with hex and RGB values. A type scale showing each heading and body size at actual rendered size. Spacing tokens visualized as colored blocks. Component examples (buttons, cards, inputs, alerts) rendered with the actual CSS your project uses.
Any developer on the team can open the file to check consistency before shipping a feature. More importantly, Claude itself can read it. Point Claude at the file before generating new UI code, and it matches your existing styles instead of inventing new ones. This is the same principle behind building a Claude Projects knowledge base: give the model a source of truth and it stays on track.
The file also doubles as documentation. New team members open it on day one and see exactly what the design language looks like. No Figma access needed. No design handoff meeting. Just a URL in the browser.
When Should You Still Use Markdown?
HTML is not always the right call. Markdown still wins in specific situations, and knowing when to use each format is part of good workflow design.
README files and Git-rendered docs. GitHub, GitLab, and most code hosts strip or sandbox raw HTML. Your README should stay in Markdown so it renders cleanly in the repo view.
Quick one-off answers. If you ask Claude a factual question or need a short code snippet, HTML adds friction with no value. A plain-text response gets you moving faster.
System prompts and tool descriptions. These contexts still have meaningful token constraints. Brevity matters here. A 200-word system prompt in clean Markdown beats a 2,000-token HTML block that says the same thing. The same applies to MCP tool descriptions where every token counts.
CI logs and machine-readable output. Anything that feeds into another tool or pipeline should stay in plain text or structured formats like JSON. HTML is for human eyes.
The rule of thumb: if a human needs to look at it and make a decision, HTML. If a machine parses it or it lives inside a platform that strips formatting, Markdown. When you compare AI app builders and their output formats, you see the same pattern. The tools that produce richer planning artifacts tend to need fewer rework cycles.
How Do You Get Started Today?
Pick one workflow and try it this week. The brainstorming prompt is the fastest way to feel the difference. Run the same prompt twice: once asking for Markdown bullets, once asking for an HTML artifact. Open both results. Notice which one you actually read all the way through.
If the HTML version makes you catch something the Markdown version missed, you have your answer. Scale up from there. Add a design_system.html to your next project. Build a disposable micro-app the next time you face a complex configuration decision.
The developer who spends 99% of tokens on alignment and planning, then lets the last 1% become production code, ships fewer bugs and rewrites less. That is the real workflow shift behind Thariq's post. Not "HTML is prettier than Markdown." But "rich planning artifacts keep humans engaged at the moment their judgment matters most."
For more on building effective AI workflows, join us at genai.club or check out the GenAI Summit Asia to connect with builders putting these patterns into production.
FAQ
How do I make Claude Code output HTML instead of Markdown?
Include the output format in your prompt. For example: 'Generate an HTML file that displays eight feature ideas with mockups, risk scores, and descriptions.' Claude defaults to Markdown when you ask for a list or summary, so specifying 'HTML file' or 'HTML artifact' steers the output. You can also add visual details you want (color coding, tables, toggles) to ensure Claude uses HTML's full capabilities rather than falling back to plain text wrapped in HTML tags.
What is a disposable micro-app in Claude Code?
A disposable micro-app is a temporary, purpose-built HTML interface that Claude generates to help you edit a specific part of a project spec or plan. For example, you might ask Claude to build a small UI with input fields and buttons for defining decision rules in a feature. You use it once to make your choices, feed the results back to Claude, then discard the file. It replaces long back-and-forth text conversations with a visual editing surface designed for exactly one task.
What does 'compute allocator' mean in AI-assisted development?
The term comes from Anthropic engineer Thariq Shihipar. It describes the developer's shifting role: instead of writing code line by line, you decide where to spend AI compute. Roughly 1% of generated tokens become production code. The other 99% go toward planning artifacts, interactive specs, and design references that align the AI with your intent. The insight is that these planning tokens are not waste. They are the mechanism that ensures the small slice of production code is correct and well-directed.
Should I stop using Markdown with Claude entirely?
No. Markdown is still the right choice for README files rendered by GitHub, quick one-off answers, system prompts, and any context where token count matters or HTML rendering is unavailable. The HTML workflow shines specifically in planning, brainstorming, spec editing, and design system documentation, where visual richness keeps humans engaged and improves decision quality. Use HTML when the output will be opened in a browser; use Markdown when it will be read inline in a terminal or Git platform.
What is a living design system HTML file and how do I create one?
A living design system is a single design_system.html file stored in your repository root. It renders your project's color palette, typography scale, spacing tokens, and component examples in one scrollable page. To create one, prompt Claude Code: 'Create a design_system.html file that documents our current color palette, type scale, and key UI components with visual examples.' The file travels with your codebase, and you can point Claude at it before generating new UI code so it stays consistent with your existing design decisions.