Start coding the right way.

Install the five tools every coder needs

You need a small set of tools before you write a line of code. These instructions are written for a Mac (the most common setup); Windows notes are called out where they differ. Install them in this order.

1 · The terminal — how it works

The terminal is a window where you type commands instead of clicking. It looks intimidating at first, but it's just a direct way to tell your computer exactly what to do. On a Mac it's already installed — press ⌘ + Space, type Terminal, and hit Enter. On Windows, install Windows Terminal and use it with WSL (see the box below).

Every command in this guide is shown in a dark box like this one. The $ is just the prompt — the computer telling you it's ready. Don't type the $; type (or paste) everything after it, then press Enter to run it.

$ pwd            # "print working directory" — shows where you are
/Users/you

• Paste a copied command with ⌘ + V, then press Enter.
• Commands are picky — exact spelling, spaces, and capital letters all matter.
• If a command hangs or runs away, press Ctrl + C to stop it.
• If a command finishes with no error message, it worked. Silence is good news.

Three commands you'll use constantly to move around your files:

$ pwd            # where am I right now?
$ ls             # list the files & folders here
$ cd ~/Dev       # change into a folder (here: ~/Dev)

2 · Homebrew (Mac package manager)

Homebrew installs other tools for you with one command each. Paste this into your terminal and press Enter:

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Follow the prompts. When it finishes, it may print two lines starting with echo — run those so your terminal can find brew.

3 · Git (version control)

Git is the tool that saves the history of your code so you never lose work. Install it:

$ brew install git

4 · A code editor — VS Code

Visual Studio Code is the free editor most people start with. Download it, drag it to Applications, then open it once and press ⌘ + Shift + P → type "shell command" → choose "Install 'code' command in PATH". Now you can open any folder from the terminal by typing code .

5 · Python & Node

Node is needed to install Claude Code (next step) and lots of web tools; Python is a beginner-friendly language you'll likely write soon. Install both now:

$ brew install python node

6 · Claude Code — your AI coding partner (install this in the terminal)

This is the big one. Claude Code is Claude that lives in your terminal — it reads your files, runs commands, and builds with you. Install it with Node, sign in with your Claude subscription, then confirm it's there:

$ npm install -g @anthropic-ai/claude-code   # installs the `claude` command
$ claude --version                          # confirms it installed
$ claude                                     # first run walks you through signing in

If claude --version prints a number, you're set. Full install docs: docs.claude.com/en/docs/claude-code/setup.

One home for everything: ~/Dev

Every project you ever build lives inside one folder called Dev in your home directory. The ~ symbol is shorthand for "my home folder." Keeping one home for your code means you never hunt around your computer wondering where something went.

$ mkdir -p ~/Dev
$ cd ~/Dev

Inside ~/Dev, each project gets its own folder. One folder = one project = one Git repository = (usually) one GitHub repo. That's the whole rule.

Dev/
├── hello-world/        # your first project
│   ├── index.html
│   └── README.md
├── weather-app/        # a later project
└── portfolio-site/     # another one

Make your first project folder now — you'll connect it to GitHub in Part 04:

$ cd ~/Dev
$ mkdir hello-world
$ cd hello-world
$ code .            # opens this folder in VS Code

Git in plain English

Git has its own words. You'll see them everywhere, so here's what each one actually means. Don't memorize this — just read it once and come back when a word confuses you.

repository

A project that Git is tracking — its code plus the full history of every change. Everyone calls it a "repo."

commit

A saved snapshot of your project at one moment, with a short message describing what changed. Think of it as a checkpoint in a video game.

working directory

The actual files on your computer right now, before you've saved a snapshot.

staging area

A holding zone where you pick which changes go into your next commit. You add files to it with git add.

branch

A separate line of work. You make changes on a branch so your main code stays safe until you're happy. The default branch is called main.

remote

A copy of your repo that lives somewhere else — usually on GitHub. Your backup in the cloud.

origin

The default nickname for your main remote (your GitHub copy). "Push to origin" = send to GitHub.

clone

Download a full copy of a repo from GitHub onto your computer.

push

Send your commits up to GitHub.

pull

Bring down changes from GitHub into your local copy.

merge

Combine the work from one branch into another.

conflict

When two changes touch the same line and Git can't decide which wins — it asks you to choose. Normal, not scary.

pull request (PR)

On GitHub: a proposal to merge one branch into another, so changes can be reviewed before they land.

.gitignore

A file listing things Git should never track — secrets, junk, huge files. Your safety net against leaking passwords.

status / diff / log

status = what's changed; diff = the exact line-by-line changes; log = the history of commits.

Create a free GitHub account & connect your project

GitHub is where your code lives online — a free backup and a portfolio employers can see. Let's create the account and push your first project to it.

Step 1 — Create the account

1. Go to github.com/signup and sign up. Pick a username you'd be happy putting on a résumé — alex-rivera beats xX_gamer_Xx.
2. Verify your email.
3. Turn on two-factor authentication when prompted — it protects your account. How-to here.

Step 2 — Tell Git who you are

Do this once on your computer so every commit is signed with your name:

$ git config --global user.name  "Your Name"
$ git config --global user.email "you@example.com"   # same email as GitHub

Step 3 — Install the GitHub CLI & log in

The GitHub CLI is the easiest way to connect your terminal to GitHub — no fiddly key setup.

$ brew install gh
$ gh auth login      # choose: GitHub.com → HTTPS → login with browser

Step 4 — Turn your folder into a repo & push it

From inside your project folder, these commands create the repo, make your first commit, and publish it to GitHub in one flow:

$ git init                         # start tracking this folder
$ git add .                        # stage everything
$ git commit -m "First commit"     # save the first snapshot
$ gh repo create hello-world --source=. --private --push

That last line creates a private repo named hello-world on GitHub and pushes your code to it. Open it in your browser:

$ gh repo view --web

Create a free Supabase account

You'll use it in Part 07 to give Ada a memory. Setting it up now takes two minutes.

1. Go to supabase.com/dashboard and sign in with your GitHub account (the button is right there).
2. Click New project. Give it a name like my-memory, and let it generate a database password — copy that password somewhere safe (a password manager, not a text file in your project).
3. Pick the region closest to you and click Create new project. It takes a minute or two to spin up.
4. That's it — once it says the project is ready, your database is live. You don't need to copy anything down right now; in Part 07 you'll connect Ada to it and grab the one code it needs.

Create a free Cloudflare account

You don't need it today, but setting up the account now means it's ready when you build something worth sharing.

1. Sign up at dash.cloudflare.com/sign-up and verify your email.
2. Install Wrangler, Cloudflare's command-line tool, and log in:

$ npm install -g wrangler
$ wrangler login     # opens your browser to approve

When you're ready to publish your first site, the docs walk you through it: Cloudflare Pages — Get started. For now, having the account and Wrangler installed is enough.

The one-time setup — copy, paste, done

This is the part that makes everything else automatic. In a few paste-and-run commands you'll connect Ada to your Supabase database and your Cloudflare account, then drop in one settings file that bakes all the good habits into Ada. You do this once. After that, you just talk to Ada and it handles the database work, the backups, and the safety for you.

Before you paste: grab two values from Supabase

Ada needs two pieces of info to reach your database. Both come from your Supabase project (Part 05):

• Project ref — open Project Settings → General and copy the Reference ID (a short code like abcdefghijklmnop).
• Access token — go to supabase.com/dashboard/account/tokens, click Generate new token, name it reggie, and copy it. You only see it once, so copy it now.

Step 1 — Connect Ada's tools

Replace the two CAPITALIZED placeholders with your values, then paste each line and press Enter:

# 1) Supabase — swap in YOUR_TOKEN and YOUR_PROJECT_REF
$ claude mcp add supabase --env SUPABASE_ACCESS_TOKEN=YOUR_TOKEN -- npx -y @supabase/mcp-server-supabase@latest --project-ref=YOUR_PROJECT_REF

# 2) Cloudflare — no token needed
$ claude mcp add --transport sse cloudflare https://bindings.mcp.cloudflare.com/sse

Step 2 — Install your habits (one paste)

This single command writes Ada's settings file, ~/Dev/CLAUDE.md. It's the brain of your setup: it tells Ada to keep your memory and to do all the good habits for you automatically. Select the whole block below — from cat to EOF — paste it, and press Enter.

$ cat > ~/Dev/CLAUDE.md <<'EOF'
# My workspace — Ada reads this at the start of every session.

You are **Ada**, my coding mentor. I'm new to programming, so keep things
simple, work in small steps, show me (don't just tell me), and correct my
mistakes kindly.

## How my projects work
- Every project lives in its own folder under ~/Dev/. Use full paths.
- One project = one folder = one GitHub repo.

## My memory — you keep it for me, using your Supabase tools
- At the START of every session, read the most recent rows from my `decisions`
  table so you know what we've already decided.
- If the `decisions` table doesn't exist yet, create it with columns: id (uuid
  primary key default gen_random_uuid()), created_at (timestamptz default now()),
  project (text), topic (text), decision (text), rationale (text).
- Whenever we make a real decision — a choice, a tradeoff, a "we'll do X not Y" —
  save it to the `decisions` table right away, without being asked: the topic,
  what we decided, and why.

## Protect my code — do these FOR me automatically. I should never have to ask.
- COMMIT OFTEN: after we finish any working change, make a git commit with a
  clear message. Don't wait for me to ask.
- PUSH AT THE END: when we wrap up, push my commits to GitHub so my work is
  backed up in the cloud.
- NEVER LEAK SECRETS: make sure every project has a .gitignore excluding .env,
  .env.*, node_modules/, and .DS_Store. Create it if missing. Never put
  passwords or keys directly in code.
- USE DOPPLER FOR REAL KEYS: when a project needs its own API keys, set it up
  with Doppler (doppler setup) and run it with `doppler run` so keys are
  injected at runtime and never live in a file. Ask me to paste the values.
- STAY FREE + CAP SPEND: prefer free tiers always. Before we add any paid
  service or a usage-billed API key, STOP and tell me to set a low spending
  limit / usage cap and a billing alert first. Flag anything that could cost
  money before we wire it in.
- DESIGN FOR MANY USERS WHEN IT'S REAL: a hello-world doesn't need this, but
  the moment a project will have real users or customers, design it
  multi-tenant from the start — an owner column (user_id) on every table,
  filter every query by it, turn on Row Level Security, and take identity from
  the session, never the browser. Warn me if we're about to store shared data
  without it.
- BRANCH FOR RISKY WORK: before a big or uncertain change, make a new git branch
  so my working version stays safe.
- README FOR EVERY PROJECT: create a short README.md (what it is, how to run it)
  when we start a new project.

## Models
- Tell me when a task is worth switching to the Fable model for deeper thinking,
  and remind me to switch back to Opus for everyday work.
EOF

Step 3 — Check it worked

$ claude mcp list     # you should see both "supabase" and "cloudflare"

Step 4 — Let Ada build your memory

Now start Ada and just ask. It creates your decision memory itself, through the Supabase tool — you never touch a database.

$ cd ~/Dev
$ claude

Then type this to Ada (this goes into the Claude chat, not the terminal):

Ada creates the table, saves the note, and reads it back to you. Your infrastructure is done — for good. 🎉 From here on, you just build, and Ada quietly keeps your memory and your backups running.

Running Claude in bypass-permissions mode

By default, Claude Code asks for your approval before it runs a command or edits a file. That's a good safety net while you're learning. But once you trust what you're doing, constant approvals break your flow. Bypass-permissions mode lets Claude act without stopping to ask each time.

$ claude --dangerously-skip-permissions

You can also toggle it from inside a session — press Shift + Tab to cycle through the permission modes until it shows bypass permissions.

Rule of thumb: use normal mode when you're exploring something new or nervous about it; switch to bypass mode for the steady, repetitive building once you know where you're headed.

Opus vs Fable 5 — which one, when

Claude comes in different models. Two matter for you. Switch between them anytime by typing /model in a Claude session. The whole trick is matching the model to the kind of thinking the task needs.

What Ada now handles for you

Here's the best part. That settings file you pasted in Part 07 quietly turned all the "good coding habits" into things Ada does for you automatically — you don't have to remember any of them. You don't need to memorize the git commands below; you just need to trust that they're happening. Here's what's going on behind the scenes:

Saves your work

After every change that works, Ada commits a snapshot. When you wrap up, it pushes everything to GitHub. Your code is always backed up — nothing you build can just vanish.

Guards your secrets

Ada keeps a .gitignore in every project so passwords and keys never get uploaded to GitHub by accident — and for real API keys, Ada uses Doppler (Part 11) so they never sit in a file at all.

Uses safe branches

Before anything risky, Ada works on a separate branch — so your working version is never the thing being experimented on.

Documents projects

Every new project gets a short README.md explaining what it is and how to run it.

Watches your spending

Ada flags anything that could cost money and reminds you to set a low cap before you use it — so a mistake stays a lesson, not a bill.

Remembers the "why"

Every real decision goes into your Supabase database, and Ada reads them back next time — so you never lose the thread of why you built something a certain way.

That's what "coding correctly" really means for you right now: your code is protected and your reasoning is remembered — and you didn't have to become an expert to get there.

Doppler — a safe home for your keys

As you build real projects, they'll need secret keys of their own — an API key for a weather service, a maps provider, a payment company. The habit you already have (never commit secrets, keep a .gitignore) stops those keys leaking to GitHub. Doppler is the next level up: it means your keys don't sit in a file on your laptop at all.

Why bother, in one line each

• Keys never live in your files → they can't be committed or leaked by accident.
• One place to manage them → add, change, or revoke a key without hunting through folders.
• Same keys everywhere → your laptop today and your live site later pull from the same vault, no copy-paste.

Set it up (once)

1. Create a free account at dashboard.doppler.com — sign in with your GitHub account.
2. Install the command-line tool and log in:

$ brew install dopplerhq/cli/doppler   # installs the `doppler` command
$ doppler login                        # opens your browser to approve

Use it in a project

Inside a project that needs secrets, connect it to Doppler, add a key, then run your app through Doppler so the key is injected:

$ doppler setup                         # pick/create a project + the "dev" config
$ doppler secrets set WEATHER_API_KEY   # it prompts you to paste the value
$ doppler run -- node index.js          # runs your app with the key injected

Your code reads the key the normal way — process.env.WEATHER_API_KEY in Node, os.environ["WEATHER_API_KEY"] in Python — but it was never in a file on your computer.

Managing your keys well

Storing keys safely is step one. A few habits keep them safe over time — and Doppler makes every one of them easy:

• One key per project. Don't reuse the same key everywhere. If one leaks, only that one project is exposed.
• Give a key the least access it needs. Many services let you make a key read-only or scope it to one feature — pick the smallest option that works.
• Rotate a key the moment it might have leaked (you pasted it somewhere public, a laptop went missing). Generate a fresh one, update it in Doppler, delete the old one — nothing else in your code has to change.
• Revoke keys you're done with in the provider's dashboard, so old keys can't be used against you.

Set spending limits — so a mistake can never cost you

Almost everything in this guide is free, and you should keep it that way while you learn. The one real money risk in coding is an app — or a leaked key — that gets used far more than you expected. A few minutes setting limits means a mistake stays a lesson, not a bill.

Where money can actually leak — and what to do

Ada / Claude Code

A flat subscription. No per-use charges, nothing to cap. You're safe here.

GitHub

Free for your projects, no usage billing. You're safe here.

Supabase

Start on the Free plan — no card needed. If you ever upgrade to Pro, turn on the "spend cap" so it can't bill you beyond the plan.

Cloudflare

The Free plan covers a huge amount. Stay on it; Cloudflare won't charge you without an explicit upgrade.

Paid API keys

Weather, maps, AI, payments — this is the real risk. Before you use the key in an app, open the provider's billing settings and set a low monthly usage limit and a billing alert.

Two settings to turn on for anything that could bill you

1. A spending limit (or usage cap) — a hard ceiling the service will not cross, even if something goes wrong.
2. A billing alert — an email that warns you as you approach the ceiling.

Set both low while you're learning — a few dollars is plenty. You can always raise them later once you know what an app actually uses.

Build for many users from day one

Your first projects might be just for you. But the moment an app has real users — or paying customers — it has to keep each person's data separate and private. That's called multi-tenancy, and it's one of those things that's easy to build in from the start and painful to bolt on later. You don't need it for a hello-world. But learn the shape now, so you recognize the moment you do.

The one habit that matters most: tag every row with its owner

From your very first table, give every row an owner column. Every piece of data belongs to someone. Add it on day one — adding it later means rewriting every table.

create table notes (
  id          uuid primary key default gen_random_uuid(),
  user_id     uuid not null references auth.users,  -- who owns this row
  body        text,
  created_at  timestamptz default now()
);

The rules that keep data private

• Filter every query by the owner. Never fetch data without asking "whose is it?" — no exceptions.
• Let the database enforce it, too. Turn on Row Level Security (RLS) in Supabase so the database itself blocks cross-tenant reads — a safety net for the day you forget a filter in code.
• Never trust the browser for identity. Get the owner's id from the logged-in session on the server, never from a value the browser sends — the browser can lie.
• One shared set of tables, separated by that key. Don't build a separate database per customer — it's the wrong default and a nightmare to maintain.

alter table notes enable row level security;

create policy "own rows only" on notes
  for all using ( auth.uid() = user_id );   -- the DB enforces the wall

Your daily cheat sheet

Honestly, you only need a handful of things. Ada does the rest for you.

Type these in the terminal

Just say these to Ada

Plain English, typed into the Claude chat — no commands to memorize.