How We Claude Code - V3 Reconstruction

This v3 page only covers workshop 1. Content slides are rebuilt as HTML. Demo-only screenshots are kept at the bottom. IMG_7403 and IMG_7404 are treated as extractable content because they expose the A/B/C verification-contract structure.

Workshop Frame

Title and Repo

Sources: IMG_7391, IMG_7392, IMG_7393

How We Claude Code was presented by Jason Schwartz from Anthropic.

The workshop repo slide points to:

https://cwc26.short.gy/workshops

Three Tools For Working With Long-Running Agents

Source: IMG_7394

Removing ambiguity

Make the agent interview you before it commits to anything.

Understanding and planning

Plans you can actually read: HTML, not Markdown.

Integrated verification

Build verification in from the start, not bolted on at the end.

Running Example

A Bill-Splitting App

Source: IMG_7395

The workshop uses one small product idea to show the three tools: a no-account bill-splitting app.

Bill	Value
Dinner	Friday
Aanya	$28.40
Marco	$31.10
Priya	$24.80
You	$28.40
Total	$112.70

1. Removing Ambiguity

Do Not Start By Asking The Agent To Build

Source: IMG_7396

Do not ask the agent to build it yet. Ask the agent to interview you about it.

A Small Prompt Change Gives A Much Better First Hour

Source: IMG_7397

Bad prompt

"Create a bill-splitting app for friends for me."

Why it is bad: under-specified. The agent picks a direction and you do not see it for an hour.

Good prompt

"I want to make this bill-splitting app into something people might want. I'm not sure what my target audience is - can you help me brainstorm different ways I could take this?"

Why it is better: the agent surfaces edge cases, audiences, and unknowns before any code is written.

2. Understanding And Planning

HTML Plans Are Easier To Read

Source: IMG_7398

HTML plans are easier to read and capture more of the model's thinking.

Markdown - yesterday

# Bill Splitter Plan

## Scope
- Split bills evenly
- Track who paid
- Export to Venmo

## Open questions
- Tip handling?
- Multi-currency?
- Auth?

HTML - today

Scope	Even split, tracking, Venmo
Open	Tip, currency, auth
Flow	Add bill -> Split -> Send

3. Integrated Verification

Three Principles

Source: IMG_7399

1. Build for it from the start

Think of verification while you build.

2. Modularize by verifiability

Group code by what is testable independently.

3. Verify across the stack

Use unit, integration, visual, and behavioral checks.

Verification Contract Demo

Sources: IMG_7403, IMG_7404

The demo asks: What if the app declared what "correct" means?

The screen labels this as the contract: state published on the page plus rules declared beside the code.

AThe component stamps its state onto the row

The rendered page becomes machine-readable. When the user ticks "oat milk", the app remembers it in memory as a variable such as todo.done = true. The contract adds one line that copies that variable onto the row as a label.

before  <li class="todo-item">
after   <li class="todo-item" data-verify-done="true">
        copied from todo.done

BYou ask Claude to write a verify spec for the component

The spec lists example states to render, called fixtures, and rules that must hold on the page, called invariants. Using the repo's existing specs as a template, Claude reads the component and writes the same shape.

The specific bug fails the invariant done-class-matches: the row's stamped state says done, but the class does not.

fixtures (states to render)
  - active
  - done
  - empty-text
  - long-text

invariants (rules to check)
  - done-class-matches
  - checkbox-state-matches
  - visible-text-never-empty

CPut together: state on the page, rules in a file, a harness that checks them

A makes the state machine-readable. B defines what good looks like upfront. The harness from the repo runs that check programmatically, the same way every time.

A  page says  data-verify-done = "true"
B  rule says  class must include "done"
   harness   class is "todo-item" -> FAIL

-> localhost:5199/verify

Closing Frame

The Work Has Shifted

Source: IMG_7408

The work is no longer writing the code. The work is setting up the conditions in which the code gets written well.

Demo Slides Kept As Screenshots

These are useful visual evidence, but not rebuilt as primary content here. IMG_7403 and IMG_7404 were extracted above because the A/B/C contract content is readable.

Demo slide IMG_7400 — IMG_7400 - live demo: todo app, editor, and browser workflow.

Demo slide IMG_7401 — IMG_7401 - live demo continuation.

Demo slide IMG_7403 — IMG_7403 - verification contract A/B content, extracted above.

Demo slide IMG_7404 — IMG_7404 - verification contract B/C content, extracted above.

Demo slide IMG_7405 — IMG_7405 - anatomy/system diagram from the demo.

Demo slide IMG_7406 — IMG_7406 - anatomy/system diagram duplicate/continuation.