You have built with it for two days. Today you stop using it like a beginner. It starts truly working. For you.
Not answering your questions. Reading your files, writing your code, running it, shipping it. Your job: point it at the right target.
You first
What do you think Claude Code can actually do?
▸ click to reveal after they answer
Read every file in your project. Write new code. Run it. Fix what breaks. Put it on the internet. All from one instruction from you.
What it can do, all of it
Four moves. That's the whole toolkit.
Reads your whole project first
Every screen, every note, before it changes a thing.
Writes real code
Actual files, saved into your project. Nothing to paste.
Runs it and watches
Starts the app, reads the real error, tries again.
Ships it to a real URL
The one your family can open tonight.
The one that gets the biggest reaction
It puts your app on the internet. Today.
From your laptop to a real URL your family can open on their phone. No separate "deploy team" required. You already did this once, on Day 1.
Deploy this to the public URL and give me the link.
Live demo, no rehearsal
Wireframe in. Working screen out.
And when it goes wrong, which it will, you will see exactly what I say to fix it. That sentence is today's real lesson.
Demo · step 1 of 5 · wireframe in
First, I hand it the wireframe.
LIVE DEMO · no rehearsal
"Build the screen this wireframe represents."
One real paper wireframe, photographed live, no code talk yet.
Just watch
Have your own Day 2 wireframe on your desk.
Keep Claude Code closed for now.
Just watch what "the goal" sounds like out loud.
You'll do this exact move in Exercise 1.
Demo · step 2 of 5 · watch it plan
Watch it make a plan before it writes a line.
LIVE DEMO · no rehearsal
"Show me your plan before you touch any files."
A real plan, read out loud, before a single line gets written.
Just watch
Watch for the list of files, not the code.
Notice it explains itself before acting.
This is the moment you'd stop it if it were wrong.
Keep watching, laptops still closed.
Demo · step 3 of 5 · watch it build
Then it actually builds it.
LIVE DEMO · no rehearsal
"Now build it."
Live build, no narration, under two minutes on the clock.
Just watch
Watch the browser tab, not the terminal.
Notice: nobody wrote HTML by hand.
This is what your Exercise 2 will feel like.
One more beat before laptops open.
Demo · step 4 of 5 · watch it fail
And then, on schedule, something breaks.
LIVE DEMO · no rehearsal
Something breaks. On purpose. No panic-fix.
A real error, left on screen a few seconds, before anyone touches it.
You do next
This is the moment you'll hit too, today.
Notice: broken is normal, not a failure.
Start thinking in expected vs. actual.
Laptops open at the end of this beat.
Demo · step 5 of 5 · gap-statement fix
I fix it with one precise sentence.
LIVE DEMO · no rehearsal
"I expected X. It does Y. Fix it."
One precise sentence, live, no do over. Watch the fix land in one pass.
You do now
Open Claude Code next to your own product.
Find your own gap, right now.
You mirror this exact move in Exercise 1.
Laptops open, screens on. Go.
The skill inside that demo has a name
“I expected X. It does Y.” The gap loop.
Describe
Run
Test
State the gap
The one sentence that separates people who ship from people who stall.
Site walkthrough · Anthropic wrote this down too
There's an official guide for the exact thing you just learned.
code.claude.com/docs/en/best-practices
"Give Claude a way to verify its work"
Claude stops when the work looks done. Give it a test, a build, or a screenshot to check against, and it keeps working until the check actually passes.
"Course-correct early and often"
The same rule as your gap statement: catch it fast, say it precisely, don't let five vague corrections pile up.
Real, official site: code.claude.com/docs. Written by the team that builds the tool.
Why this works
Precision works on AI for the same reason it works on people.
Tell a friend "clean your side of the room" and you get a shrug and a shove of stuff under the bed. Tell them "shoes in the closet, cups in the kitchen" and it actually happens. Claude Code is no different: vague instructions get vague results.
You first
Has a vague instruction from a teacher or a parent ever gone badly for you?
▸ click to reveal after they answer
"Clean your room" and "fix the bug" fail for the exact same reason. The other side has to guess what you actually meant, and guesses are usually wrong.
Bug type: layout
The button is in the wrong place. Which report gets it fixed?
The stall
the button looks weird, move it
The ship
I expected: the Save button sits directly under the note box on mobile. It does: on screens under 400px wide it floats to the top-right corner. Fix the mobile layout only, keep desktop the same.
Bug type: logic
The app does the wrong thing. Which report gets it fixed?
The stall
the counter is broken lol
The ship
I expected: clicking +1 twice shows 2. It does: two clicks shows 3, a third click shows 5. The count is doubling somewhere. Find where and fix only that.
Bug type: data
The information itself is wrong. Which report gets it fixed?
The stall
my list keeps disappearing help
The ship
I expected: notes I save stay in the list after I refresh the page. It does: the list is empty every reload, with no error shown. The data isn't actually being stored. Find where it's getting lost.
Section 3
Before you break anything on purpose, save it.
The gap loop makes you fast. This habit makes you fearless.
You first
Who has broken something on a computer and panicked?
▸ click to reveal after they answer
Every hand, every time. Real engineers don't avoid breaking things. They just always have a way back.
Checkpoints
Commit before you experiment.
A commit is a save point for your whole project. Make one right before anything risky, and "I broke it" stops being scary.
A cautionary, true-ish tale
The team that lost four hours to one "yolo."
True story, roughly: a team once said "redo the whole homepage, get creative," zero checkpoint behind them. It got very creative. Their actual homepage was gone, replaced by something that can only be described as a fever dream, and there was nothing to roll back to. Four hours later: rebuilt from memory and mild tears. Commit first. Every single time.
How it actually works
Save, break, roll back. Three moves.
Checkpoint saved
Commit
Try the risky thing
Experiment
It goes wrong
Break
Hate it? Roll back. You're exactly where you were, no damage done.
One more judgment call
Re-prompt in the same chat, or start fresh?
Bug's still there. What now?
Same chat
Fixing or refining what's already there. It remembers the context.
Fresh conversation
The chat's gone in circles, or you're starting something genuinely new.
A cluttered conversation makes worse guesses.
Same bug, five tries in
One of these is the actual fix.
The stall
"no still wrong, try again" ... "still not it" ... "ugh, try again" ... "closer?? try again"
The shipFresh conversation. Here's the current state of my app and the one gap I need closed: [gap statement]. Clean slate, one clear ask.
Section 4
Now you run the loop. On your product.
Three timed rounds, back to back. Same rules as the demo: describe precisely, watch it work, describe again.
Boot up · 30 seconds
Same team account. Builder drives. Project open from yesterday.
Log back in with the same team account card. Builder has the keyboard. Open your project from yesterday, the one you already shipped once. Hands up when your team is in.
Exercise 1 · setupFOLLOW ALONG · laptops open
You can't close a gap you haven't named.
Before you touch Claude Code, find the single biggest difference between your Day 2 wireframe and what's actually on screen right now. Destination: THE WALL, you'll read it out loud.
Exercise 1 · do it nowFOLLOW ALONG · laptops open
Gap hunt
5:00 on the clock
1Open your product next to your Day-2 wireframe.
2Find the biggest gap between them.
3Write it as a precise gap statement: expected / does / matters because.
5:00
Then: post it to THE WALL
Exercise 1 · debriefFOLLOW ALONG · laptops open
Read two gap statements off the wall.
Listen for: did they name the exact expected behavior, or just point and say "this part"? Precision is the whole skill. Rewrite any vague one together, right now.
Exercise 2 · setupFOLLOW ALONG · laptops open
Take that gap statement into Claude Code.
This is the loop from the live demo, except it's your product this time, and nobody is watching you fail. Except your teammates, who have also failed at things.
Exercise 2 · do it nowFOLLOW ALONG · laptops open
Close the gap
5:00 on the clock
1Give Claude Code your gap statement. Watch it work.
2Not right yet? New gap statement. Precision, not frustration.
3Gap closed? Grab the NEXT one. The loop never stops.
5:00
Then: screenshot to TEAM FOLDER
Exercise 2 · debriefFOLLOW ALONG · laptops open
Show a neighbor your before and after.
Listen for: how many gap statements did it take? One precise sentence beats five frustrated ones, every time. If someone needed five, help them find the sentence that would have taken one.
Exercise 3 · setupFOLLOW ALONG · laptops open
You're about to break your own product. On purpose.
Commit first, so there is nothing to lose. Then this stops being scary and starts being genuinely fun.
Exercise 3 · do it nowFOLLOW ALONG · laptops open
Break it on purpose
5:00 on the clock
1Save a version: commit before you experiment.
2Now tell Claude Code to do something reckless to your app. Enjoy the chaos.
3Roll back to your checkpoint. Everything is fine. Fear of breaking things: gone.
5:00
Post your chaos to CLASS CHANNEL
Exercise 3 · debriefFOLLOW ALONG · laptops open
Who has the funniest thing it broke?
Show of hands, one out-loud story. The real lesson: you rolled back and everything is fine. That fear is now permanently smaller.
Copy this prompt · run it now
The gap statement, as a prompt
I expected [X exactly]. It currently does [Y exactly]. The difference matters because [user impact]. Fix the gap without changing anything else that works.
When you get stuck
Three ways teams get stuck, and the fix
It keeps "fixing" the wrong thing
Your gap statement was too vague. Add the exact expected behavior AND the exact actual behavior, nothing else.
It fixed the bug but broke something else
Add one line to every gap statement: "without changing anything else that works."
Five re-prompts, no progress
Stop. Start a fresh conversation, restate the current state and the ONE gap. Clean slate.
Checkpoint
One wireframe gap closed, live, before the break.
Every team should be able to point at one thing that's better right now than it was 90 minutes ago.
“Launch fast.” Today you proved it.
Go deeper · on your own time
Three places to keep exploring this
Claude Code best practices
The official written guide to everything in today's session.
code.claude.com/docs/en/best-practices
Claude Code overview
The full docs home: every surface, every feature.
code.claude.com/docs/en/overview
"How we Claude Code"
For the ambitious: Anthropic's own engineers, day to day.
youtube.com/@claude
What's next today
Next: Design with AI. Then you ship v1 to strangers.
11:00, three style directions and the design-to-code move. Then at 13:15 v1 goes live at your public URL, and at 14:30 five actual strangers touch it while you watch in silence. The gap loop you just learned is what turns their confusion into your fix list.