How we Claude Code
Claude · video · 2026-05-22 Reader 🖥️
Agent-Native DesignAgentic EngineeringBack Pressure (Verification-Bound Autonomy)Claude CodeHuman-in-the-LoopSpec-Driven DevelopmentVerifiability (as the Quality Bar)
As models get more capable and agents are trusted to run longer on more ambiguous tasks, engineers should stop trying to hand-constrain Claude up front and instead let it interview them into a spec, review that spec through richer, denser artifacts (HTML, not long Markdown), and build verification directly into the artifact itself (as an agent-readable DOM contract) so the same checks can run under human, agent, and headless (CI) supervision alike.
practical · conference/workshop talk with live coding demo — A hands-on workshop session (presenter: Arno, of Anthropic's Applied AI team) built around a cloneable repo ('cw-workshops', session 'how-we-claude-code'). It walks through three phases live: (1) prompting Claude to interview the user into a spec via the ask-user-question tool, (2) generating and reviewing rich HTML design mocks instead of long Markdown specs, and (3) building agent-native verification (DOM-published state, schemas/fixtures/invariants, three parallel check surfaces) into a small demo app. The content is credited throughout to 'Tariq' of the Claude Code team, whose blog post 'The Unreasonable Effectiveness of HTML Files' and repo the talk is adapting.
Structure
| Part | Role |
|---|---|
| Framing: why habits must change as models improve | Sets up the talk's premise via Sutton's 'bitter lesson' analogy — more capable models make longer, more autonomous runs viable, which raises the cost of a wrong early turn and motivates front-loading verification and requirements-gathering rather than constraining the model. |
| Phase 1 demo: interview-driven spec extraction (bill-splitting app) | Live demo of prompting Claude to use the ask-user-question tool, contrasting good prompting (domain scope, open-ended) against bad prompting ('just make it better'), with auto mode, fast mode, and a high effort setting. |
| Phase 2 demo: HTML specs over Markdown for design review | Argues Markdown specs become unreadable past ~200 lines, then generates and visually compares four HTML design directions for the same app, arguing this is both a better feedback surface and not more token-inefficient in the long run. |
| Phase 3 demo: agent-native verification (to-do app) | The talk's core technical payload — publishing component state into the DOM, defining schemas/fixtures/invariants tested by 'probes,' and running the same verification from a human dashboard, an agent driving a browser (Playwright MCP), and a headless CLI (`bun verify`), including diagnosing a deliberately planted failure. |
| Closing recommendations | Recommends Opus 4.7 (for its vision model) over Sonnet for this workflow, endorses fast mode despite its cost, and closes the token-inefficiency objection to HTML specs. |
Key terms
- Auto mode Claude Code
A Claude Code operating mode (cycled into with shift-tab) that lets the agent proceed through actions without per-step confirmation; presented as something everyone in the room should already be using. - Effort parameter (/effort)
A Claude Code setting controlling how much reasoning effort is applied per turn; the presenter's recommendation for this workflow is 'x high,' with 'max' as an alternative. - Interview (Claude interviewing the user)
A workflow where Claude proactively asks the user scoped, clarifying questions (triggered by explicitly invoking the 'ask user question' tool in the prompt) to extract requirements the user has not yet articulated, rather than the user trying to specify everything upfront. - HTML spec
A rendered, interactive HTML document used as the primary review artifact for both requirements and visual/UI intent, in place of a long prose Markdown spec — denser, screenshot-able, and later drivable by tools like Playwright MCP. - Verification (vs. testing) Verifiability (as the Quality Bar)
The practice of exposing an artifact's state/behavior as a checkable contract so it can be confirmed correct by a human, an agent, or headlessly — deliberately distinguished from unit 'testing' and pushed to be 'agent native,' i.e. driven by an agent alongside or instead of a human. - Invariant / probe
An invariant is a property of a component's DOM-published state contract that must always hold across its defined fixtures (known states); a probe is a test input deliberately chosen to push the component off its happy path to exercise that invariant. - Agent-native (make it available to the agent first) Agent-Native Design
Designing an artifact (here, a UI component) so its state is directly machine-readable — published into the DOM as data attributes — rather than requiring an agent to infer state by scraping the rendered UI or reaching into framework internals.
Propositions
- explicitAs models become more capable, agents can run for longer on more complex tasks, which raises the cost of an early wrong turn (burned tokens) and makes front-loading verification and requirements-gathering more important, not less.conf: high
- explicitAs models get more capable you should resist constraining them, by analogy to Sutton's 'bitter lesson' that hand-engineered, hand-constrained approaches get dominated over time by scale and raw capability.conf: high
- explicitClaude is likely better at extracting what a user actually wants from them than the user is at specifying it upfront, analogous to end users who 'know it when they see it' but can't articulate requirements in advance.conf: high
- explicitGood prompting for requirement extraction means naming the domains/areas of interest and leaving room for open-ended answers, rather than over-specifying the desired outcome or issuing vague commands like 'just make it better.'conf: high
- explicitExplicitly instructing Claude in the prompt to use the 'ask user question' tool is what triggers the interview workflow, where Claude asks a sequence of scoped clarifying questions and then writes a spec.conf: high
- explicitYou should always be using auto mode in Claude Code, and the recommended effort setting for this kind of work is 'x high' (max effort as an alternative).conf: high
- explicitMarkdown files, though historically 'the lingua franca of the AI-native software development life cycle,' become impractical once they exceed roughly 200 lines, because at that length neither the user nor their colleagues are likely to actually read them.conf: high
- explicitAn HTML file is denser and more ergonomic than a long Markdown file for reviewing what an agent is about to build, especially visual/UI intent, and can be paired with screenshots and later driven by tools like Playwright MCP.conf: high
- explicitGenerating multiple, visually distinct HTML design directions (e.g. a 'brutalist' vs. a 'Tokyo fintech' aesthetic) for the same spec gives the user a comparative artifact to react to, which is much harder to infer from prose alone.conf: highsupportsClaude Code: Best practices for agentic coding · p10 — Supports and instantiates the best-practices claim that a clear, machine-checkable target (a visual mock/screenshot) drives convergent iteration — the four-HTML-design-direction demo is a direct, worked example of exactly this pattern applied to UI design.
- explicitOpus 4.7's improved vision model makes it easier for Claude to extract what is visually wrong from a screenshot than for the human to articulate the problem in words, especially for subtle front-end misalignments.conf: medium
- explicitHTML specs are not more token-inefficient than Markdown specs in the long run: although a rich HTML spec costs more tokens to generate up front, it reduces the number of iteration cycles needed afterward, lowering total token cost.conf: medium
- explicitPublishing a component's internal state directly into the DOM (as data attributes) lets a verification framework read exact application state without scraping the rendered UI or depending on framework internals, decoupling verification from implementation.conf: high
- explicitA verification framework for an agent-native component is built from a schema, a set of fixtures (known states), and invariants — properties that must always hold — tested via 'probes' that deliberately push inputs off the happy path.conf: highextendsThe Anatomy of an Agent Harness · p7 — Extends the harness piece's rules-based/visual/LLM-as-judge verification taxonomy with a concrete implementation pattern: publishing component state directly into the DOM as a schema+fixtures+invariants contract, so rule-based checks, human visual review, and agent-driven checks all read the same underlying artifact.supportsWhen AI Writes the Code, Specifications Need an Exit Strategy · p5 — Supports the claim that durable system knowledge should be promoted into native, code-adjacent artifacts (schemas, types, tests) rather than kept as permanent prose — the schema/fixtures/invariants verification framework is a concrete, worked instance of exactly that kind of native artifact.
- explicitThe same underlying DOM-state/invariant contract can be checked from three distinct surfaces — a human-readable dashboard, an agent driving a browser directly (e.g. via Playwright MCP from Claude Code), and a headless CLI run (`bun verify` for CI) — without re-implementing the checks for each surface.conf: high
- explicitA deliberately broken invariant (a displayed total not matching its components, e.g. 3 + 4 shown as 10) demonstrates that this framework detects contract violations distinct from application bugs, and that Claude Code, using the DOM contract and Playwright MCP, can autonomously diagnose the cause of a failing check.conf: high
- explicitVerification runs can be recorded as video clips and stored (e.g. on S3) or shared with colleagues as auditable evidence that a change works — a practice the internal Claude Code team already uses for front-end changes.conf: high
- implicitAs agents are trusted to run more autonomously and for longer, the practical bottleneck shifts from raw model capability to how cheaply, quickly, and reliably a human or agent can verify what was produced — front-loading rich specs and building verification into the artifact itself is how that review capacity is preserved as autonomy grows.conf: medium
- explicitFor this workflow, Opus 4.7 is recommended over Sonnet specifically for its stronger vision model, and 'fast mode' — though more expensive — is worth using to iterate quickly on specs.conf: high
Arguments
Engineers should stop trying to fully specify requirements to Claude up front and instead prompt it to interview them, letting Claude extract latent requirements turn by turn. strength: medium
Explicit premises:
- Models are becoming more capable, so agents can run longer and handle more ambiguity.
- Claude is likely better at extracting what a user wants than the user is at articulating it upfront, analogous to end users who 'know it when they see it.'
- Good prompting scopes the domain and leaves the outcome open-ended rather than predefining it.
Implicit premises:
- By the logic of the bitter lesson, hand-engineered human specification effort will generally be dominated by the model's own capability at extracting the right signal, so investing human effort in exhaustive upfront specs is a comparatively poor use of that effort.
- Over-specifying prematurely risks anchoring the model on the user's own possibly-incomplete or biased assumptions rather than surfacing the user's actual latent needs.
Inferences:
- Since models already extract requirements better than users specify them, the higher-leverage human action is structuring how the interview happens (scope, openness) rather than trying to write the 'right' answer down first.
Verification should be built as an agent-native, artifact-level property of the software itself — not a separate testing step bolted on afterward — so the same checks work for a human, an agent, and a headless CI run. strength: medium
Explicit premises:
- Publishing component state into the DOM lets verification run independent of how the UI is implemented or scraped.
- A schema/fixtures/invariants structure, tested by probes that push off the happy path, gives a precise, reusable contract.
- The same contract is demonstrably checkable from three different surfaces (human dashboard, agent-driven browser, headless CLI) without re-implementing the checks.
Implicit premises:
- As granted agent autonomy scales, the human capacity to individually review every change does not scale with it, so verification capacity — not raw model capability — becomes the practical constraint on how much can safely be delegated.
- Recording verification runs as retained video evidence substitutes for a human watching every change live, letting trust be established after the fact via evidence rather than through continuous supervision.
Inferences:
- If verification can be made cheap, fast, and machine-checkable at the artifact level, then the same underlying work supports human review, agent self-diagnosis, and CI gating simultaneously, rather than requiring three separate verification efforts.
Narratives
- Live prompting demo: Arno prompts Claude (with auto mode, fast mode, and a high effort setting) to build a bill-splitting app, using an intentionally scoped, open-ended prompt that explicitly invokes the 'ask user question' tool. Claude tapes through clarifying questions (audience? secondary audience?) and generates a written spec.
→ Shows concretely what 'good prompting for interview-style extraction' looks like, in contrast to the named bad-prompting example ('just make it better'), and grounds the abstract bitter-lesson argument in an actual Claude Code session. - Four distinct HTML design directions (e.g. 'brutalist,' 'Tokyo fintech') are generated by Opus 4.7 for the same bill-splitting app spec and clicked through live, contrasted against how hard the same comparison would be to make from a Markdown description.
→ Demonstrates the HTML-spec-over-Markdown argument directly, and sets up the closing claim that HTML specs are not more token-inefficient overall because they cut iteration. - A small React to-do app has its state published into the DOM (data attributes for total/done/active items); every component has schemas, fixtures, and invariants tested by probes. A deliberately broken invariant (3+4 shown as 10) is shown failing on a human-readable dashboard, then failing the same way in a headless `bun verify` run, and finally diagnosed autonomously by Claude Code driving a browser via Playwright MCP — distinguishing a broken verification contract from a broken app.
→ Is the talk's central proof-of-concept for agent-native verification: it shows the same DOM contract supporting three independent verification surfaces (human, agent, headless CI) and an agent successfully self-diagnosing a planted defect using only that contract.
Questions addressed
- ✅ How do you get a comprehensive, accurate spec out of a user without requiring them to articulate everything upfront?
Prompt Claude to interview the user by explicitly invoking the ask-user-question tool, scoping the prompt to domains/areas of interest rather than a predefined outcome. - ✅ How do you review or communicate design/UI intent to (and from) an agent more efficiently than long prose?
Use dense, interactive HTML mockups/specs instead of long Markdown files, optionally paired with screenshots and later driven by tools like Playwright MCP. - ✅ Are HTML specs more token-inefficient than Markdown specs, given they cost more to generate?
No — the higher upfront generation cost is offset by fewer iteration cycles, so total token cost over the life of the spec tends to be lower. - ✅ How can the same verification be run by a human reviewer, by an agent, and headlessly in CI without maintaining three separate implementations?
Publish component state into the DOM as a single machine-readable contract (schema + fixtures + invariants); build a human-readable dashboard, an agent-driven browser flow, and a headless CLI runner that all read that same contract. - ✅ How should verification evidence be preserved and shared with colleagues at scale, rather than requiring live review of every change?
Record verification runs as video clips and store/share them (e.g. via S3) as auditable evidence — described as the Claude Code team's existing internal practice for front-end changes.
Gaps
- incompleteThe talk never addresses how HTML specs (or the design-direction mocks) stay synchronized with the app over its lifetime after the initial build — whether they, like the Markdown 'second system' the corpus elsewhere critiques, drift out of date as the code evolves, or whether they are explicitly meant to be discarded once a build is accepted.
Read next: extract-when-ai-writes-the-code-specifications-need-an-exit-strategy — its 'change brief' framing (specs as bounded, expiring artifacts, with only durable facts promoted into schemas/tests) directly addresses the lifecycle question this talk leaves open. - incompleteThe verification framework (schemas, fixtures, invariants, probes) is demonstrated by a single practitioner on two small demo apps. The talk doesn't address who authors and maintains the invariants across a real team, how disagreements about what counts as a 'known state' get resolved, or whether this becomes its own coordination/maintenance burden as the app and team scale.
Read next: Corpus material on organizational/coordination cost of agent-facing artifacts (e.g. ontology/registry maintenance costs raised for agent-native-design docs like extract-vault-ld) is the natural comparison. - incompleteSeveral central claims — that HTML specs net-reduce token cost, that Opus 4.7's vision model materially improves screenshot-based feedback, that the verification framework meaningfully improves reliability — are asserted from the presenter's own experience with a single demo repo, without any measurement, benchmark, or before/after comparison.
Read next: Compare against the corpus's recurring pattern of unreplicated single-author agentic-workflow anecdotes (e.g. extract-anatomy-of-an-agent-harness's own unquantified 'giving the model a way to verify its own work improves quality 2-3x' claim) for how thin this evidentiary base typically is across the corpus. - incompletePublishing full component state into the DOM via data attributes is shown as a development-time verification aid, but the talk never addresses whether this instrumentation ships to production, and if so what it exposes to end users' browsers (internal state, business logic surface) versus being stripped/gated for a dev-only build.
Read next: Corpus material on agent-native design's security/exposure tradeoffs, and general appsec practice on debug instrumentation reaching production. - incompleteThe talk gives a clear correction loop for design/visual intent (screenshots, HTML mocks, iterate) but no equivalent correction loop for the interview-derived requirements spec itself — what happens when Claude's interview-based extraction gets the requirements wrong is not addressed.
Read next: extract-claude-code-best-practices and other Claude Code workflow pieces in the corpus for how spec/plan review loops are typically closed.
Related documents
- When AI Writes the Code, Specifications Need an Exit Strategy
- Claude Code: Best practices for agentic coding
- The Anatomy of an Agent Harness
- Software Factories, Light and Dark
- Have your agent record video demos of its work with shot-scraper video
- [FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero
- 10 Things Developers Want from their Agentic IDEs in 2025
- Loop Engineering: Building Blocks, Adoption, and Impact
- mattpocock/skills v1.1: does /wayfinder beat grill-with-docs?
- How Claude Code Is Built