No intro, no setup. Paste this prompt into Claude and watch a working game appear in seconds. You're building, not watching.

Build an HTML whack-a-mole game as a single web page. 9 holes in a 3x3 grid. Moles pop up randomly, I click to whack them. 30 second timer, score counter, and a "Play Again" button. Make it look fun, bright colors and a satisfying animation when I hit one. No external libraries.

That game came from one plain-English sentence. The skill you're learning isn't coding, it's describing what you want clearly. A few things to notice about how you asked:

• You said what it should do (whack moles, 30-second timer), not how to build it
• You set a feel ("make it fun, bright colors"), and Claude made the design calls
• If something's off, you don't fix code, you just say what to change in plain words

Make the moles pop up faster as the timer runs down, and add a sound when I miss.

Now something useful, and you'll build it conversationally, one prompt at a time, watching it grow. This is a simple maintenance tracker for ranch equipment. No spreadsheet, no setup, it all lives in one web page.

Step 1, the basics. Paste this:

BBuild me a simple ranch equipment maintenance tracker as a single HTML file. I want to add an asset by typing its name and a "next service due" date, and see all my assets in a list. Keep it clean and simple. No external libraries.

Step 2, make it remember. Add a few assets, then paste:

Make it so my assets are still here if I refresh or reopen the page. Save them in the browser so the list persists.

Now refresh the page, your assets are still there. That's the data living in the "back end" (here, your browser), separate from the page itself. Hold that thought for Module 3.

Step 3, add status pills. Paste:

For each asset, show a colored status pill based on the next service date: red "Overdue" if the date has passed, amber "Due Soon" if it's within 30 days, and green "OK" otherwise. Add a button to mark an asset serviced, which sets a new next-service date 3 months out.

• You built a working tool by describing it in plain English, three sentences, three layers
• Each step added to the same page, you grew it, you didn't start over
• Want more? Keep going: "let me delete an asset," "add a location column," "sort by soonest due"

You just felt an important distinction without us naming it. Compare the two things you built:

• The game kept its score in the page. Refresh, and it's gone, the data was fleeting.
• The tracker kept your assets in the browser's storage. Refresh, and they're still there, the data persists, separate from the page.

That's the core idea behind every real app: a front end (the page you see and click) and a back end (where the data actually lives). They're different things, connected together.

Your tracker's data lives in your browser, which means it's private to this one computer. To make it shared, so your whole team sees and updates the same list, the data would move to a database in the cloud (like a Google Sheet behind the scenes). That's exactly what we build in a later session.

For anything beyond a quick build, the best move is to let Claude ask questions first. Give it a deliberately vague request and watch it interview you before building.

Help me build a simple tracker for the projects I manage. Ask me questions first so you understand what I actually need before you build anything.

• Claude asks structured questions: what to track, what statuses matter, how you want to view it
• Answer as a group, the questions surface decisions you'd otherwise miss
• A good build starts by reducing ambiguity, not by guessing

• Describe outcomes, not steps. You said "make it fun" and "easy to scan", Claude made the calls.
• Revise in plain English. You change things by saying what's wrong, not by editing code.
• Let it interview you. For anything real, answer its questions before it builds.
• It builds, not just advises. You leave with working artifacts, not instructions.
• You stay in charge. Claude handles the how; you own the what and the whether.

This is a lot for one hour, and that's fine. Today is about seeing what's possible and getting hands-on. You'll get dedicated time to build something real with me, see the series card below.

Think about the trackers, reports, and manual processes in your work. Any of these could be a thing Claude builds for you:

• Open floor: what surprised you, what felt powerful, what would you build first?
• This week: try one build in Claude, something real from your own work
• Share your feedback:  Give Feedback

Today is one stop on an 8-session journey. Here's the whole arc, and where it's headed: