How I AIWhy this Claude Code engineer uses HTML files as AI specs | Thariq Shihipar (Anthropic)
CHAPTERS
- 0:00 – 0:13
Why long Markdown plans fail—and why staying “in the loop” matters
Thariq explains that agent-generated plans have grown so long that he stopped reading them, which he calls a mistake. Claire reinforces that PRDs/specs still matter because humans need to understand and steer what agents are doing.
- •Markdown plans became unwieldy as agent runs got longer
- •Not reading plans reduces human oversight and alignment
- •Specs/PRDs remain critical even with smarter models
- •The core goal is staying in sync with the agent’s intent and actions
- 0:13 – 0:32
The “compute allocator” mindset: planning is spending money
They reframe modern product/engineering work as allocating compute budget. If you let an agent run for hours, you’re implicitly approving real cost—so the spec and planning phase becomes the key decision point for what’s worth building.
- •Long agent runs translate directly into dollars spent
- •Everyone becomes a “compute allocator” deciding where to spend tokens/time
- •Planning is how you surface unknown unknowns before paying for execution
- •Alignment with Claude is the new prerequisite to efficient building
- 0:32 – 6:52
HTML as the new Markdown: richer, more readable specs for humans
Thariq argues HTML is better than Markdown for consuming large plans because it’s more scannable, scrollable, and visual. Models can handle either format, but HTML makes humans more likely to actually engage and edit the work.
- •HTML improves readability and engagement vs. raw Markdown
- •Better visuals (mockups/diagrams) without ASCII workarounds
- •Richer medium reduces “eyes-glaze-over” skimming
- •Human engagement raises overall plan/spec quality
- 6:52 – 9:51
Demo setup: brainstorming demo ideas in an HTML artifact
Thariq shows how he starts by brainstorming with Claude like a collaborator, prompting it to generate demo ideas directly into an HTML file. The result includes multiple options with visual mockups, descriptions, and risks—making selection easier.
- •Simple prompt: brainstorm ideas directly in HTML
- •HTML output includes visual mockups and structured sections
- •Helps overcome the ‘won’t read beyond one screen’ constraint
- •Enables quick comparison and choosing a demo direction
- 9:51 – 12:18
From brainstorm to implementation plan: interview yourself, then generate the HTML plan
After selecting a concept (CSV to interactive dashboard), Thariq has Claude interview him to uncover requirements and edge cases. He then asks for a single HTML implementation plan that includes whatever artifacts provide maximum context: code excerpts, mockups, structure, and logic.
- •Use an ‘interview me’ step to extract requirements and unknowns
- •Prompt for a plan that maximizes context (excerpts, mockups, code)
- •HTML plan can include filesystem layout, templates, logic, and mood boards
- •A plan you’ll actually read becomes a practical execution artifact
- 12:18 – 13:48
Prompting philosophy: trust Claude, but add constraints with an escape hatch
They discuss balancing specificity and freedom in prompts: constrain what must be present (e.g., code excerpts) while leaving room for Claude to add useful context. The phrase ‘whatever is needed’ is used as a deliberate escape hatch to avoid over-constraining creativity and usefulness.
- •Give enough detail to get what you need, not a rigid template
- •Overbuilt prompts/skills can accidentally limit the model
- •Include must-haves (like excerpts) plus an open-ended allowance
- •Trust signals can improve outcomes and keep collaboration fluid
- 13:48 – 18:23
Future of PRDs and tech specs: one artifact or many, shaped to the audience
Claire and Thariq explore how HTML enables flexible packaging of product + technical detail depending on who’s reviewing. Instead of forcing a single template, specs can be assembled as interactive, audience-appropriate bundles (tabs, sections, linked views).
- •PRD and tech spec boundaries can be fluid with HTML
- •Artifacts can be customized for different reviewers and contexts
- •Interactivity (e.g., tabs) is easy and still model-readable
- •Types/interfaces and success criteria become powerful “boundaries” for alignment
- 18:23 – 21:45
Making HTML specs editable: generate a throwaway micro-app to edit one section
Addressing the ‘Markdown is easier to edit’ objection, Thariq demonstrates generating an editable HTML UI for a specific portion of the plan (decision/rendering rules). Instead of manual text edits, he creates a custom interface to adjust fields, hide/show elements, and export back to markdown/spec content.
- •If you dislike a plan section, build a UI to edit it—not just text revisions
- •Claude can generate a tailored micro-app for a single spec module
- •UI supports structured edits (fields, add/remove, copy/export)
- •The workflow turns spec editing into an interactive experience
- 21:45 – 23:35
Collaboration and sharing: hosting HTML artifacts and improving adoption
They discuss how HTML plans scale better socially: you can host and share a link, and colleagues are far more likely to read a web-like artifact. Thariq also uses HTML for weekly status updates generated from Slack summaries, making internal communication more consumable.
- •HTML artifacts can be hosted (e.g., AWS) and shared via links
- •Web-native readability increases the chance others will review plans
- •Claude-generated HTML status updates improve manager/team visibility
- •Better communication becomes a competitive advantage inside organizations
- 23:35 – 25:47
The abundance mindset: generate many artifacts, not just production code
Thariq argues that as software creation gets cheaper (Jevons-like effect), most tokens won’t go into production code but into exploratory artifacts: dashboards, custom interfaces, and planning tools. Claire adds that ‘source of truth’ debates matter less when documentation is cheap and models can find context.
- •Only a small fraction of tokens become production code
- •Most value shifts to exploration, visualization, and decision support
- •Just-in-time documentation and throwaway software become viable
- •Reduced cost changes how teams think about formatting and repositories
- 25:47 – 26:39
Plans as implementation artifacts: execute, then verify against intended output
Thariq explains how he would use the HTML plan as a handoff artifact: clear context, provide the plan, and ask Claude to implement. The plan also supports verification—agents can compare the intended mockups and requirements against what was actually built.
- •Use the HTML plan as the canonical artifact for implementation
- •Clear context + ‘implement this plan’ is the execution move
- •HTML mockups provide a reference for verification/validation
- •Artifacts help check ‘what we meant’ vs. ‘what we shipped’
- 26:39 – 30:16
Demo: living design systems in HTML for reuse across projects
Thariq showcases an HTML file that encodes a compact ‘living’ design system: colors, typography, spacing, radius, components. By dropping designsystem.html into repos, Claude can quickly ingest and apply consistent design rules across new projects.
- •Create a single HTML artifact representing the design system
- •Include core tokens plus component definitions for reuse
- •Point Claude at the folder to discover and apply the system
- •HTML becomes a portable, compressed design reference
- 30:16 – 31:43
Comments, annotations, and custom review workflows inside HTML plans
They explore extending HTML plans with interaction patterns inspired by Claude Design: commenting, circling, annotating, and building lightweight canvases for review. The broader idea is to shape the review tool to match how a team wants to run design/spec review rather than forcing generic tools.
- •Add comment/annotation systems directly into HTML artifacts
- •Borrow interaction models from design tools (e.g., canvas + markup)
- •Enable structured feedback that can be pasted back into Claude Code
- •Teams can encode their preferred review workflow into the artifact
- 31:43 – 35:58
Recap workflow + lightning round: favorite tools, compute future, and being nice to Claude
Claire summarizes the HTML-first workflow (brainstorm → plan → micro-app editors → living design system). In the lightning round, Thariq picks the Code tab, shares excitement about compute announcements, and discusses prompting style—staying friendly rather than yelling at the model.
- •Workflow recap: brainstorm in HTML, plan in HTML, build micro-UIs for edits
- •Design.md ‘dies’ in favor of portable designsystem.html artifacts
- •Event highlights include more compute online and sci-fi future concepts
- •Prompting: don’t yell; emotional tone can affect model behavior
