The Habits Nobody Posts About
Most Claude Code advice is about prompts. The people who build Claude Code barely mention them.
That gap stuck with me after this week's How I AI episode with Thariq Shihipar, who works on Claude Code at Anthropic. Three of his team's habits aren't about phrasing a request better. They're about the shape of the artifacts the work produces, and where those artifacts live. All three are easy to copy this afternoon.
Plans Live as HTML, Not Markdown
When an Anthropic engineer asks Claude Code to plan a feature, the plan comes back as an HTML file committed to the repo. Markdown is for notes. HTML is for review.
The reasoning is about how you actually read. A markdown plan is a wall of text you skim and approve. An HTML plan renders in a browser: headings you can collapse, links you can click, a layout your eye can move through. The format makes you read the plan instead of nodding at it.
That matters because the plan is the cheapest place to catch a mistake. Reviewing a rendered plan for ten minutes is faster than reviewing the 600 lines of code it would have produced. You're moving the review earlier, to the artifact that costs the least to change.
Two more reasons the HTML lives in the repo, not a doc:
- The plan sits next to the code it describes. Open the folder a month later and the reasoning is right there, version-controlled alongside what shipped.
- The next agent can read it. A plan in a Google Doc is invisible to the tool doing the work. A plan in the repo is context the model picks up for free.
The move to copy: when a task is bigger than one clean change, ask for a plan as a rendered artifact you'll actually review, and keep it in the project. Spec-as-code beats spec-in-a-doc-nobody-opens.
Throwaway Apps for Jobs That Resist a Prompt
The second habit sounds wasteful and isn't. For any task that resists a clean prompt, they build a tiny single-use app, run it once, and throw it away.
Some jobs are hard to describe in a sentence but trivial to do with ten lines of code. Reshape this messy export into the format the next step wants. Diff these two lists and show me what changed. Pull every TODO out of the codebase and group them by file. You could fight the phrasing of a prompt for fifteen minutes, or you could have the agent write a small script that does the thing exactly, then delete it.
The build cost collapsed, so the math changed. When a one-off tool takes two minutes to generate, "build a tool for this single task" stops being over-engineering and starts being the fast path. The tool isn't precious. It did one job. It's gone.
This is the same instinct behind reaching for code instead of cleverness. A prompt is you describing the transformation in English and hoping the model holds all of it. A ten-line script is the transformation, executed exactly, every row, no drift. For anything deterministic, the script wins.
The move to copy: next time you're rephrasing the same request for the third time, stop. Ask for a small tool that does it directly. Use it. Throw it away.
The Design System Travels With the Codebase
The third habit is why their output looks on brand without anyone pasting style rules into chat. The design system lives in the codebase. Tokens, components, patterns. The model reads them and matches them.
Most people treat visual consistency as something they correct after the fact. The agent generates a button in the wrong blue, you tell it the right hex, you do that forty more times across forty more sessions. The fix never sticks because it never gets written down anywhere the model looks.
Put the design system in the repo and the correction stops repeating. The color tokens, the spacing scale, the component patterns are all sitting in files the agent reads before it generates anything. On-brand output becomes the default instead of a thing you nag the tool toward.
This site works exactly that way. The brand colors and typography live in their own Skills, and a line in the lightweight CLAUDE.md (and AGENTS.md) points at them. When an agent styles a new page, it reads the tokens first. The output lands in the right palette because the palette was context, not an afterthought.
The move to copy: write your visual rules down once, in the repo, in a form the model reads on its own. Stop correcting the same blue.
What the Three Have in Common
None of these is a prompt trick. Each one is about giving the work a durable home the agent can see.
The plan is an artifact in the repo, shaped for review. The throwaway tool is the work done in code instead of described in prose. The design system is context the model reads instead of a correction you keep repeating.
That's the through-line: the payoff isn't in the sentence you type, it's in what you leave behind for the tool to read next time. Prompts vanish when the chat resets. Artifacts in the repo compound. It's the same reason context, not prompting, is the only AI skill that compounds. The engineers closest to the tool optimize the context, and let the prompts stay boring.
Start With One
Pick the one that fits your week. If you keep re-explaining your visual style, write it into the repo. If you keep re-reading dense plans, ask for HTML. If you keep wrestling a prompt that won't behave, build the throwaway tool.
The engineers who build the tool aren't doing anything you can't do by Friday. They've just stopped expecting the perfect prompt to save them, and started leaving better artifacts for the next loop. That habit scales, especially once you're running more than one agent at a time and can't babysit any single thread.