From Chat to Code Sprint
0 of 7 lessons done

A five-day sprint, Monday July 27 through Friday July 31, kicking off live on Monday at 2:00pm ET. On Monday you pick a small project of your own and write a spec sheet for it with Claude. The rest of the week you build it, one block a day, and on Friday you show it. Everything happens in the Claude desktop app.

Before kickoff

0/1

One thing to sort on your own before we start. Everything else happens together on the call.

Do this on your ownDownload the Claude desktop app
Two things before we start, and that's all. Everything else we do together on the call. These two are the only bits that can't be sorted live, because one is a download and one might need a card. If either won't cooperate, post in #claude-code-sprint and we'll get you through it before we start.

The Claude desktop app can do two things most people never turn on. It can work with folders on your computer, and it can build things that run. You'll turn both on with us at 2. All you need beforehand is the app itself, on a plan that can do the work.

Do this
  1. Download the Claude desktop app. Go to claude.ai/download and install it for your computer, Mac or Windows. The desktop app is what unlocks working with your own files. The browser version won't do this week.
  2. Sign in and make sure you're on a paid plan. Open the app, sign in, and check that you're on Claude Pro or higher. If you're on the free plan, upgrade now. Everything from here needs it.
A setup worth copying: put the Claude desktop app on one half of your screen and leave the other half free for whatever you're working in. You'll be going back and forth all week, and having a place to paste a confusing message the second you see it is the difference between feeling stuck and getting unstuck in thirty seconds.
You're done with this one when: the desktop app is installed and open on your computer, and you're signed in on Claude Pro or higher.
Watch out for: downloading from a copycat site. Make sure you're at claude.ai, the real app comes from Anthropic.

Monday, July 27: kickoff at 2:00pm ET

0/4

We start live at 2:00pm ET in the #claude-code-sprint channel in Slack. A Go Live card posts there when we start, and that card is the door. On the call we turn on code together, pick your project, and write your spec sheet. You leave Monday with code on and a one-page plan for your own project, which is what the whole rest of the week builds from.

Mon, Jul 27 · lesson 1 of 3Turn on code, together
We do this live, on the call. It's the one fiddly moment of the whole week, which is exactly why we're not making you do it alone. Follow along with us and you'll be through it in a few minutes. The steps are written out here so you can find them again later.

Two things happen here. You make a folder for your work, and you point Claude Code at it. Once it can see that folder it can build things that live on your computer, and you don't touch setup again for the rest of the week.

We'll do this together
  1. Make your project folder. Create one new, empty folder somewhere easy to find, like your Desktop. Call it my-project. Everything you build this week lives in it.
  2. Find Claude Code in the app. It sits alongside your regular chats rather than replacing them. If you can't spot it, ask Claude in the app "where do I find Claude Code in this app?" and follow what it tells you, because the layout does move between versions.
  3. Point it at my-project when it asks for a folder. Then ask it "what's in this folder?" The folder is empty and it should say so. What you're checking is that it's genuinely looking at your computer, not guessing.
You're done with this one when: Claude Code is pointed at your my-project folder and has answered a question about what's in it.
Watch out for: a button or label that doesn't match exactly what you see. Look for the closest thing; the app's wording moves between versions and the idea stays the same. If you're stuck, say so on the call, that's what it's for.
Mon, Jul 27 · lesson 2 of 3Pick your project

By Thursday night you'll have a working version one of something. The projects that get there share a shape: one page or one small tool, doing one job, with a result you can see on your screen. That isn't a limit on what you'll ever build, it's the size that fits in a week and still feels real when it works.

The one-sentence test: "It takes ___ and gives me ___." If you can fill in both blanks, you have something to start from. The Friday version needs to run in your browser on your own computer, with no accounts, no logins and no app store. It does not have to be finished or online, it has to be working. Anything beyond that isn't cut, it goes in After Friday.
What people in this sprint are actually building

These came out of the kickoff call, described by the people building them. A made-up list of examples tells you what's allowed. A real one tells you how wide the range is.

  • A time machine for writing. Someone who writes and researches a lot currently drafts in chat, exports to PDF, fiddles, saves over it, and wants version control instead of that loop.
  • A hybrid resume and portfolio, one page, to point recruiters and agencies at instead of sending a resume plus a pile of links. Live on the internet by Friday.
  • An in-store price tracker. Note what something costs in one shop, compare it against another, and stop paying more out of not knowing.
  • A grocery list built from your own recipes. Pick the meals, get the list, stop buying duplicates and throwing food away.
  • A cleanup tool, being built by someone who already does that job by hand every week.
"How is that different from just doing it in chat?" Someone asked exactly this on the kickoff call, about the cleanup tool, and it is the right question to ask. The short answer: chat does the job once, while you are sitting there asking. Code gives you a thing that exists, that you open, that works the same way every time, and that keeps working when you are not thinking about it. For the long answer, Getting more out of Claude takes one real task and runs it through chat, then co-work, then code, so you feel the difference instead of taking our word for it.
Or start from one of these shapes
  • A cleanup tool. Paste messy text in, click one button, get a clean version out that you can copy. Notes, transcripts, exports, anything you keep re-typing.
  • A tracker for something you actually count: water, workouts, job applications, pages read. One page, a button, a running tally that's still there tomorrow.
  • A calculator you keep redoing by hand: your freelance rate, a recipe scaled up for a crowd, splitting a trip's costs.
  • A checklist generator for a routine you repeat: packing for a trip, the weekly review, getting the house ready for guests.
  • A flashcard page built from your own notes, for anything you're trying to keep in your head.
  • A fill-in-the-blanks writer: answer three questions, get the email or update you send every week, in your wording.
  • A readable-table maker: paste an ugly export from some system at work, get a table a human wants to look at.
  • A picker: paste a list of anything, dinners, names, tasks, and let it choose or sort for you.
Blanking on ideas? Build the cleanup tool. It's the default for a reason: everyone has messy text somewhere, the shape is simple, and the result is something you'll genuinely reuse. Choosing it isn't settling, it's a solid first build.
Use whichever of these sounds like you
I'm spending this week building something small of my own, and I need to work out what to build. I'm not technical and this is my first time doing anything like this. Interview me one question at a time, and ask me at least five questions before you suggest anything. Ask about what I do over and over in a week, where my time actually goes, what I redo by hand, and what I complain about. Then give me three options I could start this week. Write each one as a single sentence in the form "it takes ___ and gives me ___". These can be real projects, not toys. For each one, tell me the part you think I can get working by Friday, and what would come after. The Friday version should run in my browser on my own computer, and should not need user accounts, logins or an app store. It does not have to be finished or online, it has to be working. Then tell me which of the three you would pick for me, and why. Once I've chosen, save it as idea.md in this folder: one paragraph, plain language, on what I'm building and who it's for.
I'm spending this week building something small of my own, and I already have an idea. Here's what I want to build: your idea, in a few sentences Ask me questions one at a time, at least four of them, until you understand what I actually want it to do and who it's for. Don't rewrite my idea until you've asked. Then draw a line through it for me. Don't shrink my idea. Keep the whole thing, and tell me which part of it you think I can get working by Friday, and what comes after Friday. The Friday version should run in my browser on my own computer, and should not need user accounts, logins or an app store. It does not have to be finished or online, it has to be working. Then write the version I'm building as a single sentence in the form "it takes ___ and gives me ___", and save it as idea.md in this folder: one paragraph, plain language, on what I'm building and who it's for.
Coming up: the next lesson turns your idea.md into a spec sheet, and that spec runs the rest of the week. So take five real minutes here, then move on. Picking isn't the hard part, and you'll sharpen it with Claude in the next lesson anyway.
You're done with this one when: idea.md is saved in your my-project folder, and you can say your one sentence out loud: one thing that goes in, one result you can see come out.
Watch out for: picking the impressive idea over the useful one. The tool you'll actually open next month beats the one that sounds good on the Friday call.
Mon, Jul 27 · lesson 3 of 3Write your spec sheet with Claude
We do this one together too. Spec-writing is the second half of the kickoff call. Everyone writes their own, at the same time, with Claude asking the questions. If you're doing it after the call, the steps are the same.

A spec sheet is one page that says what you're building before you build it. Professional builders start here, and this week you work the way they do: describe the thing, agree on what "done" looks like, then build to the description. It sounds like paperwork and it's the opposite. The spec is what lets you finish on Thursday instead of wandering all week.

Yours will have eight sections: What it is, Who it's for, What goes in and what comes out, The screen, Working by Friday, Build steps, After Friday, and Decisions. Claude writes all of it with you, by interviewing you.

Do this
  1. Open Claude Code in the desktop app, pointed at your my-project folder.
  2. Paste the prompt below. It reads the idea.md you saved in the last lesson, so there is nothing to fill in. Answer its questions honestly; plain answers beat impressive ones.
  3. Read spec.md when it's saved. Read it as a promise to yourself: is this the thing you want, and could you honestly check off every line of "Working by Friday" by looking at your screen?
  4. Say what's off, now. If a line reads wrong, this is the cheapest moment of the whole week to change your mind. Tell Claude and have it update the file.
Paste this into Claude Code
Read idea.md in this folder. That is what I'm building this week. Today we are only writing the plan, we are not building anything. Interview me one question at a time and don't write anything until you have asked at least five questions. Ask what goes in, what comes out, what I want on the screen, and what would make me happy on Friday. Then save a file called spec.md in this folder with these sections: - What it is: two sentences in plain language. - Who it's for: who opens it, and when. - What goes in, what comes out: the exact input and the exact result. - The screen: what's on the page and what I click. - Working by Friday: a numbered checklist of things I can watch happen on my screen. - Build steps: Tuesday, Wednesday and Thursday, each with what done looks like that day. - After Friday: everything from my idea that isn't week one. - Decisions: the choices we made, and what we deliberately left out. Write the spec for my whole idea, then mark where Friday lands. The Friday version runs in my browser on my own computer, needs no accounts or logins, and does not have to be finished or online. It has to be working. Write it so that tomorrow you can open spec.md and start building from it without asking me anything again.
Where this goes: tomorrow morning, Claude Code reads this file and builds from it. Every build day this week starts with "read spec.md," which means the better this page is, the easier your week gets.
You're done with this one when: spec.md is saved in your my-project folder, and every line of "Working by Friday" is something you could honestly check off by looking at your screen.
Watch out for: saying yes to every good idea Claude offers along the way. Good ideas are what the After Friday list is for. The spec you can finish beats the spec that has everything.
Mon, Jul 27 · after the callThe difference between chat, co-work and code
Do this after the 2pm call, in your own time. You just turned on code and wrote a spec. This is the session that explains what you actually did, and when to reach for each one.

There are three Claudes: one you think with (chat), one you delegate to (co-work, on your real files), and one you build with (code). Most people only ever meet the first. Knowing which to reach for is most of the difference between AI being a novelty and AI being useful.

The session takes one real task of your own and runs it through all three, so you feel the difference rather than read about it. It is nine short lessons and you can stop after the first three if that is all you want tonight.

Do this
  1. Open the session: Getting more out of Claude. It sits under Learn in your Curriculum, and it is open to you whether or not you finish the sprint.
  2. Bring the project you specced today. The session asks you to pick one real task; use the one you just wrote a spec for and it will land harder.
  3. Do at least "Meet the three Claudes" and the Chat lesson tonight. The rest keeps.
You're done with this one when: you can say out loud which of the three you'd use for your next task, and why.

Tuesday, July 28: build block one, the skeleton

0/1

First build block. Yesterday your project was a page of words. Today Claude Code reads that page and turns it into a real file on your computer, one you open in your browser and look at. It won't work yet, and it isn't supposed to. It will look like your tool.

Tue, Jul 28Build the skeleton

A skeleton is your tool with all its parts on the page and none of the wiring behind them. The box is where the box goes, the button says what the button will say, and clicking it does nothing yet. Builders start here because layout arguments are cheap on day one and expensive on day four, and because there's nothing like seeing the shape of your own idea on screen twenty minutes in.

Do this
  1. Open Claude Code in your my-project folder, where spec.md is waiting.
  2. Paste the prompt below. It tells Claude Code to build from your spec, so there's nothing to fill in.
  3. Open the file it makes. Claude Code will tell you the file's name and exactly how to open it. Do that now, not later.
  4. Hold it up against your spec. Read "What it is" and look at the page. Is this the shape of that thing?
  5. Ask for one change. Move something, rename a button, make the input bigger. Not because it needs it, but because asking for changes is the skill you're practicing all week, and the first one should be a cheap one.
First, which lane are you in?

Everyone here is building something different, and that sounds like it should mean everyone needs different instructions. It mostly doesn't. The work forks in exactly four places, and knowing which side you're on tells Claude Code what to build today.

  • Screen, or no screen. Is your tool a page you look at and click, or something that just runs and hands you a result? A tracker has a screen. A thing that tidies a folder every morning doesn't need one.
  • Just you, or someone else sees it. Does it live only on your computer, or does it need to be online for other people? A resume site is the second kind. Most first projects are the first kind, and that's the easier week.
  • Where your material comes from. Do you paste it in, does it read a file you keep, or does it have to go and fetch something from somewhere else? Fetching is the hardest of the three, so if that's you, get the pasted version working first.
  • Runs when you click, or runs on its own. Almost every week-one project runs when you click. If yours really wants to run on a schedule, build the click version this week and make it automatic later.
Not sure? Paste your four answers into Claude Code along with today's prompt, or just ask it: "read spec.md and tell me which of these four applies to my project, and what that means for what you build today." You are not picking a track you're stuck with. You're telling it what shape the thing is.
Paste this into Claude Code
Read spec.md in this folder. Build the skeleton of the tool it describes as a single file in this folder: every part visible and in the right place, with real labels, but the buttons don't have to do anything yet. Everything runs in my browser on my own computer, with no accounts and no logins. When it's ready, tell me the exact name of the file and exactly how to open it on my computer. Then list what's real and what's still just for show, so I know what tomorrow is for.
Coming up: tomorrow your real material goes in and the main job starts working. Tonight, if you want a head start, drop the real stuff into your folder or just know where it lives: the actual notes, the actual numbers, the actual list.
You're done with this one when: a file Claude Code made is open in your browser, it looks like the shape of the tool your spec describes, and you've asked for at least one change and seen it happen.
Watch out for: opening the file in an editor, seeing a wall of code, and deciding you're out of your depth. You aren't meant to read it. Look at the result in the browser and judge that instead.

Wednesday, July 29: build block two, the core works

0/1

Second build block, and the day your tool starts earning its name. The skeleton gets its one job wired up, and the material going through it is yours: your notes, your numbers, your list. This is also the day things break in interesting ways, which is why the fix-it patterns live here.

Wed, Jul 29Make the core work, on your real material

The core is the one job your tool exists to do. For a cleanup tool it's messy in, clean out. For a tracker it's the count going up and still being there tomorrow. Your spec's "What it is" names yours. Today that job has to actually happen, and it has to happen on your real material, because real material is the only input that tells you what's actually wrong.

Do this
  1. Get your real material ready. The actual text, the actual numbers, the actual list. Not a shortened version, not a tidy sample. If it lives in a file, put the file in your my-project folder.
  2. Paste the prompt below with your material where it asks for it.
  3. Try it the moment Claude Code says it's ready. Put the real thing in and look hard at what comes out.
  4. Say what's wrong, one change at a time. Then open it again and look. Three or four rounds is completely normal, and each round is you getting better at this, not the tool being bad.
Paste this into Claude Code
Read spec.md in this folder. Today the core job has to actually work. Here is my real material, exactly as it is: paste your real text, numbers, or list here, or name the file you put in the folder Make the main job work on exactly this. Never invent content and never silently drop anything you don't recognize; if something in my material is confusing, ask me instead of guessing. When it's working, tell me in one sentence what to try first.
If it does this, try this
Everyone's project is different and the ways they go wrong are the same. None of these mean you did something wrong, and all of them are five-minute fixes.
  • The file won't open, or you can't find it. You double-click and nothing happens, or your browser shows a blank page. Ask Claude Code "what is the full path of the file you just made, and how do I open it?" and use that exact path. Nine times out of ten the file is real and you're looking in the wrong folder.
  • Nothing happens when you click the button. Say exactly that: "the button does nothing when I click it. Check the page for errors and fix it." That one sentence is enough for it to find the problem.
  • The output looks nothing like what you wanted. Don't re-describe the whole tool. Paste a few lines of your real input, then exactly the output you wanted for those lines, and say "this in, this out." Showing it beats explaining it every time.
  • It works on the first try and falls apart on the second. That means it got built around one example's quirks. Paste the second one and say "this comes out wrong, make it handle both without breaking the first, and leave anything you don't recognize alone."
  • You asked for four changes at once and now the part that worked is broken. Go back to one change per message, opening and looking after each. To recover, say "put it back to how it was before my last request," then make the changes one at a time.
You're done with this one when: your tool has done its main job on your real material at least once, and what came out is close enough that you can name what's still off.
Watch out for: polishing how the tool looks before it does its job properly. Get the core right on your real material first. Friday is when you make it nicer.

Thursday, July 30: build block three, finish version one

0/1

Last build block, and the day the spec pays for itself. On Monday you wrote a checklist called "Working by Friday." Today you walk it, line by line, and finish version one of your own tool. Give this one a real block of time.

Thu, Jul 30Finish version one. The spec is the checklist

Finished doesn't mean perfect, and it doesn't mean you ran out of week. It means every line of the "Working by Friday" list you wrote Monday is either working on your screen or moved to After Friday on purpose. That's the whole difference between people who finish things and people who almost do: they decided in advance what done meant, and then they checked.

Do this
  1. Run the audit. Paste the prompt below and let Claude Code go through your own checklist and report honestly.
  2. Fix one line at a time, starting with the one that matters most, opening and looking after each fix. Yesterday's fix-it patterns all still apply.
  3. Move what won't make it to Later, on purpose. If a line isn't going to happen by tonight, tell Claude Code to move it to the After Friday list in spec.md. Cut scope out loud, not by quietly ignoring it. This is what professional builders do every week.
  4. Do a stranger test. Close everything, reopen your tool from scratch, and use it start to finish once, as if you'd never seen it. Whatever snags, that's your last fix of the day.
Paste this into Claude Code
Read spec.md and go through the "Working by Friday" checklist one line at a time. For each line, tell me plainly: works, partly works, or not built, and how you know. Don't fix anything yet. Then we'll go through them together, one at a time, starting with whichever unfinished line matters most for the tool doing its job. If we decide a line moves to Later, update spec.md so the list stays honest.
You're done with this one when: every line of "Working by Friday" is working or deliberately moved to After Friday, and you'd let someone watch you use your tool from start to finish.
Watch out for: the quiet drop, where a line just never comes up again. A line moved to After Friday on purpose is a finished decision. A line you stopped mentioning is an unfinished one, and it'll nag at you Friday.

Friday, July 31: change it three times, then show it

0/1

Last day, and two moves in it. You change your tool three times, so you feel how cheap changes are once a thing exists, and then you show it. Everyone specced and built their own thing this week, which makes the Friday posts genuinely worth reading.

Fri, Jul 31Change it three times, then show what you got working

Building it once is good. Changing it is where you actually get powerful, because real things are never right the first time, and the people who build a lot are just the people who are comfortable asking for the next version. Your After Friday list from the spec is sitting right there if you want ready-made changes.

Change it three times, from your After Friday list or these
  • "Add a second button that gives me the result in a different form, like a plain list I can paste into an email."
  • "Remember what I put in last time, so I don't lose it when I close the page."
  • "Make it handle this second kind of input too," with that input pasted in.
  • "Make it look less plain. Bigger type, more space, something I don't mind opening every day."

Ask, open it, look at the difference, ask again. That loop of describing and looking and adjusting is the entire rhythm of building with AI, and it doesn't change whether the thing is one page or a hundred.

Then show it
  1. Take two screenshots. One of your tool with your real material in it, and one of what it gave you back.
  2. Post them in #wins with the "What it is" line from your spec and one line about the part that was hardest. That line is worth more to the next person than the screenshots are.
  3. Name your next thing. One sentence about what you want to build after this. It doesn't have to be good, it has to exist.
Where the trail goes next: this week you built at sprint pace with the group. When you want to keep building, at your own pace, on whatever you want, that's what From Chat to Code is for, and it's also where the terminal version of Claude Code lives if you decide you want it. Nothing you built this week needs it.
You're done when: you've changed your tool at least three times, you've posted what you got working in #wins, and you've named the next thing you want to build.

You went from chat to code.

Five days ago your tool was one sentence. Now it's specced, built, changed three times, and shown. When you want to build the next thing, at your own pace, From Chat to Code is where that lives.