HTML Is the New Markdown — How Claude Code Changed the Way I Plan Software
Anthropic engineers don't write text specs anymore — they have Claude Code generate HTML mockups. After trying it, I'm not going back.
I caught Thariq Shihipar's interview from Anthropic's Code with Claude event, and the title alone made me sit up: "HTML is the new Markdown."
Coming from a guy who works on the actual Claude Code team, that's not a hot take — it's a workflow change. And after a week of testing what he described in my own builds, I think it's the most underrated AI workflow shift of 2026.
The Old Way vs. The New Way
For the last two years, the default way to plan something with an AI was the same: open a chat window, ask for a markdown spec, review it, edit it, copy it into your task tracker, then start building.
The text spec was the artifact.
What Shihipar laid out at Code with Claude is that Anthropic engineers have already moved past that. Inside the Claude Code team, HTML is now the spec format — interactive, visual, clickable mockups that get generated as part of the planning conversation itself.
Instead of a list of bullet points describing a screen, you get the screen.
The "99% of Tokens for Planning" Mindset
The quote from the interview I keep coming back to: "99% of your AI-generated tokens should go to planning, interfaces, and communication — not production code."
That is the opposite of how most of us are using these tools.
Most people are still using Claude or ChatGPT like a faster Stack Overflow — paste the bug, get the fix, ship the code. Shihipar's framing flips the priority. Generation is cheap. The expensive part is figuring out what to build. So spend the model where decisions get made, not where keystrokes get saved.
This lined up with something I've been quietly doing for months — I train my own custom assistants on my tone, my brand, my product strategy. The assistant isn't a code monkey. It's a thinking partner that helps me design what I'm about to build before any code gets touched. Hearing the Anthropic team validate this approach was a real "OK, this is the way" moment for me.
What an HTML Spec Workflow Actually Looks Like
Here's how Shihipar described the loop:
- You start a planning conversation with Claude Code.
- Instead of asking for a list of features, you ask for an HTML mockup of the screen or flow.
- Claude generates a real, interactive HTML artifact — buttons, forms, the whole page.
- You click around, comment, edit, swap pieces.
- The artifact itself becomes the spec, not a markdown document.
When something needs to change, you don't go re-write a doc. You just regenerate that section of the mockup.
The result: a planning artifact you can actually show to a non-technical stakeholder. A founder. A designer. A customer. They can interact with the thing before it gets built and tell you what's wrong in five seconds instead of after two weeks of dev work.
The "Throwaway Micro-UI" Idea Is Genius
The specific tactic that stuck with me: throwaway micro-UIs for editing plans.
If you've ever tried to direct Claude to change a specific piece of a longer spec, you know how clumsy that conversation gets — "actually, in section 3, change the third bullet to say..." and now you're nine messages deep editing one sentence.
Shihipar's team builds tiny, temporary HTML interfaces inside artifacts to edit sections directly. Click a button, change a field, the spec updates. It's the difference between editing a Google Doc by sending emails versus opening the doc and typing.
This is the kind of thing you only invent when you live in the workflow. Most of us don't realize how broken the text-editing-by-chat pattern is until somebody hands us a better one.
Living Design Systems Inside the Repo
The other piece Shihipar talked about: design systems that live inside the codebase as reusable HTML artifacts.
When Anthropic engineers build something new, they pull from a shared HTML component library that travels with the repo. New project? Same components, same patterns, instant visual consistency. The documentation is just-in-time — generated as needed, not maintained as a separate burden.
For a small team or solo founder, this is huge. The traditional design system requires somebody to be the design system librarian. Nobody actually does that job at small companies. With Claude Code, the system maintains itself because the artifacts are reusable on demand.
Where I Push Back
A couple things worth being honest about:
HTML specs are heavier than markdown. That's the point — but it also means your token budget burns faster. If you're on the free tier of Claude, you'll hit limits quicker with this workflow.
Not every project needs visual mockups. A back-end refactor, a database migration, a CLI tool — markdown is still fine. The HTML-spec workflow shines for anything user-facing. For internal plumbing, the old text spec is faster.
The Anthropic team is in an unfair position. They have unlimited Claude. They built the tool. They can afford workflows that would be expensive for the rest of us. Calibrate accordingly.
What I'd Do With This Tomorrow Morning
If this lit a fire for you, here are the actions I'd take:
- Pick your next project. Don't start with a markdown spec. Start with: "Claude, build me an interactive HTML mockup of the first three screens of this product."
- Save the artifacts. Keep them in your repo. They are your spec now. Markdown can be the changelog.
- Bring stakeholders into the artifact. Anyone who needs to weigh in — a co-founder, a designer, a client — gets to interact with the mockup, not read a doc.
- Train your custom assistant. The biggest unlock is having an AI that knows your design language. Train it on your existing pages, your brand, your past projects. Then it pulls those patterns into every new artifact.
The Bottom Line
The Anthropic team isn't doing this for fun — they're doing it because it actually changes how fast they ship and how well their specs survive contact with the real product.
If you build software, the move is to stop treating AI like a faster way to write code and start treating it like a faster way to think about code. HTML-first planning is one of the cleanest examples of that shift I've seen all year.
Go try it. Bring me back the artifacts.