How We Claude Code
Thariq Shihipar works on Claude Code at Anthropic. He opened Code w/ Claude Extended with a workshop called "How we Claude Code." The room was packed. All the chairs and tables were taken (I was lucky to get a seat), and the rest of the crowd stood along the walls.
His point: agents can run for 8 to 10 hours now. They cost real money. When something goes wrong that far into a run, it hurts. So how do you stay in the loop without hovering over it the whole time?
Three parts.
1. "Interview me"
Most prompts leave out more than they include. You've got this whole picture in your head, but by the time you type it out, half of it is gone. Thariq's fix is two words.
"The magic word for prompting is 'interview me.' Claude really gets that and starts to learn about you."
Say those words and Claude goes into question mode. It'll ask about your audience, your constraints, stuff you probably haven't considered. For something vague, expect 30 or 40 questions over several rounds.
He demoed this with a bill-splitting app. Starting prompt: "create a bill splitting app for me." That's it. Intentionally vague. Claude immediately started asking questions. Who's the audience? Roommates? Travel groups? Multiple currencies? When does collection happen?
Be honest with Claude about what you don't know. Use it as a thought partner to pull out what's in your head, and to surface what you haven't thought about yet.
Someone asked why Claude doesn't just do this automatically. Thariq's answer: Claude has no idea how much you already know. If you've got a precise spec in your head, getting quizzed is annoying. If you don't, the interview is exactly what you need. Even humans struggle with this when talking to each other.
2. Use HTML for plans
Thariq said he's done with markdown.
"I have totally stopped editing markdown files. I ask Claude to edit them. And if I'm asking Claude to edit it, there are prettier ways. HTML. It can include diagrams, code paths, mockups. And I'm definitely more likely to read it."
Markdown became the default because humans could edit it anywhere. Thariq just asks Claude to edit his specs now, so why stick with a format that was optimized for human editing?
He showed an HTML spec Claude had generated for the bill-splitting app. It had a table of contents, expandable sections, and visual diagrams baked in.
Mockup demo
He asked Claude to explore four different design directions for the bill-splitting app, each as a set of HTML files with full screen mockups.
Took about 15 minutes. Four completely different directions: receipt-style, ledger, social/Venmo-style, card-stack.
"I haven't asked Claude to go off for 8 hours to build the entire app. I asked it to go off for 15 minutes to build me mockups."
Nothing in the mockups actually functioned, but you could see the design and pick a direction before sinking hours into a real build. Fraction of the token cost.
He also showed a TL;DR for a PR as an HTML file. Module map, overview of changes, highlighted sections for the reviewer. His take: the clickthrough rate when he sends an HTML file to teammates versus a markdown PR description is "orders of magnitude different."
3. Verification
This seemed to be the part Thariq cared about most.
"Given that agents are so good at writing code, the most important thing to focus on is verification. The most talented engineers on the Claude Code team are working on verification."
Verification goes beyond unit and integration tests.
Verification environments
He showed something he calls a "verification environment." Like Storybook, but built for verification, not just visual browsing. His React demo loaded components one by one, ran actions against them, and recorded video clips of the results.
When he submits a PR on the Claude Code codebase, he gets a video of Claude testing the changes.
Modulize by verifiability
Someone asked how to structure code for agents. Thariq said he used to not have a strong opinion on this, but now he does.
In React, he used to put state and UI in the same file. Helped him think through the problem. Now he keeps state and UI in separate files so he can verify each one independently.
Structure your code so that each part can be independently verified. If you can verify the state logic separately from the UI, and render the UI in isolation, you've made the whole system more trustworthy for agents to work with.
His point was that nobody has fully figured this out yet, and if you invest here now, it pays off more as models improve.
Q&A highlights
On effort levels: "In the old Pokemon games, if you set effort low, it does speedrun techniques. It tries to cheat a little. What's the minimum work to do this task? If you set effort extra high, it will plan out the most precise way to get there." Most people at Anthropic haven't changed the default.
On leaving ambiguity in plans: "If I don't have a strong opinion, I'll just say 'use your best judgment.' You can also ask Claude to break the work into stages. Do stage one first, then decide on stage two after you have more information."
On skills: "I'm very anti 'npm install skills-dash-x' and then it's like CEO agent. If you've never read the skill, I don't trust it. Skills for your particular workflows are good."
On learning to code with Claude: "Instead of saying 'build me a tab browser,' say 'I'm learning to code, I want to build an app, I don't know what I don't know. Can you teach me some of these concepts?'"
Notes from the workshop. Quotes are from a voice recording and may be lightly edited for clarity. More from the event on the live blog.