You're a developer now. A getting-started guide for AI-assisted development 0 / 8
Getting started · for anyone who's been told to "become a developer"

You're going to become a developer.
Apparently.

There's a memo: everyone's a developer now. You've never opened a terminal, which is fine — by the end of this you'll have a real program written in Python, living in a real GitHub repo, built with an AI that does the typing. It takes about an hour and assumes you know nothing. We start at the very beginning.

~ — zsh
%
What you'll build
  • Conway's Game of Life — a tiny animated universe running in your terminal.
  • Written in Python, built with Claude Code.
  • Published to GitHub and shipped as a real pull request.
What you need
  • A Mac and its admin password.
  • An email address and about an hour.
  • ~$20 for Claude — there's no free tier, but a friend with Claude can send a referral that includes a free trial. Ask around before paying.

How this guide works

Every command sits in a card that looks like a real terminal window. Hit Copy, paste it into your terminal, press Return. Under each one, a ↳ what this does line explains it in plain English — you'll never paste something you don't understand.

Mark steps done as you go (your progress is saved in this browser), and each section ends with a quick quiz so you know it stuck. Troubleshooting and Glossary live in the top bar — open them anytime something looks unfamiliar or breaks.

iYou can't break your Mac by reading. Looking around in the terminal is completely safe. The few commands that change your system or need your password are clearly flagged before they appear.

Start with §01 → The Terminal

01

The Terminal

A window where you type instructions instead of clicking them.

It looks intimidating because it's mostly text on a dark background, but it's the most literal part of your computer: you type a command, it does exactly that, and it prints what happened. Nothing hidden.

Open it now: press ⌘ Space, type "Terminal," press Return. A window appears with a % and a blinking cursor. That % is the prompt — the computer waiting for you to type. Everything below happens at that prompt. There are four commands to learn first, and they're all about one idea: moving around folders.

pwd Where am I?

The terminal is always "inside" one folder at a time. Before doing anything, it helps to know which one. pwd stands for print working directory — it answers exactly that.

~ — zsh
% pwd
/Users/you
The output is a path — a chain of folders separated by slashes. /Users/you reads as: the you folder, inside Users, at the root of the disk. This is your home folder, where every terminal starts.

ls What's in here?

pwd tells you where you are; ls ("list") tells you what's around you — the files and folders inside the current directory.

~ — zsh
% ls
Desktop Documents Downloads Pictures
Commands take flags — options after a dash — that change what they do. ls -l lists one item per line with details; ls -a also shows hidden files (names starting with a dot, like .zshrc). Combine them as ls -la:
~ — zsh
% ls -la
drwxr-xr-x 5 you staff 160 Jun 25 09:14 Desktop
-rw-r--r-- 1 you staff 842 Jun 24 18:02 .zshrc
Those drwxr-xr-x columns on the left are permissions — who may read, write, or execute each file. That x (execute) bit is what lets a file run as a program, the way ls and cd do. You change permissions with chmod — and in §04 you'll use chmod +x to turn a file you wrote into a command you can run.

cd Moving around

cd ("change directory") moves you between folders. Give it a folder name to go in; give it .. to go up one level; give it nothing to jump home from anywhere.

~ — zsh
% cd Documents
% pwd
/Users/you/Documents
% cd ..
% pwd
/Users/you
.. always means "the folder above this one." A single . means "right here." And ~ is shorthand for your home folder — so cd ~ (or just cd) takes you home no matter how deep you've wandered.

mkdir Making a folder

mkdir ("make directory") creates a new, empty folder where you are. You'll use it constantly — every project begins as a fresh folder.

~ — zsh
% mkdir projects && cd projects
% pwd
/Users/you/projects
Made a folder called projects, then stepped into it. The && means "do the first thing, and only if it works, do the next." If mkdir fails — say the folder already exists — cd won't run.

The Unix way

Those four commands hint at a bigger idea. The terminal is built from many small tools that each do one thing well, and you combine them. The pipe | takes the output of one command and feeds it as the input to the next. Here, ls lists files and grep keeps only the lines that match a word:

~ — zsh
% ls -la | grep .zshrc
-rw-r--r-- 1 you staff 842 Jun 24 18:02 .zshrc
Two simple tools became one useful one. That's the whole philosophy: compose small pieces instead of one giant program. Stuck on what a command does? Type man ls for its manual (press q to quit).

A few more you'll meet along the way — no need to memorize them now:

  • echo hello — prints text back to you.
  • chmod +x file — changes a file's permissions; +x makes it runnable as a program (more in §04).
  • Ctrl+C — stops whatever command is currently running. Your escape hatch when something hangs or won't quit; you'll use it to stop the Game of Life in §06.
  • clear (or ⌘K) — wipes the screen clean when it gets cluttered.
  • ping github.com — checks you can reach a server over the network.
  • dig +short github.com — looks up the address behind a web name.
  • ssh — connects securely to another machine over the network.

That's the core: pwd to see where you are, ls to see what's there, cd to move, mkdir to make — and the idea of piping small tools together. Everything else in this guide builds on these.

Pop quiz · §01
You've lost track of which folder the terminal is in. What do you type?
Skip ahead anyway →
02

Your toolkit

Now we install the real tools. One sentence to remember: Homebrew installs apps, mise installs commands.

You'll set up four things, in order: Apple's developer basics, Homebrew (for Mac apps), a better terminal and editor, and mise (for command-line tools). Each builds on the last, so run them top to bottom.

① Apple's Command Line Tools

macOS ships without a few essentials developers need — including git, the tool that tracks code changes. This one command installs them. A dialog box will pop up; click Install and wait a few minutes.

~ — zsh
% xcode-select --install
When it finishes, confirm git is there:
~ — zsh
% git --version
git version 2.39.5 (Apple Git-154)

② Homebrew

Homebrew is the standard way to install Mac applications from the terminal. Paste its official installer. It will ask for your Mac password (the one you log in with) — that's expected.

!This one needs your password. When you type it, nothing appears on screen — no dots, no stars. That's normal; the terminal hides password length. Type it and press Return.
~ — zsh
% /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
When it's done, the installer prints two lines to "add Homebrew to your PATH." On Apple-Silicon Macs that's the command below — it teaches your terminal where to find brew. Run it, then close and reopen Terminal.
~ — zsh
% echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
% eval "$(/opt/homebrew/bin/brew shellenv)"
PATH is the list of places your terminal looks for programs. The first line saves the setting for future sessions; the second applies it right now. Confirm with brew --version.

③ A real terminal and editor

Time to use Homebrew for what it's best at — installing apps. iTerm2 is a nicer terminal than the built-in one, and VS Code is the editor where you'll read and write code. The --cask flag tells Homebrew these are graphical apps.

~ — zsh
% brew install --cask iterm2 visual-studio-code
🍺 iterm2 and visual-studio-code were successfully installed!
Open iTerm2 from Spotlight (⌘ Space → "iTerm") and use it from here on — everything you've learned works exactly the same, it just looks better. To open the current folder in VS Code later, you'll type code .

④ mise — your tool installer

mise (say "meez") installs command-line tools and keeps their versions tidy. From now on, whenever this guide needs a new tool, you'll reach for mise. Install it:

~ — zsh
% curl https://mise.run | sh
Then turn it on for your shell (this is mise's version of Homebrew's PATH step), and reload:
~ — zsh
% echo 'eval "$(~/.local/bin/mise activate zsh)"' >> ~/.zshrc
% source ~/.zshrc

Now grab your first two tools with it: uv (for Python, next section) and jq (for reading JSON data). Installing more than one at once is fine.

~ — zsh
% mise use -g uv jq
mise uv@0.9.2 ✓
mise jq@1.8.1 ✓
-g means "global" — available everywhere, not just one folder. You already have git from step ①, and uv brings Python in the next section, so that's the whole toolkit.
Can't find a tool by name? mise knows hundreds. Search with mise registry | grep <name> to find the exact one — e.g. mise registry | grep node.
iNo quiz here — this section is pure setup. The next one earns its quiz.

Next: §03 → Git & GitHub

03

Git & GitHub

Two different things people constantly confuse.

Git is a tool on your Mac that takes snapshots of your code over time, so you can see what changed and undo mistakes. GitHub is a website that stores those snapshots online, so your code is backed up and shareable. Git is the camera; GitHub is the photo album in the cloud.

Here's the good news: once Claude Code is set up, it does almost all the git work for you. You'll just ask. So this section teaches the handful of ideas you need to follow along, not every command.

Tell git who you are

Every snapshot ("commit") is stamped with a name and email. Set yours once. Use the email you'll sign up to GitHub with.

~ — zsh
% git config --global user.name "Your Name"
% git config --global user.email "you@example.com"
% git config --global init.defaultBranch main
Replace the name and email with your own (keep the quotes). The last line makes the starting branch of every project be called main — the modern default.

Create your GitHub account

In your browser, go to github.com and sign up — it's free. Use the same email you just gave git. Then come back here to connect your Mac to it.

Install gh and log in

gh is GitHub's official command-line tool. It's how you'll create repos and open pull requests without leaving the terminal. Install it with mise:

~ — zsh
% mise use -g gh
mise gh@2.95.0 ✓

Now connect it to your account. This one is interactive — instead of finishing instantly, it asks you a few questions. Use the arrow keys and Return to answer.

~ — zsh
% gh auth login
? Where do you use GitHub? GitHub.com
? Preferred protocol for Git operations? HTTPS
? How would you like to authenticate? Login with a web browser
Pick GitHub.com, then HTTPS, then Login with a web browser. It shows a short code and opens your browser — paste the code, click authorize, done. Check it worked with gh auth status.

The five words you'll actually hear

You don't need to master git. You need to recognize five words, because Claude Code will use them with you:

  • Repository (repo) — a project folder that git is tracking. One repo per project.
  • Commit — one saved snapshot, with a short message describing the change.
  • Branch — a parallel line of work. You make changes on a branch so main stays safe until you're happy.
  • Pull request (PR) — a proposal to merge a branch into main, where the change can be reviewed first. You'll open one in §07.
  • Issue — a note on GitHub describing a bug or a to-do. A tidy way to track what's next.
Bonus, for later: a worktree lets you check out two branches into two folders at once — handy when you want Claude working on one branch while you poke at another. Just know the word exists; git worktree add ../experiment some-branch is all it takes.
Pop quiz · §03
You want to propose a change for review before it joins the main code. What are you opening?
Skip ahead anyway →
04

Python

The language you'll write — gently, and just enough to read it.

Python is popular because it reads almost like English. You won't memorize it; you'll recognize it, because Claude Code writes most of it. We'll poke at Python live, learn its building blocks, then write a real file.

The interactive interpreter

Python comes with a REPL — a live prompt where you type one line and immediately see the result. Start it with uv run python (uv quietly downloads Python the first time). The new prompt is >>>.

~ — python
% uv run python
>>> 2 + 2
4
>>> "hello".upper()
'HELLO'
Leave the REPL anytime with exit() or Ctrl+D. Everything in this section you can type at the >>> prompt to see it work.

Three ways to hold data

Almost everything in Python is built from three containers:

~ — python
# a list — an ordered sequence
>>> fruits = ["apple", "pear", "plum"]
# a dict — labelled lookups (key → value)
>>> prices = {"apple": 1.20, "pear": 0.90}
# a set — unique items, duplicates dropped
>>> seen = {"apple", "apple", "pear"}
>>> seen → {'apple', 'pear'}
List = order matters, duplicates allowed (fruits[0] is "apple"). Dict = look things up by name (prices["apple"] is 1.20). Set = a bag of unique things. You'll use lists and dicts constantly.

Loops and functions

A loop repeats work; a function (defined with def) packages it under a name. Create a file called greet.py (run code ~/greet.py to open a fresh one in VS Code), paste this in, and save with ⌘S — we'll unpack that last block right after.

greet.py
def greet(name):
return f"Hello, {name}!"
 
def main():
for name in ["Ada", "Alan", "Grace"]:
print(greet(name))
 
if __name__ == "__main__":
main()
Notice Python uses indentation (the spaces) to show what's inside what — no curly braces. f"Hello, {name}!" is an f-string: it drops the value of name right into the text.

__main__ Make it a real command

That last block — if __name__ == "__main__": — is the one bit of Python that looks like noise but isn't. It's what turns a file into a program you can run, exactly like the Unix tools (ls, cd) from §01.

iWhat if __name__ == "__main__": means. A Python file can be imported by another file (to borrow its functions) or run directly (to do its job). This line says "only do this part when I'm run directly, not when I'm imported" — it's how a file knows whether it's the program itself or just a helper.

Run it the simple way first:

~ — zsh
% uv run greet.py
Hello, Ada!
Hello, Alan!
Hello, Grace!

Now make the file a command in its own right. First add a shebang as the very first line of greet.py — it tells your Mac "run me with Python." In VS Code, put this on line 1 and save:

greet.py — line 1
#!/usr/bin/env python3

Then flip on the execute permission with the chmod you met in §01, and run the file directly:

~ — zsh
% chmod +x greet.py && ./greet.py
Hello, Ada!
Hello, Alan!
Hello, Grace!
chmod +x switches on the execute bit — the x you spotted in ls -la back in §01. The ./ means "the file right here." You no longer need uv run; greet.py is a command now, just like the built-in tools. You just made your first one.

A few moves worth knowing

These idioms come up everywhere — skim them, you'll recognize them when Claude writes them:

~ — python
>>> nums = [5, 2, 9, 1]
>>> nums[1:3] # slicing
[2, 9]
>>> sorted(nums)
[1, 2, 5, 9]
>>> [n * 2 for n in nums] # list comprehension
[10, 4, 18, 2]
Slicing grabs a sub-range. sorted returns a sorted copy. A comprehension builds a new list from an old one in one line — Python's most-loved shortcut.

Using other people's code

You rarely start from scratch — you install packages (libraries) other people wrote. uv adds them to a project. Let's make a project and add requests, the standard library for fetching things from the web.

~/projects — zsh
% uv init hello && cd hello && uv add requests
Initialized project `hello`
+ requests==2.32.3
uv init hello creates a project folder with a starter main.py. uv add requests downloads the library and records it, so anyone who opens this project gets the exact same setup. (Another you'll see a lot later: uv add boto3, Amazon's toolkit for AWS.)

Write and run a real file

Open the project in VS Code, replace main.py with the code below, and save (⌘S).

~/projects/hello — zsh
% code . # opens this folder in VS Code
main.py
import requests
 
def main():
wisdom = requests.get("https://api.github.com/zen").text
print("GitHub says:", wisdom)
 
if __name__ == "__main__":
main()
Back in the terminal, run it. uv run uses the project's libraries automatically:
~/projects/hello — zsh
% uv run main.py
GitHub says: Non-blocking is better than blocking.
Pop quiz · §04
You need to look something up by name, like a price for "apple". Which container fits?
Skip ahead anyway →
05

Claude Code

An AI that works in your terminal — reads your files, writes code, runs commands, all with your say-so.

This is the part that makes the rest easy. You describe what you want in plain English; Claude Code reads your project, makes the changes, and shows you each one before it touches anything.

$It costs money — be ready for that. Claude Code needs a paid Claude Pro plan (about $20/month) or pay-as-you-go API credits. There's no free tier. But a friend who already has Claude can send you a referral with a free trial — worth asking before you pay. Sign up or check plans at claude.com/pricing.

Install it

One command — the official installer. It doesn't need any of the other tools; it stands on its own.

~ — zsh
% curl -fsSL https://claude.ai/install.sh | bash
Claude Code installed. Run `claude` to get started.
If your terminal says claude: command not found afterward, close and reopen it once so it picks up the new tool.

Start your first session

Claude Code works inside a project folder. Move into one and launch it. The first time, it opens your browser to log in — use your Claude account.

~/projects/hello — zsh
% claude
✻ Welcome to Claude Code
Logged in as you@example.com
How can I help?

The five things to know on day one

  • Type / to see every command. /help is a fine first move.
  • It asks before it acts. Run a command, edit a file — Claude shows you and waits for Yes / Yes, don't ask again / No. Nothing happens without your approval.
  • Press Shift+Tab to cycle how much it asks — from confirming everything to auto-accepting edits once you trust it.
  • Say what, not how. "Add a high-score file and show the top five" beats trying to dictate code. It figures out the how.
  • /clear starts a fresh conversation, /init writes a project notes file, and /exit (or Ctrl+D) leaves.
Everything you learned in §01–§04 still matters — Claude can run those commands for you, but now you understand what it's doing. That's the difference between a co-pilot and a black box.
Pop quiz · §05
Claude Code wants to edit a file. What happens?
Skip ahead anyway →
06

Build it

Conway's Game of Life — a universe from four rules.

The Game of Life is a grid of cells that live and die by simple rules, generation after generation. From those rules, shapes emerge that crawl and pulse across the screen. It's a perfect first build: small, visual, and genuinely mesmerizing. You won't write it — you'll direct it.

Make a home for it

~ — zsh
% mkdir ~/game-of-life && cd ~/game-of-life && git init
Initialized empty Git repository in ~/game-of-life/.git/
A fresh folder, with git now watching it. Launch Claude Code inside it: claude

Ask for it

Once Claude is running, paste this. Notice it describes what the program should do, not how to code it.

Say this to Claude
Build Conway's Game of Life in Python as a single file I can run with uv. Animate it in the terminal with a grid of cells, wrap around at the edges, show a generation counter, and quit cleanly when I press Ctrl+C. Build a terminal user interface that lets me start, and stop simulations.

Claude will create a file (it'll tell you the name — usually main.py) and ask permission before saving. Approve it. Then run what it built:

~/game-of-life — zsh
% uv run main.py
Conway's Game of Life · generation 12
█ █ ██ █ ██ █ █ ██ █ █
██ █ █ ███ █ ██ █ ██ █
[ space ] start / stop [ q ] quit
You should get a small interface — start a simulation and watch cells flicker to life and die across the grid, then stop it. (Ctrl+C always force-quits, too.) If the filename differs, use whatever Claude told you: uv run <that name>.

What "good" looks like

Here's a clean reference version, so you can see the shape of a small, well-organized program. The four rules live in one short function near the top.

game_of_life.py — Python
def step(grid):
"""Apply the four rules to produce the next generation."""
height, width = len(grid), len(grid[0])
nxt = [[False] * width for _ in range(height)]
for y in range(height):
for x in range(width):
n = count_neighbours(grid, x, y)
if grid[y][x]:
nxt[y][x] = n in (2, 3) # survives
else:
nxt[y][x] = n == 3 # born
return nxt
Don't worry about every symbol. Notice it's readable: a function with a one-line description of its job, a loop over every cell, and the rules spelled out. You can ask Claude "explain this file to me" anytime.

Make it yours

Now change it. Ask Claude for a feature — this is where it gets fun.

Say this to Claude
In the start screen, let me choose the board size and pick a starting pattern — a glider, a blinker, or random — before each simulation runs.

Approve the changes, relaunch, and try a glider on a small board, then a big random one — watch how differently they evolve:

~/game-of-life — zsh
% uv run main.py
Board size? › small medium large
Pattern? › glider blinker random

Checkpoint

You should have a working Game of Life with a small interface to start, stop, and set up simulations. Running it is the test — if cells are moving, you passed. If not, the Troubleshooting panel (top bar) covers the usual snags.

Next: §07 → Ship it

07

Ship it

Put it on GitHub and open a real pull request.

Your program runs on your Mac. Now make it real: save a snapshot, push it to GitHub, then practice the everyday workflow — change something on a branch and propose it through a pull request. Even working alone, this is how professionals keep their history clean.

Save and publish

First, take a snapshot (a commit), then create a GitHub repo and push it up — gh does both at once.

~/game-of-life — zsh
% git add -A # stage every change
% git commit -m "Conway's Game of Life"
% gh repo create game-of-life --public --source=. --push
✓ Created repository you/game-of-life on GitHub
✓ Pushed commits to https://github.com/you/game-of-life
git add -A gathers your changes, git commit snapshots them with a message, and gh repo create makes the online repo and uploads it. Your code is now backed up on GitHub. (Don't want to type git yourself? Ask Claude: "commit everything and push it to a new public repo.")

Change something on a branch

Never make changes directly on main. Start a branch — a safe side-track — make your change there, and propose it back. Create one:

~/game-of-life — zsh
% git checkout -b add-colors
Switched to a new branch 'add-colors'
Say this to Claude
Give the living cells a color so the animation pops, and commit the change with a clear message.
Want to see exactly what changed before trusting it? Type git diff, or just ask Claude "what did you change?"

Open the pull request

Push your branch and open a PR. --fill writes the title and description from your commit, so there's nothing to type.

~/game-of-life — zsh
% git push -u origin add-colors
% gh pr create --fill
✓ https://github.com/you/game-of-life/pull/1
% gh pr view --web
Opening pull request in your browser…
Your browser opens the pull request on GitHub. This is the review screen — the green/red lines show exactly what changed. This is what your boss keeps saying in meetings.

Merge it

Happy with it? Merge the PR into main, clean up the branch, and pull the result back to your Mac.

~/game-of-life — zsh
% gh pr merge --squash --delete-branch
✓ Merged pull request #1
% git checkout main && git pull
Updating… Fast-forward. Your colors are now on main.
And issues? When you think of the next idea, jot it down where you'll find it: gh issue create. It's a to-do list that lives with your code.

Checkpoint

You just shipped code the way every software team does: branch → change → pull request → review → merge. It's live on GitHub, with a clean history. That's the entire loop — everything else is variations on it.

Next: §08 → Where to go next

08

Next steps

You have the whole loop. Now point it at something you actually want.

An hour ago, "open a terminal" was a stretch. Now you can install tools, write and run Python, and ship code through a pull request with an AI doing the heavy lifting. The rest is reps.

What to do this week

  • Build something small you'd actually use. A script that renames your screenshots, a tool that checks a website is up, a tiny web page. Make a folder, run claude, and describe it.
  • Let Claude teach you. Open any project and ask "explain what this code does" or "what would you improve?" Reading code with a guide is the fastest way to learn.
  • Leave notes for next time. Run /init in a project — Claude writes a CLAUDE.md file describing it, so future sessions start smart.
  • Keep the loop tidy. Branch, commit often, open PRs even for yourself. Your future self will thank you.
Part 2 is coming: "Put it on the internet." The same S3 + CloudFront + Route 53 stack that serves this very page — how to take something you built and give it a real web address. (That's also why boto3 showed up in §04.)

As for the memo: you're now the person in the building who actually knows what a pull request is. Go build something of your own.

You're a developer now. · a getting-started guide for AI-assisted development
built with the terminal, GitHub, Python & Claude Code — the very tools it teaches.