How I AI: Thariq Shihipar on Replacing Markdown with HTML for AI-Powered Development

When Thariq Shihipar, an engineer on the Claude Code team at Anthropic, told me “HTML is the new markdown,” I knew I was in for a treat. We were at the Code with Claude event in San Francisco, and this simple statement kicked off one of the most interesting conversations I’ve had about the evolving relationship between humans and AI agents.

For a while, Markdown has been the lingua franca for interacting with LLMs. It’s simple, structured, and easy for both people and models to read. But as Thariq pointed out, as our AI partners get more capable and the projects we build get more complex, we’re starting to hit the limits of what a simple text file can do. Huge, thousand-line Markdown plans become overwhelming, and our eyes start to glaze over. We stop reading, we stop engaging, and the quality of our collaboration suffers.

This is where Thariq’s insight comes in. He's found that by using HTML, we can create a much richer, more engaging communication medium. It’s not that the models struggle with Markdown—they’re brilliant at it—but that HTML makes it easier for us, the humans in the loop, to visualize, interact with, and stay connected to the work being done. It pulls us into the process, transforming us from passive reviewers into active collaborators. As Thariq so perfectly put it, we're all becoming "compute allocators," and our main job is to decide what's worth spending compute on. HTML helps us make better decisions.

In this episode, Thariq walked me through three incredible workflows that all center on this idea. We covered how he uses HTML for brainstorming and planning, how he gets Claude to build disposable "micro-apps" for editing those plans, and how he maintains a "living design system" that travels with his code. It's a fundamental shift in how we can work with AI, and it’s something you can start doing today.

Workflow 1: Brainstorming and Planning with Interactive HTML

The first and most fundamental workflow is ditching long, boring text-based plans in favor of dynamic, visual HTML artifacts. When you're dealing with a plan that's thousands of lines long, you just stop reading it. Thariq admitted he'd just ask Claude to edit the plan instead of reading it himself. The solution is to create a plan you actually want to read.

Step 1: Start the Conversation in HTML

To prepare for our podcast, Thariq didn’t just ask for a list of ideas. He started a conversation with Claude Code and gave it a very specific instruction.

I was literally like, look, I'm on a Claire Vo podcast. I want to do a demo, you know, and can you brainstorm some ideas in HTML file?

This simple switch from asking for a list to asking for an HTML file produced a completely different kind of output. Instead of a text list, he got a visual, scrollable page with eight distinct demo ideas, each with its own little mockup, a description, and even a risk assessment. It was immediately more engaging and easier to digest than a wall of text.

Step 2: From Brainstorm to a Full-Blown Plan

After picking an idea—in this case, "CSV to interactive dashboards"—Thariq took it a step further. After a bit of back-and-forth to let Claude "interview" him about the idea, he asked it to generate the full implementation plan, again using HTML. The prompt was beautifully simple and effective.

create a HTML file as a plan that helps me visualize what the implementation plan is. Include excerpts, mockups, code, whatever is needed to give me like maximum context

Notice a couple of key things here. He misspelled "excerpts," which didn't matter at all. More importantly, he gave Claude an out with "whatever is needed to give me like maximum context." This is a philosophy Thariq uses often: provide enough constraint to get what you want, but leave room for the model to surprise you. As he says, "I always needed to be like, 'Hey, Claude, like I trust you here.'"

The result was a comprehensive, single-file website that contained everything from a scripted podcast intro and file structure diagrams to code snippets and even a visual mood board for the UI. It's a document you can actually read, explore, and share with a teammate, who is far more likely to engage with this than a giant Markdown file.

Workflow 2: Building Micro-Apps to Edit Your Plan

This is where my mind was truly blown. The immediate objection to using HTML is that it’s not as easily editable as Markdown. If you see something you want to change in a complex table or a set of rules within your HTML plan, what do you do? Open up a code editor?

Thariq's solution is brilliant: you ask Claude to build a temporary, disposable user interface—a micro-app—just for editing that one specific part of the plan.

It's like this is not even personal software. This is like sub... it's like micro-software on top of micro-software.

Step 1: Identify the Editing Challenge

In his HTML plan, Claude had generated a set of decision rules for how to turn different data types from a CSV file into visualizations. Thariq felt these rules were a bit arbitrary and wanted to refine them. Instead of a tedious back-and-forth chat, he decided to create a better editing experience.

Step 2: Prompt for a Custom UI

He gave Claude another prompt, this time asking for a tool to solve his specific problem.

I want to create an edible HTML artifact to help me define the decision rules... I don't like the ones we have right now. Make this a custom UI that helps me with structure but gives me flexibility. Design the ideal interface for this problem.

Step 3: Use Your Throwaway App

What Claude returned was a beautiful, custom webpage that was a dedicated UI for editing those decision rules. It had input fields, dropdowns, add/remove buttons, and even a button to copy the final configuration back to his clipboard as Markdown.

He could now interact with this complex set of rules in a structured, visual way, get the output just right, and then bring the perfected data back into his main workflow. This is an amazing example of the "abundance mindset" Thariq talked about. We can now afford to generate these throwaway tools to make our own process more efficient and enjoyable.

Workflow 3: Creating and Using a "Living Design System" in HTML

Finally, Thariq showed how to apply this HTML-first approach to one of the most persistent challenges in software development: maintaining and adhering to a design system. How do you make sure that the new features you're building with Claude match the look and feel of your existing application?

His answer is to create a design_system.html file—another artifact that is both human- and machine-readable.

Step 1: Extract Your Design DNA

You can point Claude at a project folder or even multiple GitHub repositories (like your marketing site and your app) and ask it to extract the design system. It will analyze the CSS, components, and styling to understand your app's visual language.

Step 2: Generate the design_system.html Artifact

Next, you have Claude generate an HTML file that represents this system. This isn't just a style guide document; it's a living artifact. It visually displays the color palette, typography scales, spacing rules, and even interactive examples of core components. You can see the buttons, the inputs, the cards—all rendered right there on the page.

This file now becomes a portable source of truth. When you start a new project or feature, you just give Claude the design_system.html file as context. It can reference this file to ensure everything it builds is perfectly on-brand.

Step 3: Explore Variations and Share with Your Team

This workflow can get even more sophisticated. Using tools like Claude Design, you can create component playgrounds with interactive knobs and sliders to explore variations. What would this button look like with more padding? What if the border was a different color? You can build a simple UI to let you play with these properties in real-time.

As I mentioned in our chat, I do something similar by creating a component visualization page. This is incredibly useful for marketers or other non-technical stakeholders who need high-fidelity mockups for decks or videos. They can go to a single page, see all the app components in various states, and get exactly what they need without bugging an engineer. This HTML artifact bridges the gap not just between you and the AI, but between engineering and the rest of the company.

---

What I love about Thariq’s approach is how it recenters the human. These workflows aren't about fully automating the developer away; they're about creating better tools for collaboration. By shifting from plain text to rich, interactive HTML, we make the entire development process more visible, more engaging, and ultimately, more effective.

Thariq mentioned that maybe only 1% of the tokens he generates end up in production code. The other 99% are spent on this rich, beautiful, and sometimes disposable scaffolding: the plans, the custom interfaces, the status updates, and the design systems. This is what it means to be a compute allocator—investing resources in alignment and communication to ensure that the 1% that does ship is exactly what it needs to be.

I strongly encourage you to try this. The next time you sit down with Claude, don't just ask for a list. Ask it to build you a webpage, design you an interface, or create a plan in HTML. You might be surprised by how much more connected you feel to the process and how much better the final result is.

Thanks to Our Sponsors

• [Celigo](https://www.celigo.com/)—Intelligent automation built for AI
• [Persona](https://withpersona.com/)—Trusted identity verification for any use case

Episode Links

• YouTube: https://youtu.be/Qrpm7E80wQ0
• Spotify: https://open.spotify.com/episode/6Wtk2CxwbHUwYGAe9HWgYT?si=Q9G6nIpsQQ-U25nNAwN8Mw
• Apple Podcasts: N/A

Find more about our guest Thariq Shihipar on his LinkedIn and X. You can find me, Claire Vo, on LinkedIn and X.