Transcription
Markdown is dying, and the people killing it built Claude code. Derrick works on Claude code at Anthropic. Last week, he dropped a thesis that broke the dev internet. 750,000 views, 2.7 thousand likes, 340 reposts, and the replies are split.
But again and again, you see the same line. "Wait." You stop too. He claims Markdown is the wrong format for every spec, every plan, every PR write-up you hand to your agent. Almost all of it out, and he has the receipts. This is the unreasonable effectiveness of HTML.
By the end of this video, you will know exactly why your codebase is about to look very different. And whether that is a good thing. Here is what HTML can carry that Markdown cannot.
One, information density. Markdown can carry headings, bold, a bullet list, a table if you squint at it. That is roughly it. HTML can carry eight things in one file. Tables, CSS-driven design, SVG illustrations, code snippets inside script tags, live interactions wired with JavaScript and CSS, workflows drawn with SVG and HTML side by side, spatial data, anything you can place on a canvas with absolute positions, and actual images with image tags.
Derrick's claim, and I think it holds, there is almost nothing Claude can read that you cannot represent in HTML. So what does the model do when the format fails it? It improvises. ASCII diagrams, or his favorite, estimating colors with Unicode characters. Boxes that pretend to be charts, hashes that pretend to be color swatches. That is the cost of forcing a powerful agent through a format built for a 1990s readme.
When you give it HTML, the agent stops faking the chart and just draws the chart. So, compare. Same data, two formats. Markdown gives you this. A bar chart hand-drawn out of pipes and dashes. From a distance, it looks like a chart. Up close, the columns drift. The bars do not line up with the axis. And the second you paste it into a doc with a different font, every alignment breaks.
HTML gives you this. Same five numbers. A real SVG bar chart, rendered crisply, picking its own colors from a palette. Sitting inside a single.html you can open in any browser. That is why Derrick writes HTML documents are easier to read, easier to organize visually, easier to navigate with tabs and links and illustrations. He says the chance someone actually reads your spec, your report, your PR write-up, that chance gets much, much higher when it is HTML. A Markdown file is a thing your colleague will skim. An HTML file is a thing your colleague will open. That is the difference.
And yes, there is a price. The honest one. HTML can take two to four times longer to generate than Markdown. Two to four X. That is real. But here is the piece that changes the math. Opus 4.7 ships with a 1 million token context window. 1 million, which means the extra tokens you spend rendering HTML, they barely register against the budget you already have. The cost is real. The cost is also absorbable. And in exchange, you get a document your team will actually read.
Some of the replies under the post pushed back on this. They argued Markdown's lower token spend is itself the value. The honest answer is it depends what you are buying.
Over a thousand builders. Daily hangouts, weekly workshops, and a community that actually ships together. Three full courses. The Agentic Coding Course, 18 modules. Master the systems that make AI coding repeatable. The AI Agent Mastery Course, build production agents with N8N and Python. And the Second Brain Bootcamp, eight modules. Build your own personal AI system from scratch. Link in description, 10% off.
Back to the video. Here is the part that turns this from a thesis into a workflow. Five places where switching to HTML changes everything.
Use case one, specs, planning, and exploration. You ask Claude code to fan out six approaches to a problem in one HTML file. Side by side, each one labeled with the trade-off it is making. You pick. The pick becomes a plan with mockups and code snippets baked in.
Use case two, code review. The PR diff rendered with margin annotations, severity colors, jump links. Derrick attaches an HTML code explainer to every PR he makes now. And he is on the team. He says it works better than the default GitHub diff view.
Use case three, design and prototypes. Claude Design is built on HTML for a reason. HTML is incredibly expressive for design. Even when your end surface is React or Swift or anything else. Claude sketches in HTML then translates. You can ship the prototype with sliders and knobs. Tune the animation, then copy the parameters back into a prompt.
Use case four, reports, research, and learning. You point Claude code at your codebase, your Git history, your Slack, the internet. You get back a single readable explainer page. A diagram of flow, three or four key code snippets annotated, a gotcha section at the bottom.
Use case five, custom editing interfaces. This one is the sleeper. Sometimes typing in a text box cannot describe what you want. So, Claude Code builds you a throwaway editor. A single HTML file purpose-built for your one piece of data. Drag 30 linear tickets into now, next, later, cut. Edit a feature dependency warnings. Tune a system prompt with live re-render of three sample inputs. And every one of them ends with one button. Copy it back out. As Markdown, as a diff, as a prompt for the next session.
So, why Claude Code specifically? Why not Claude AI or Claude Design? Because of what Claude Code can ingest, your file system. Every dot HTML file you have already generated, all visible at once. Your MCP surface, Slack, Linear, anything you have connected, your browser when you have Claude in Chrome. Your Git history, the why behind every line of code. That stack of context is what makes the HTML output actually informed. The agent is not synthesizing in the dark. It is synthesizing from your real work. Move the same prompt to a chat surface and you lose half of it. The artifact comes back generic. Pretty maybe, but generic. This is the part that does not transfer. Claude Code's reach into your environment is the input that makes the output worth having.
Here is the part the article actually ends on. Derek says the real reason he switched is not density. It is not sharing. It is not even the joy of making things. It is that he stopped reading the Markdown plans. He would offload work to Claude, get back a wall of text, and he just would not read it. Which meant he was leaving Claude to make every choice. Which is a slow way to lose the plot. The HTML versions, he reads them. He clicks around. He suggests changes. He is back in the loop.
So, I will let Derek close it himself. "I'm happy to say I feel more in the loop than ever before when using HTML. I hope you do, too."
The replies under the post are full of people saying the same thing. "I was already doing this. I just did not have the framing yet." "This finally explains why Claude keeps printing HTML as artifacts." "I'm moving my whole planning workflow today." You are going to see this format show up everywhere over the next few months. Specs, PR write-ups, status reports, internal explainers. Even editorial magazines, and judging by the replies, plenty of other places, too. Get ahead of it. Open one of the files in Derek's gallery. Look at how it reads compared to the Markdown you would normally get. And if you want to learn more about AI, check out the dynamis.ai community.