Field guide · How I AI ✦ Lenny's Newsletter
How Anthropic's Claude Code engineers stopped writing text lists and started shipping interactive plans.
01 — The core swap
Markdown was the lingua franca for talking to LLMs: simple, structured, easy to read. But as plans grew to thousands of lines, something broke — Thariq admits he just stopped reading them and would ask Claude to edit the plan rather than read it himself. The models never struggled with Markdown. The humans did.
"The plans are so long, I honestly have stopped reading them. And this was honestly a mistake. You still need to be really in the loop."
HTML fixes the human side: it's a richer medium you actually want to look at, so you stay an active collaborator instead of a passive rubber-stamp. A bullet list you skim; an interface you react to.
Same plan, twice. Click the toggle. The left one you'd approve in two seconds; the right one makes you say "wait, churn shouldn't be above signups." That reaction is the point.
02 — The mindset shift
When an agent can write the code, your job moves up a level. As Thariq frames it: "When you say Claude can run for 8 hours, what you're really saying is Claude can spend 500 bucks." You're no longer the one typing — you decide what's worth that compute. Toggle below to see where the tokens should actually go.
The assumption: "AI is for writing code, so most of its effort lands there." It feels right — and it's the trap.
"Maybe only 1% of the tokens I generate end up in production code." — the other 99% buys planning, interfaces, status updates, and design systems: the scaffolding that makes the 1% correct.
03 — Try the technique live
Here's the move: instead of asking for a list of ideas, ask for a mockup. Type any product or feature below. Claude is embedded right in this page — it'll think for a second and hand back a working HTML interface, rendered live. No bullets. A thing you can look at.
Notice what just happened: you described one sentence and got something you can judge. That tightens the loop between intent and feedback — the entire reason HTML beats Markdown for planning.
03½ — Steal these
Three lines do all the work. They share one trait: enough constraint to get what he wants, plus a deliberate "out" that lets the model surprise him. Note the typos — they didn't matter.
I'm doing a demo. Can you brainstorm some ideas in an HTML file? A little mockup for each one, whatever visual makes them easy to compare. I trust your judgment.
Returned a scrollable page of 8 ideas — each with a mockup, a description, and a risk assessment. A one-page menu, not a wall of text. He picked "CSV → interactive dashboards."
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
First Claude "interviews" him about the idea, then produces a single-file site: scripted intro, file-structure diagrams, code snippets, even a UI mood board. The "whatever is needed" clause is the intentional out — "I always needed to be like, hey Claude, I trust you here."
I want an editable HTML artifact to define the decision rules — I don't like the ones we have. Make a custom UI that gives me structure but flexibility. Design the ideal interface for this.
Out came a dedicated editor: input fields, dropdowns, add/remove buttons, and a button to copy the result back as Markdown. "This is micro-software on top of micro-software."
04 — The toolkit
Tap any card to open it.
"I don't want to hand-edit a spec — build me a tiny tool to edit it."
When one part of a plan needs tweaking, don't edit text. Ask Claude for a disposable single-purpose UI — sliders, dropdowns, reorderable lists — that lets you adjust just that piece. Use it, get the result, throw it away. The interface costs nothing because it never had to last.
A file literally named design_system.html — human- and machine-readable.
Point Claude at a project folder or even multiple repos (your marketing site and your app); it reads the CSS and components and extracts your visual language into one HTML artifact — palette, type scale, spacing, plus live, interactive examples of buttons, inputs, and cards. Hand that file to any new project as context and everything it builds comes out on-brand.
With Claude Design you can go further: component playgrounds with knobs and sliders to tweak padding or border color in real time. Bonus — non-technical teammates grab high-fidelity mockups for decks straight from the page, no engineer required.
Stay in the loop without strangling the agent.
Don't pre-specify every detail — that wastes your effort and Claude's. Add structure only where it buys you something: a constraint that prevents a real mistake, a format that aids review. Anything that doesn't pay for itself gets cut. HTML helps because seeing the output tells you exactly where more control is actually needed.
The prompting recipe: freedom + guardrails.
Give Claude room to make choices, then bound it with the few things you genuinely care about — "use our design system," "keep it under one screen," "these three states must exist." You get the upside of its judgment without gambling on the parts that matter to you.
When making interfaces gets cheap, you make far more of them.
Jevons paradox: as a resource gets cheaper to use, total use goes up, not down. Generating a UI used to be expensive, so you rationed them. Now a mockup costs a sentence — so build one for every idea, every plan, every conversation. Disposable interfaces become the default unit of thought.
Software that exists for one task, then disappears.
Not everything needs to be durable. Generate the doc when you need it, the tool for the moment you need it, and let both evaporate after. This removes the maintenance tax that used to make small tools not worth building.
The interactive plan isn't just for humans — it feeds the build.
The same HTML plan you reviewed becomes the input Claude implements against, and you can drop comments and annotations directly onto it. It's the spec, the review surface, and the hand-off to coding — one living document instead of a PRD, a Figma file, and a ticket.
05 — Putting it together
design_system.html. A plan you'll actually read.06 — Check yourself
Why does HTML beat Markdown for plans?
Right. Engagement is the mechanism — better reactions, better products.
Where should ~99% of your AI tokens go?
Right. You're a compute allocator — production code is the small leftover slice.
What does "complexity has to earn its keep" mean for prompting?
Right. Trust + targeted guardrails. Constraints must pay for themselves.