Living Design System

Sources#

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

Summary#

Thariq Shihipar's third HTML-first workflow: maintain a design_system.html file — an artifact that is both human- and machine-readable — as a portable source of truth for your application's visual language. Unlike a static style-guide document, it renders: color palette, typography scales, spacing rules, and interactive examples of core components (buttons, inputs, cards) all displayed live on the page. You hand this one file to Claude as context whenever you start new work, and everything it builds comes out on-brand.

This is the HTML as the New Markdown move applied to the persistent problem of design-system adherence: the same artifact a human can eyeball is the artifact the model reads to stay consistent.

How it's built#

1. Extract the design DNA. Point Claude at a project folder — or multiple GitHub repositories at once (e.g. the marketing site and the app) — and ask it to extract the design system. It analyzes the CSS, components, and styling to infer the visual language.
2. Generate the design_system.html artifact. Claude renders the extracted system as a single HTML file that visually displays palette, type scale, spacing, and interactive component examples — not a description of the components, the components themselves.
3. Explore variations and share. With tools like Claude Design, build component playgrounds with interactive knobs and sliders ("what would this button look like with more padding? a different border?") to explore variations in real time.

Why it's "living"#

A conventional style guide drifts: the doc says one thing, the code does another. A design_system.html extracted from the code and rendered as real components is harder to falsify — what you see is what the components actually do. And because it's a single portable file, it travels: give it to a new project, a new feature, or a teammate, and it becomes the reference that keeps output consistent. It is a durable allocation of compute — generated once, reused as context indefinitely — in contrast to the throwaway micro-apps.

Bridging engineering and the rest of the company#

The artifact's biggest payoff is organizational. A rendered component page lets non-technical stakeholders — marketers, PMMs, anyone making decks or videos — go to one page, see every component in its various states, and grab high-fidelity mockups "without bugging an engineer." Claire Vo reports doing exactly this with her own component-visualization page. The design system thus bridges not just human↔AI but engineering↔the rest of the company — the same human-facing-legibility payoff HTML as the New Markdown claims for plans.

Connections#

• Thariq Shihipar — originator of the design_system.html workflow
• Claude Code — extracts the design DNA from repos and renders design_system.html; Claude Design powers the component playgrounds
• HTML as the New Markdown — the parent thesis; design system is the HTML-first move applied to design
• Compute Allocator — a durable compute allocation (generate once, reuse as context)
• Disposable Micro-Apps — the throwaway counterpart; design system is the keep-it counterpart
• Claire Vo — runs a parallel component-visualization practice for non-technical stakeholders
• Engineer PM Convergence — an artifact that lets non-engineers self-serve high-fidelity assets is the tooling side of roles blurring across the org

Open questions#

• How does the design_system.html stay in sync as the codebase evolves — re-extract on a cadence, or wire it into CI?
• Does a rendered, model-readable design system measurably improve on-brand output vs. a plain CSS/token file, or is the win mostly human legibility?
• At what project size does maintaining the artifact cost more than the consistency it buys?

Sources#

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