What This Video Gets Right
Thariq names the exact problem most Claude Code users have but can't articulate: long markdown plans stop being read. Coming from an Anthropic engineer, this isn't a hot take — it's a confession that validates what we've all been doing wrong. The 'compute allocator' reframe is the most important line in the whole interview. It changes what your job IS when you use these tools.
Who Should Watch This
Every 45+ educator, coach, or consultant who has installed Claude Code in the last 6 months and feels like they're spending money on outputs they don't fully understand. If you've got more than three plans in your ~/.claude/plans/ folder, this is for you. Bonus: if you're trying to bring a non-developer audience along with AI tooling, the HTML pattern is the single easiest upgrade you can teach them.
How This Connects to Our Model
The TrainingSites model is built on live facilitation, accountability, and outcomes — the parts that don't get automated away. Thariq's insight reinforces that: as agents get smarter, the planning and spec phase gets MORE important, not less. That's where humans add value. The same logic that justifies live sessions over static courses justifies HTML plans over markdown plans — it's about staying in the loop with what's being built. Agent Builders members can use this pattern tomorrow with no new tools.
I opened my ~/.claude/plans/ folder this morning. Fifteen markdown files. I haven’t read any of them this month.
I’m the one who asked Claude to write them. I’m the one paying for the compute. And I’ve been hitting “go” on plans I haven’t read.
If you use Claude Code, you’ve probably done the same thing.
An Anthropic engineer just said the same thing — out loud, on a podcast
Last week Thariq Shihipar, who works on the Claude Code team at Anthropic, sat down with Claire Veo on the How I AI podcast. About two minutes in, he says this:
“Markdown became a really popular way of interacting with agents, but the plans are so long, I honestly have stopped reading them. And this was honestly a mistake. I think that you still need to be really in the loop.”
— Thariq Shihipar, Claude Code team @ Anthropic
The engineer who builds Claude Code stopped reading his own plans. So did I. So did you.
That’s the problem. Here’s the line that made it click for me:
“When you say, okay, Claude can run for 8 hours, what you’re really saying is Claude can spend 500 bucks. All of us are becoming these compute allocators now. You have to decide what is worthwhile spending the compute on.”
That’s the job now. Not coder. Not writer. Not even prompt engineer. Compute allocator — you decide what’s worth $500 of Claude time. If you didn’t read the plan, you’re allocating that compute blind.
The fix is not a new tool. It’s one word.
Stop asking Claude for plans in markdown. Ask for them in HTML.
That’s it. Same Claude Code, same prompt structure, same workflow. You change .md to .html, and suddenly:
- Plans are scrollable, with headings you can actually scan
- Mockups are real images, not ASCII art
- Tables render as tables, not pipe characters
- Code snippets sit in proper boxes
- You can open the file in a browser and look at it like a website
Thariq’s words: “This is the plan. It’s purely in HTML. This is something that I will actually read.”
Same information. Different medium. You re-enter the loop.
5 prompts you can copy today
These are the prompts Thariq walked through in the video. I’ve adapted them so an educator, coach, or consultant — not a developer — can use them in Claude Code starting this afternoon.
1. Brainstorm in HTML, not in chat
When you want options, not opinions:
Brainstorm 8 ideas for [your topic]. Put them in a single HTML file with a little mockup for each one. Whatever visual makes each idea easy to compare. I trust your judgment.
You get a one-page menu instead of a wall of text. Open the file in your browser. Pick one.
2. Plan in HTML
When you’ve picked the idea and want a plan you’ll actually read:
Create an HTML file as a plan that helps me visualize what the implementation looks like. Include excerpts, mockups, code samples — whatever is needed to give me maximum context.
The “maximum context” line matters. It tells Claude to use the medium fully — not just a long document with HTML tags, but mockups, diagrams, side-by-side comparisons, sample output.
3. Have Claude interview you before it plans
Most plans are wrong because the brief was wrong. Surface what you don’t know you don’t know:
Before you write a plan, interview me. Ask me one question at a time. Cover what I want, what I don't want, who it's for, what success looks like, and what could go wrong. When you've got enough, write the HTML plan.
This is the single biggest upgrade in this whole post. Most people skip it and wonder why their plans don’t fit.
4. The throwaway editing UI
This one is sneaky-powerful. You’re reading your HTML plan and one section is wrong — say, a table of rules or a set of options. Instead of typing back “change row 3,” you ask Claude to build you a custom editor for that section:
Create an editable HTML artifact to help me define the [rules / options / sections] in this plan. Make it a custom UI that gives me structure but lets me edit freely. Design the ideal interface for this. Output a markdown summary I can paste back into the plan.
You get a little personal app — sliders, dropdowns, edit fields — for one decision. Use it for 2 minutes. Throw it away. Paste the result back into your plan.
Claire Veo called it “micro software on top of micro software.” That’s exactly right. You’re not building software. You’re building a 2-minute tool that helps you make one decision faster.
5. Your design system as design.html
If you’re building anything with a look and feel — a course site, a community space, a sales page — have Claude extract your design system into HTML once, then pass that one file to every new project:
Look at my [website / community / brand]. Extract the design system — colors, fonts, spacing, button styles, key components — into a single HTML file I can reuse. Show every component in action so I can see it.
Then for any new project: “Use design.html in this folder as the design system.”
One file. Every project on-brand. As Claire Veo put it: “Design.md is dead. Long live design.html.”
Why this works (the part nobody explains)
The technical answer is that Claude reads HTML and markdown about equally well. So the change is not for Claude. The change is for you.
HTML pulls you back into the loop because you can actually see it. Markdown lets you off the hook — you skim, you scroll, you tell yourself you read it. HTML doesn’t let you fake it. Visual stuff either looks right or it doesn’t, and your eye knows in 2 seconds.
That’s the whole insight. Better medium → you actually engage → you catch mistakes earlier → Claude builds the right thing → less wasted $500 runs.
What to do tomorrow morning
- Open Claude Code on your next real project
- Use prompt #1 (Brainstorm in HTML) or prompt #2 (Plan in HTML) instead of asking for markdown
- Open the resulting
.htmlfile in your browser - Actually read it. All the way through.
- Use prompt #4 (throwaway editing UI) on any section you want to change
That’s the whole shift. No new tools. No new platforms. Just stop letting markdown be the default.
Watch the full conversation
The full 25-minute interview is worth watching — Thariq goes deeper on the “living design system” pattern and Claire reframes product management as compute allocation in a way that lands hard.
Why this Claude Code engineer uses HTML files as AI specs — How I AI podcast
Want a place to learn this kind of thing with other 45+ educators and coaches?
This is what we do inside Agent Builders. Every second Monday I build agents live — I show what’s actually working in Claude Code, what’s failing, and what the prompt patterns are this week, not the ones that were hot 6 months ago.
If you’re tired of figuring this out alone, come work alongside us: trainingsites.io/sprint.