[an error occurred while processing this directive]
MODULE 3

WTF Is Happening

Learn the vocabulary so you're not lost.

Spoons: Low
Time: 20–35 min
Done when: you can recognize the key terms and explain what Claude is doing in plain language.

By now, you've had a conversation with Claude. You saw something get built. Maybe you even clicked on it and it worked.

But somewhere in that conversation, Claude probably said something that made you think: "I have no idea what that means but I'm just going to nod and hope it works out."

This module fixes that.

You\'re not going to learn to code. You\'re going to learn just enough vocabulary to understand what Claude is talking about - so you can stay in the driver's seat.

The Goal Here

Think of this like learning enough Spanish to navigate a restaurant in Mexico City. You don't need to be fluent. You need to know "agua," "bano," and "la cuenta, por favor."

Same thing here. You need maybe 15 words. That\'s it. After this module, when Claude says "I\'ll commit this to the repo and we can deploy it," you'll know what that means without having to do any of it yourself.

What you're NOT doing: You are not learning to code. You are not memorizing syntax. You are not becoming a developer. You are learning to understand the conversation so you can give better directions. That\'s it. If anyone asks, you're "technically literate" - you speak the language, you just have someone else do the typing.

The Big Picture

Before we get into vocabulary, here\'s what\'s actually happening when you build an app with AI. The whole thing, simplified.

Stage 1: Conversation
You talk to Claude. Claude writes code. You see previews (artifacts). You give feedback. Claude adjusts. Repeat until it works.
This is where you've been living. Module 2 stuff.

Stage 2: Saving
Once something works, you save it somewhere permanent. Not just in the chat - in a place where the code actually lives and won't disappear. This is where GitHub comes in.
You haven't done this yet. Module 5 stuff.

Stage 3: Deploying
You take the saved code and put it on the internet so other people can use it. It gets a real URL. It's "live." This is deployment.
Also Module 5 stuff.

Where are you right now? If you're following this workbook in order, you're in Stage 1. You\'re having conversations and seeing things come to life in artifacts. The code exists, but only inside your Claude chat. It\'s like a Word document you haven\'t saved yet - close the tab and it might be gone. That\'s fine for now. We'll save it properly later.

The Words You'll Actually Hear

Here are the terms Claude will use. For each one, I'll give you the technical word, the human translation, and why you might hear it.

Repository (Repo) = A folder for your project that lives in the cloud

Think Google Drive, but specifically for code. When Claude says "let\'s create a repo," it means "let\'s make a place to save this project." GitHub is where repos live.

Commit = Saving a snapshot of your work

Like hitting "Save" but with a note about what you changed. Each commit is a checkpoint you can go back to. When Claude says "I\'ll commit this," it means "I\'ll save this version."

Push = Uploading your saved work to the cloud

After you commit (save locally), you push (upload to GitHub). It's a two-step save. Commit = save on your computer. Push = backup to the cloud.

Pull = Downloading the latest version from the cloud

The opposite of push. If someone else made changes (or you worked from a different computer), you pull to get the latest version.

Branch = A parallel universe for experiments

Lets you try things without breaking what already works. The "main" branch is the real version. Other branches are experiments. When they work, you merge them back.

Deploy = Put it on the internet for real

Moving your app from "only I can see this" to "anyone with the link can use it." When Claude says "ready to deploy," it means "ready to go live."

Frontend = The part users see and click on

Buttons, colors, layout, text - anything visible. When Claude says "I\'ll update the frontend," it means "I\'ll change how it looks or behaves for the user."

Backend = The invisible machinery behind the scenes

Where data gets processed, stored, and retrieved. Users never see it. When Claude mentions "backend," think "the engine room."

Database = Where information gets remembered

If your app needs to remember anything (user accounts, saved items, history), that info lives in a database. It's a spreadsheet on steroids.

API = How apps talk to each other

When your app needs info from another service (weather data, payment processing, AI), it uses an API. Think of it as a waiter taking orders between your app and someone else's.

Localhost = Your computer running a test version of your app

When Claude says "running on localhost," it means the app is running on your computer in a test environment, not on the real internet. By default, only you (on that computer) can see it. If you're on a different device (like your phone), you can\'t access localhost until the app is deployed to the real internet.

Bug = Something broken or not working right

Not a literal insect. Just something that doesn\'t work as expected. "There\'s a bug" = "something's wrong."

Debug = Finding and fixing what's broken

The process of hunting down bugs. When Claude says "let me debug this," it means "let me figure out what's wrong and fix it."

Dependencies = Code your app borrows from other people

Instead of writing everything from scratch, apps use pre-built pieces. These are dependencies. When Claude says "installing dependencies," it's grabbing those pre-built pieces.

Environment = The conditions where your app runs

Development environment = your computer for testing. Production environment = the real internet for real users. Different environments, same app.

Terminal / Command Line = Typing instructions instead of clicking buttons

The black screen with text that hackers use in movies. It's just another way to control your computer - typing instead of clicking. Claude Code runs here.

What You Don't Need to Know

Just as important as what TO know is what you can safely ignore. Here's your permission slip to not care about these things:

You don't need to know: How the code actually works
Claude handles that. You just need to know if it DOES work (test it) and if it does what you WANT (give feedback).

You don't need to know: What programming language is being used
JavaScript, Python, TypeScript - doesn\'t matter to you. Claude picks what works. You don\'t need to have an opinion.

You don't need to know: How to read code
When Claude shows you code, scroll past it. Look for the preview. Look for the question it\'s asking you. The code is Claude\'s problem.

You don't need to know: Git commands
Git is the tool that handles repos, commits, pushes, and pulls. You don't need to memorize commands. Just understand the concepts. Claude does the typing.

You don't need to know: How servers work
When we deploy, we'll use services that handle all that. You click buttons. Servers appear. Magic.

The vibe: You\'re the director, not the cinematographer. You don\'t need to know how the camera works to say "that shot should be wider." Same here. Know enough to give good direction. Let Claude handle the technical execution.

Scripts for When Claude Gets Technical

Sometimes Claude will get deep in the weeds. Here's what to say to stay in control without pretending you understand.

When Claude uses a word you don't know:

Wait - what does [word] mean? Explain it like I've never coded before.

When there's too much code on screen:

I don't need to see the code. Just show me the result and tell me if it works.

When it asks you to make a technical decision:

I don't have enough context to decide that. What would you recommend for someone who just wants it to work?

When it mentions multiple options (frameworks, libraries, etc.):

Pick whichever one is simplest and most beginner-friendly. I trust your judgment.

When something breaks and you don't know why:

Something\'s not working. I don\'t know how to read the error. Can you figure out what's wrong and fix it?

When you're completely lost:

I need you to take a step back and explain what we\'re doing right now and why, in plain English. I\'m lost.

Quick Reference Card

Tear this page out (or screenshot it). Keep it handy during your Claude conversations.

Claude Says It Means
"Let me commit this" I'm saving this version
"I'll push to the repo" I'm uploading to GitHub
"Running on localhost" It's running on your computer only
"Ready to deploy" Ready to put on the real internet
"There's a bug" Something's broken
"Let me debug" Let me find and fix the problem
"Installing dependencies" Grabbing pre-built code we need
"Frontend change" Changing how it looks
"Backend change" Changing how it works behind the scenes
"Check the database" Look at the stored information
"API call" Talking to another service
"In production" On the real, live internet

Parking Lot

Terms or concepts that came up that you want to look up later, or questions you still have. Don't let them derail you - just write them down and keep moving.

Words I still don't understand: _______________________________________________

Things I want to learn more about (later, not now): _______________________________________________

Module 3 Complete

You now speak enough tech to follow the conversation.

You know what repos, commits, and deployments are.

You know what to ignore and what to ask about.

You\'re not a developer. You\'re something better: a director who speaks the language.

What\'s next - Module 4: Module 4 is called "The Feedback Loop" and it\'s about iteration - how to test what Claude builds, how to articulate what\'s wrong when something isn\'t right, and how to keep improving without falling into a perfectionism spiral. You'll learn to give feedback that actually helps.

You're doing great. Keep going.

[an error occurred while processing this directive]