Claude Code 101

You type something to ChatGPT or Claude. It types something back. Sometimes it's exactly what you needed. Sometimes it's not, and you rephrase and try again.

That back-and-forth is something you do without thinking about it. But it's actually a skill. A valuable one. Describing what you want to an AI, reading the result, and giving feedback until it's right.

Here's an example you'll recognize. You ask Claude to write a product description:

Three rounds. Each one better. You didn't need special training to do this. You just described what you wanted and said what was wrong. That's exactly how Claude Code works too. The difference is just what the AI produces. Instead of text, it produces working software. But your skill — describing and refining — is the same.

Key takeaway

Think about the last time you asked ChatGPT or Claude to write something. That skill — describing what you want clearly — is exactly what Claude Code uses. Everything that follows builds on it.

What happens when you go beyond text

You asked ChatGPT for a simple webpage. Or a calculator. The AI gave you a block of code. You copied it. Pasted it into a file. Opened it in a browser. And then...

Why this happens

The AI wrote perfectly fine code. The problem is everything around it. A real website isn't one block of code. It's files that know about each other. A way to see the result live. A way to change one thing without breaking something else. A way to test. A way to put it on the internet.

When you copy-paste from a chat window, you are the one connecting all those pieces. That's the ceiling. Not the AI's quality. Your ability to be the glue between a code block and a working product.

The tools we explore in the next lessons remove that ceiling. You stop being the glue. The tools handle the connections. You handle the ideas.

Key takeaway

The jump from browser AI to editor AI is useful but limited. The AI suggests. You still decide, place, and verify everything yourself.

Before we go further into how, let's look at what. These are things built by regular people with ideas. Not developers. Not tech companies.

The pattern is always the same. Describe what you want. AI builds it. Give feedback. Adjust. Deploy. The tools handle the code. You handle the vision.

Key takeaway

The difference isn't the AI model. It's the scaffolding: CLAUDE.md for memory, skills for rules, MCPs for connections, plan mode for thinking first.

When you use Claude in the browser, you're having a conversation. The AI gives you text. That text might contain code, but it's still just text in a window. You copy it somewhere. You hope it works.

Building AI is fundamentally different. The AI doesn't give you text. It changes files on your computer. Creates new ones. Runs commands. Tests things. Deploys to the internet.

That's the fundamental shift. It's not about smarter AI. It's about AI that can do things, not just say things.

Key takeaway

A typical session: open your project, start Claude Code, describe what you want, review the plan, let Claude build, give feedback, save. The whole time you're describing what, Claude handles how.

"Project" sounds intimidating. Like six months of meetings and a Gantt chart. In our world, a project is just a folder on your computer with files in it. Those files are your website.

When you "build" something, you're adding files to this folder. When you "deploy," you're uploading the folder to the internet. When you "save your work," you're taking a snapshot you can go back to later.

The freelancer's client intake form? About 20 files in a folder. The AI created all of them from descriptions. The folder got uploaded to the internet. People visit the URL. That's the whole story.

Key takeaway

You don't need a six-month plan. Describe a landing page or tool. Claude builds it. You give feedback. You deploy. Done.

The biggest misconception: you need to describe everything perfectly upfront. Write the perfect prompt. Get the perfect result first try.

No. The best results come from starting rough and refining. Watch how a real project develops:

Four rounds. Each one builds on the last. You didn't need to plan all of this upfront. You discovered what you wanted by seeing the results. That's exactly how the Workshop course works later.

Key takeaway

The best results come from iteration, not from the perfect first prompt.

You've built something on your computer. It works in your browser. But only you can see it. "Deploying" means: putting it on the internet so anyone with the link can visit it.

The small agency's website roaster went from "works on my laptop" to "live on the internet" in about 5 minutes. They shared the link on LinkedIn. People started using it immediately. The whole thing is still just a folder of files, but now those files live on a server instead of a laptop.

Key takeaway

Deploy is not complicated. It's uploading a folder and getting a link.

Have you noticed that well-designed websites have consistent colors everywhere? The button is the same orange as the heading accent. The spacing between sections is always even. Nothing looks "off."

That's not because someone manually matched colors on every element. It's because of a system. You define your colors, fonts, and spacing once, in one place. Everything in the app references that one place.

The consultant changed their entire accent color from green to blue. One change. Ten seconds. Everything updated. This system gets set up at the very beginning and works silently from then on.

Key takeaway

Design tokens enforce consistency. Change your accent color once, it updates everywhere in 10 seconds.

Even if you only need English today, the way you handle text matters. If you write "Roast it" directly on a button in your code, and later want to add Dutch, you have to find every piece of text in every file. For a small app, that's dozens of strings. For a real app, hundreds.

The alternative: all your text lives in translation files. The button says "use the text called submitButton." The English file says that's "Roast it." A Dutch file would say "Roast het."

The restaurant's reservation page started English-only. Three months later they added Dutch and German. 20 minutes each. Because the system was there from day one.

Key takeaway

Even if you only need one language today, use the translation system. Future you will be grateful.

Here's something interesting about working with AI: after it builds something, you can ask it to review its own work.

You say something like: "Look at everything you just made. Does it work on a phone screen? Are the colors consistent? Did you miss anything?"

And it finds things. Every time. Not because the AI is bad at building. Because building is complex, and a fresh look catches what the first pass missed. Same reason you proofread an important email before sending it.

What the review typically catches

• A layout that looks fine on a laptop but overflows on a phone
• A color that was written directly instead of using the design system
• Text that was left in English instead of going through the translation file
• A form that accepts empty submissions without showing an error
• A button that looks clickable but doesn't actually do anything yet

The team lead's dashboard had a mobile problem that nobody noticed during building. The review caught it before they shared it with the team. The fix took 30 seconds.

Build, then review. Always. It's the simplest habit that makes the biggest difference in quality.

Key takeaway

Build, then review. Build, then review. The cheapest quality improvement you'll ever make.

Let's put it all together. None of this is complicated. Each piece is simple. Together they make a process.

That's the whole process. Repeat for each feature. There's no mysterious step where you suddenly need to understand programming.

Key takeaway

Describe → Build → Feedback → Adjust → Test → Deploy. Repeat for each feature. That's the whole process.

What you've seen in this course

• What people build with these tools (real examples, real results)
• How the process works (describe, build, feedback, adjust, deploy)
• Why building AI is different from chat AI (it does things, not just says things)
• What a project actually is (a folder of files)
• Why design tokens and translations matter (set up once, benefit forever)
• How reviewing catches problems early (build, then review)

The next courses are hands-on

You've seen what's possible. The next step is getting your hands on it.

Key takeaway

You've seen what's possible. Next: get your hands on it.