Video summary

How we Claude Code

Main summary

Key takeaways

Technology

Summary of the workshop: “How we Claude Code” (Anthropic)

Setup / workshop flow

  • Speaker (Arno, Applied AI team) runs a hands-on workshop with:
    • A QR code for credits and resources.
    • A companion repository to clone.
    • Three phases in the repo; the workshop primarily covers phase 1 during the session, with deeper details for later.

Core motivation: agents need new working patterns

  • Agents are becoming more capable because models are improving, enabling longer autonomous runs and more complex tasks.
  • This changes how people should work:
    • Longer runs can waste tokens if the agent is “wrong early.”
    • Therefore, Anthropic recommends front-loading verification/spec work rather than letting an agent wander.
  • Key idea: push human verification work “up front” into a richer artifact so the agent can verify alongside (or eventually without) humans.

Technology concept #1: “Bitter lesson” style guidance (don’t over-constrain)

  • The talk references Richard Sutton’s bitter lesson: don’t try to hardcode all constraints; instead, provide enough compute/data and let models improve.
  • Translated into prompt/agent practice:
    • Claude likely extracts requirements better than humans can fully articulate them upfront.
    • Reduce ambiguity and allow Claude to interview you.

Technology concept #2: Use HTML instead of Markdown for specs

  • Builds on Tariq’s blog idea: “The Unreasonable Effectiveness of HTML files.”
  • Why HTML:
    • More dense and more human-ergonomic than large Markdown specs.
    • Better for visual feedback (HTML can incorporate screenshots).
    • More scalable than Markdown as docs grow (e.g., Markdown becomes unreadable past ~200 lines).
  • The workshop covers planning and design exploration using HTML-based artifacts.

Technology concept #3: Good prompting = guided extraction via tools

  • “Bad prompting” examples:
    • “Just make it better.”
    • “Make no mistakes.”
  • “Good prompting” guidance:
    • Specify areas/domains you care about without over-specifying the final output.
    • Encourage Claude to iterate by asking questions.
    • Explicitly trigger workflows by instructing Claude to use specific tools—especially an “ask user question” tool referenced in the prompt.

Claudecode workflow features (modes/controls)

  • Demonstrates Claude’s operational modes and effort controls:
    • Auto mode is recommended as easiest/most effective.
    • Mentions fast mode for quicker iteration (higher cost) and an effort parameter (e.g., “high”).
  • Commands/flags shown conceptually as:
    • /auto, /fast, and /effort (and related controls)

Phase 1 demo: Bill-splitting app (interactive + design directions)

Requirement gathering via interview

  • Example app: bill splitting.
  • Claude interviews the user to fill in requirements:
    • Targets “friends” as the primary audience.
    • Uses the configured prompt/tooling so Claude generates a spec from the Q&A.

Plan → HTML spec → multiple design directions

  • Claude generates:
    • A plan (from gathered requirements).
    • Then multiple design directions rendered as HTML (e.g., different aesthetics).
  • Why HTML prototypes improve feedback:
    • You can click through and compare designs directly.
    • Claude can use screenshots/vision to interpret fine alignment/layout issues.
    • Opus 4.7’s vision capabilities are highlighted as especially good for extracting misalignment/problems from what the human observes.

Phase 3 / verification framework (agent-native verification)

Goal

  • Make verification native to the artifact itself so agents can verify end-to-end, with:
    • A human-readable dashboard
    • An agent-first (browser-driven) mode
    • A CI/headless CLI mode (e.g., “run bun verify”)

How verification is embedded in the app (React + DOM contracts)

  • Built around making component state visible to an agent:
    • React components publish state to the DOM (as “data” / emitted values).
    • Agents read the DOM “contract” rather than scraping internal React structures.
  • Verification artifacts include structured elements:
    • Schemas
    • Fixtures
    • Known states
    • Invariants (properties that must always hold)
    • Probes (tests beyond the “happy path”)

Storybook fixtures + Playwright MCP + testing library

  • Implementation details referenced:
    • Uses Storybook fixtures and a testing library.
    • Uses Playwright MCP so Claude can interact with the UI/browser for verification.
    • Produces verification steps that can be run, recorded, and replayed.

Evidence recording and sharing

  • Verification can generate recorded clips/videos as evidence.
  • Evidence is shareable/storable (e.g., S3) for colleague review of success/failure proof.

Live verification behavior showcased (two kinds of failures)

Example app: small React to-do app

  • The demo manipulates app state:
    • Add item, tick off, drop/clear finished items, etc.

Two failure demonstrations

  1. Deliberate wrong invariant

    • Example: sums mismatch (e.g., “3 + 4 does not equal 10”).
    • Tests may still pass in the demo scenario to illustrate the difference between:
      • test metrics
      • vs verification invariants/contracts the agent checks.

  2. Breaking the contract without breaking the UI

    • The app continues to function, but a DOM contract field is removed/changed.
    • Verification fails because the agent-readable contract is broken.

Claude diagnoses verification failures

  • Claude runs verification (agent-first) and uses Playwright MCP to determine why a check failed.
  • Example output referenced: “Schema got rejected; 4 + 3 does not equal 10.”

What’s in the repo (and how it maps to the workshop)

  • Repo path referenced (wording approximate): “CW workshops → Claude with Code workshops → how we Claude Code”.
  • Phase contents described:
    • Phase 1: bill-splitting prompt interview + HTML design directions.
    • Phase 2: (implied) additional HTML directions/design exploration workflows.
    • Phase 3: verification framework using a to-do React app:
      • human-readable dashboard
      • agent-driven verification (browser)
      • headless/CI verification (CLI)
  • Encouraged actions:
    • Open the repo.
    • Run examples and verify changes.
    • Experiment by breaking code/contract and observing results.

Key recommendations and “best practices” from the talk

  • Use Opus 4.7 (better vision model), especially for frontend/spec feedback loops.
  • Prefer Auto mode.
  • Use Fast mode when iterating on specs (even if it’s token-expensive), because:
    • HTML specs reduce downstream iteration costs.
    • A richer spec can prevent wasted agent runs over time.

Main speakers / sources

  • Speaker: Arno (Applied AI team architect at Anthropic)
  • Referenced concept/source: Richard Sutton (bitter lesson)
  • Referenced artifact/blog: Tariq — “The Unreasonable Effectiveness of HTML files”

Original video