Folders inside folders, all the way down. That's the whole trick.
/Users/jensen/Documents/my-project is an address, like a postal address.
Act 1 · Terminal05 / 54
Six commands carry you 90% of the way
terminal — zsh
$ pwd
/Users/jensen/Documents$ ls
my-project notes.md receipts$ cd my-project
$ cat notes.md
# Project notes...$ mkdir demo
$ cd .. # back up one floor
pwd
"Where am I?" — prints your current address.
ls
"What's here?" — lists the folder's contents.
cd
"Take me to..." — moves you to another folder.
cat
"Show me this file" — prints it to the screen.
mkdir
"Make a folder."
..
The floor above. cd .. goes up one level.
Act 1 · Terminal06 / 54
Two ways to give directions
Absolute — the full address
/Users/jensen/Documents/my-project/index.html
Always starts with /. Works from anywhere — like a full postal address.
Relative — from where you stand
my-project/index.html ../receipts/jan.pdf
Starts from your current folder. .. means "one floor up" — like saying "next door".
Why it matters: when an agent says it edited src/app/page.tsx, this is how you know which file it touched.
Act 1 · Terminal07 / 54
Checkpoint · predict
You start in /Users/jensen/Documents. You type: cd my-project then cd .. then pwd.
What does the computer print?
Think for ten seconds — then we go around the table.
Act 1 · Terminal — quiz08 / 54
Quick quiz — terminal
Q1
Which command tells you where you are right now?
pwd — print working directory.
Q2
You're in /Users/me/docs. What does cd .. do?
Moves you up one level — to /Users/me.
Q3
../notes.md — absolute or relative path?
Relative — it starts from where you're standing, not from the root.
Space reveals answers one by one · R reveals all · click a question works too.
Act 2 · File primitives09 / 54
Layer 2
Files, demystified
Every document, photo, and app is bytes — and the extension is a promise about how to read them.
Act 2 · Files10 / 54
A file = bytes + a promise
one file, opened honestly
notes.md← name + extensioninside, just bytes:# Meeting notesShip the deck by Friday....that's it. Text.
📝
.md / .txt
Plain text — readable by humans and agents alike.
🌐
.html
Text that describes a page's structure.
🖼️
.jpg / .png
Bytes encoding pixels — not meant to be read as text.
⚙️
.js / .py
Text that a computer can execute.
The extension doesn't change the bytes — it tells the computer which program should open them.
Act 2 · Files11 / 54
Markdown — text with light bones
What you type (.md)
# Standup notes
**Ship date:** Friday
- Deck is ready
- Demo needs wifi backup
Run `preview` before the call.
---
What you read
Standup notes
Ship date: Friday
Deck is ready
Demo needs wifi backup
Run preview before the call.
Same bytes, two views. # = heading · **bold** = bold · - = list item. This is how agents write documents — and how you brief them.
Tags are labels, not content: <h1> "this is a heading", <ul> "this is a list". The browser reads the labels and draws the page. Every website you've ever used was, at bottom, text like this.
Act 2 · Files13 / 54
Checkpoint · predict
A file contains these bytes: ## Agenda- Budget- Timeline
It's named agenda.md. What do you expect to see when you open it in a markdown viewer?
And: would the bytes be different if it were named agenda.txt?
Act 2 · Files — quiz14 / 54
Quick quiz — files
Q1
You rename notes.txt to notes.md. Did the bytes inside change?
No. Only the promise changed — which program opens it.
Q2
In markdown, what does a line starting with # become?
A heading. **bold** is bold, - starts a list item.
Q3
Why do AI agents work best with plain-text files?
Text can be read, edited, and diffed without special tools — by humans and agents alike.
Space reveals answers one by one · R reveals all · click a question works too.
Act 3 · Software engineering basics15 / 54
Layer 3
Anatomy of an app
Frontend, backend, database, authentication — every app you use is these four things in a trench coat.
Act 3 · Architecture16 / 54
Every app is a restaurant
Frontend
The dining room. What you see and touch: buttons, menus, layout. Runs in your browser or phone.
HTML + CSS + JavaScript
Backend
The kitchen. Takes your order, cooks it: business logic, calculations, rules. Runs on a server somewhere.
Python, Node, C#, Java...
Database
The pantry and the ledger. What survives when the lights go out: accounts, orders, records.
SQL Server, PostgreSQL, SQLite
▼
The frontend asks, the backend decides, the database remembers.
Act 3 · Architecture17 / 54
Watch a request make the round trip
PRESS SPACE TO RUN
Order
Browser · frontend
🎫 KEYCARD
⚙
Backend · kitchen
Database · pantry
POST /orders · 🎫GET customer 42 · 🎫
rows ⇢
⇠ 200 OK + data
Someone taps Order in the browser. Every click starts a conversation.
A request flies to the backend — carrying the order and your keycard token.
The kitchen checks the keycard first — AuthZ: who is asking, and may they ask?
The backend asks the database — the pantry — for what it needs.
The ledger answers with rows. The database remembers — it never decides.
The backend cooks: business logic runs here, never in your browser.
The response returns — 200 OK plus the data (HTML, or JSON).
The browser renders it. Whole round trip: ~200 milliseconds. That's the API — the agreed menu of asks and answers.
Act 3 · Architecture18 / 54
The database — the ledger that survives
01
It remembers
Restart the app, lose the power — the data stays. Your balance, your orders, your profile.
02
It enforces
Only valid writes get in: no negative prices, no duplicate invoice numbers.
03
It answers
"All invoices for customer X this month" — in milliseconds, across millions of rows.
Why agents care
Most real support and engineering work is reading and carefully changing this layer. That's why serious coding agents are given read-only access first, and write access only with approval gates.
Act 3 · Architecture19 / 54
Auth — who are you, and what may you do?
Authentication (AuthN)
Proving who you are: password, fingerprint, 2FA code.
The hotel checks your passport at check-in.
Authorization (AuthZ)
Deciding what you may do: your keycard opens YOUR room, not the penthouse.
Every request carries a token — the keycard the backend checks on every door.
Login, step by step: you type password → backend checks it → backend hands you a token → every later request shows the token → backend checks permission per action.
Act 3 · Architecture20 / 54
Checkpoint · walkthrough
You open Netflix on your TV and press Sign In.
Name the three layers in the moment you type your password — and say which one decides whether the password is right.
Bonus: where does "continue watching" live?
Act 3 · Architecture — quiz21 / 54
Quick quiz — apps
Q1
In the restaurant model: which layer is the kitchen?
The backend — it takes orders and does the work.
Q2
Who decides whether your password is correct — the frontend or the backend?
The backend. The client can fake a button; it can't fake the check.
Q3
One line each: AuthN and AuthZ?
AuthN = proving who you are (passport). AuthZ = what you may do (keycard).
Q4
What does an API define?
The menu — which requests you can make, and what comes back.
Space reveals answers one by one · R reveals all · click a question works too.
Act 4 · How browsers really work22 / 54
Layer 4
The browser, demystified
The most-used piece of software on your machine — and the stage where frontend, backend, and database finally meet.
Act 4 · Browser23 / 54
URL → page, in five stops
01
You type the address
jensenloke.github.io/talks — a name, not yet a place.
02
DNS resolves the name
The internet's phone book translates the name into a server's numeric address.
03
Your browser asks that server
A request, exactly like Act 3: "give me this page."
04
The server answers with files
HTML (structure), CSS (looks), JavaScript (behavior) — often fetched from several places.
05
The browser renders
It reads the labels, paints the pixels, runs the scripts. The page is alive.
Act 4 · Browser24 / 54
Three files walk into a browser
HTML — skeleton
What exists: headings, lists, buttons, images. Pure structure.
CSS — skin
How it looks: colors, fonts, spacing, layout. Same HTML, different outfits.
JavaScript — muscle
What it does: reacts to clicks, fetches data, updates the page without reloading.
Client vs server: code running in your browser (client) can display and ask — but the code running on the server decides. Your browser can fake a button; it can't fake the database.
Act 4 · Browser25 / 54
Live: dissect a real website
your browser, right-click → Inspect
# do this live:1. Open jensenloke.github.io
2. Right-click any text → Inspect
3. Hover the HTML → watch it light up
4. Network tab → reload → watch files arrive
5. Edit someone's name live on the page :)
What to notice
The page really is HTML text — you're reading the source.
The Network tab IS stop 4 of the journey.
Your edits change YOUR browser only — client ≠ server.
Act 4 · Browser — quiz26 / 54
Quick quiz — the browser
Q1
Name the five stops from URL to visible page.
Name → DNS → request to the server → files come back (HTML/CSS/JS) → browser renders.
In devtools you edit a headline. Did the website change for everyone?
No — only your browser. Client edits never touch the server.
Space reveals answers one by one · R reveals all · click a question works too.
Act 5 · Deployment27 / 54
Layer 5
Running & shipping
From "works on my machine" to "works for everyone" — localhost, Vercel, Supabase, and Docker.
Act 5 · Deployment28 / 54
localhost — your machine, as a server
terminal
$ python3 -m http.server 8000
Serving HTTP on :: port 8000...# now open:http://localhost:8000
The two ideas
localhost = "this very computer".
The port = a door number. Many servers can run at once, each behind its own door.
This is how every project starts: running locally, visible only to you, safe to break. Agents live here too — most of their work runs on localhost before anything ships.
Act 5 · Deployment29 / 54
Going public, without a server room
Vercel — the frontend's post office
Connect it to your GitHub; every push goes live worldwide in seconds. Hosting, addresses, HTTPS — handled.
TripBeacon — a product on this very site's work page — runs on Vercel.
Supabase — someone else's ledger
A hosted database plus authentication: user accounts, logins, permissions — rented by the month instead of built by the year.
Frontend on Vercel + data in Supabase = a complete product, no servers of your own.
The modern default: rent the infrastructure, own the code. You push files; platforms do the running.
Act 5 · Deployment30 / 54
Docker — ship the whole machine, boxed
The problem: "works on my machine" — your app needs the right Python, the right settings, the right everything.
Docker's answer: pack the app AND its whole environment into a container — a sealed box that runs identically anywhere.
the idea
my app+ its settings+ its tools─────────────= one box 📦runs the same everywhere
Where Vercel ships files, Docker ships machines. Big systems run as fleets of boxes — including much of what runs agents.
Act 5 · Deployment31 / 54
Checkpoint · pick the tool
Three situations — name the tool:
1. "I want my site live on the internet 30 seconds after I save it."
2. "My app needs user logins and saved data, but I don't want to run a database."
3. "My teammate says it works on their laptop but breaks on mine."
Act 5 · Deployment — quiz32 / 54
Quick quiz — running & shipping
Q1
What does localhost mean?
"This very computer" — your machine acting as a server.
Q2
Ports are like… what?
Door numbers — many servers can run on one machine, each behind its own door.
Q3
The todo app's items vanish when you refresh. Why?
The state lived only in JavaScript's memory — there's no database (no pantry) to remember.
Q4
Which tool ships files, and which ships whole machines?
Vercel ships files. Docker ships machines.
Space reveals answers one by one · R reveals all · click a question works too.
Act 6 · Version control & CI/CD33 / 54
Layer 6
Git, GitHub, and the robots
Memory for your code, a home in the cloud, and automation that checks and ships it.
Act 6 · Git34 / 54
Git — a time machine for folders
PRESS SPACE TO RUN
Working folder
index.html
style.css
app.js
Staging shelf
app.js · staged
"Add pricing page"
HEAD▼
PR #12 · feature → main · reviewed ✓
You edited app.js. The working folder holds your change — and only that moment.
git add app.js — choose what goes into the next snapshot. The staging shelf holds it.
git commit -m "Add pricing page" — the snapshot is saved to history, with a message. HEAD points at now.
Keep committing: history grows. Every saved moment stays reachable.
git branch feature — a parallel universe forks off. Free. Main doesn't notice.
git checkout feature — HEAD moves; new commits land on the fork. Main stays untouched.
git checkout main — the time machine: your folder snaps back to main's state, including app.js.
git merge — the universes recombine. Nothing was ever lost.
main is the agreed trunk — the version everyone trusts. A branch is a side road: work happens there without touching the trunk.
Pull request — you propose your branch back to main. Humans review the diff and approve. That's the checkpoint before merge.
Rebase — instead of merging, lift your branch onto main's latest commit: a straighter history. Same safety net, different shape.
Act 6 · GitHub35 / 54
GitHub — git's home, and the world's workshop
Backup & history
Your repo, mirrored to the cloud with its full history.
Collaboration
Propose changes as a pull request — reviewed and approved before merging.
Identity
A public record of what you've built — a portfolio that updates itself.
The distinction: git is the tool on your machine; GitHub is the website where repos live and people (and agents) collaborate. You can use git without GitHub. You can't use GitHub without git.
Act 6 · CI/CD36 / 54
CI/CD — the robots that check and ship
PRESS SPACE TO RUN
💻
git push
🤖
Checks · CI
🌍
Deploy · CD
commit 3f9c21a
● LIVE
git push — you hand the robots your change. That's the whole job description.
CI picks it up automatically: does it build? do the tests pass?
The robots run the checks — no human has to remember to check.
Checks pass — and a human approves. Robots check; humans decide.
CD ships it — no manual copying, no "deploy Fridays".
Live. Vercel building and publishing your site the moment you push is this machine.
Act 6 · Git37 / 54
Checkpoint · Friday, 6pm
It's Friday, 6pm. A change went out an hour ago and the site is broken. People are emailing.
With git in the picture, what is your first move — and why is this calm instead of a crisis?
Think: what does the time machine give you?
Act 6 · Git — quiz38 / 54
Quick quiz — git & the robots
Q1
What is a commit?
A saved snapshot of the whole folder, with a message describing it.
Q2
Git vs GitHub — one line each?
Git is the time machine on your computer. GitHub is the cloud home where repos live and people collaborate.
Q3
What does CI do? And CD?
CI runs the checks automatically on every change. CD ships it once checks pass and a human approves.
Q4
An agent just changed 30 files and something broke. What's your first move?
Revert to the last good commit. History has your back — undo first, understand later.
Space reveals answers one by one · R reveals all · click a question works too.
Act 7 · Agents39 / 54
Layer 7
Briefing the agent
AGENTS.md, CLAUDE.md, and skills — how you hand the map to the machine.
Act 7 · Agents40 / 54
AGENTS.md — orientation, in a file
Real excerpt — this site's own AGENTS.md
# AGENTS.md — jensenloke.github.io
## Repository purpose
Jensen Loke's personal site and blog...
No build step, no frameworks.
## Conventions
- Every article belongs to exactly one track
- Index pages updated newest first
## Gotchas
- Keep homepage featured card in sync
A markdown file at the repo's root — Act 2, in the wild.
Agents read it before touching anything.
It carries: purpose, conventions, workflow, gotchas.
CLAUDE.md is the same idea under Claude's name; many repos carry both.
The test: ask an agent to "add a new article" here and watch it follow the rules — newest first, right folder, index updated. It read the file.
Act 7 · Agents41 / 54
Skills — runbooks on demand
AGENTS.md — always on
The orientation every session starts with. Context the agent carries everywhere in this repo.
Like your first week at a job: how things work here.
Skills — loaded on demand
Task-specific playbooks the agent opens when doing that task: "how we deploy", "how we review code", "how we answer tickets".
Like the checklist you open for one specific job.
Why this matters to you: this is how non-engineers make agents disciplined. You don't write code — you write the map and the checklists in plain text. The agent supplies speed; the files supply consistency; you keep judgment.
Act 7 · Agents42 / 54
Live: watch the agent obey the file
the demo
# ask the room first:"What will the agent do before
writing a single line?"# then run it live:> Add a new article about today's class
reads AGENTS.md
creates qwen/<slug>.html
updates index (newest first)
updates writing/index.html
What to point out
It read the file first — nobody told it to.
It followed conventions it didn't invent.
Text in → disciplined behavior out.
Act 7 · Agents — quiz43 / 54
Quick quiz — briefing the agent
Q1
What does an agent read before touching a repo?
AGENTS.md (or CLAUDE.md) — the orientation file at the repo's root.
Q2
AGENTS.md vs skills — what's the difference?
AGENTS.md is always-on orientation. Skills are runbooks loaded on demand for a specific task.
Q3
What format do you write these briefings in?
Plain text — markdown. Act 2, in the wild.
Q4
The agent supplies speed, the files supply consistency. What stays human?
Judgment and authority. That's the human in the loop.
Space reveals answers one by one · R reveals all · click a question works too.
Act 8 · Build day44 / 54
Hands on
Build day
You now hold the map. Time to feel what building costs — starting with the smallest app that deserves the name: a todo list.
Act 8 · Build day45 / 54
The brief: a todo app
What it must do
Type a todo and add it to a list.
Click a todo to mark it done (strikethrough).
Double-click to delete it.
The rules
One file: index.html.
Runs on localhost only.
No database, no accounts, no retention.
That's the entire spec. As simple as software gets. Let's find out how simple it really is.
$ cd my-todos
$ python3 -m http.server 8000
Serving HTTP on :: port 8000...# open in your browser:http://localhost:8000
The moment
Add three todos. Admire them. Then refresh the page.
Gone. All of them.
Question for the room: where did the todos go?
Act 8 · Build day48 / 54
What that "simple" app really took
What we built
A folder with a known address
A file with the right promise (.html)
Structure + style + behavior
A server + a port
Six moving parts — and the app FORGETS everything.
What a real product adds
Database + backups (remembering)
Accounts, auth, permissions
APIs · mobile · multiple users
Testing · security · monitoring
Deployment · CI/CD · rollback
Hundreds of moving parts — before a single customer arrives.
This is why software is complicated. And this is why agents change the math — you just felt what they're about to take off your plate.
Act 8 · Build day49 / 54
Now the agent's turn
live — the same brief
> Build me a todo app. Add, mark done,
delete. Keep it in one file for now.
writes index.html
starts the local server
todo app running on localhost# elapsed: under a minute
Name the layers as they fly past
Folder + file (Acts 1–2)
Skeleton, skin, muscle (Act 4)
Serving on localhost (Act 5)
Ten minutes by hand. Under a minute with an agent. Same layers — you just see them now.
Act 8 · Build day50 / 54
One more ask: make it remember
live — the follow-up
> Keep my todos when I refresh.
adds localStorage save/load
todos survive the refresh
What just happened
The app grew a memory — the browser's own. Refresh-proof, but still one browser, one machine, lost if you clear it.
To remember across devices and users, the memory moves to a database — the pantry, hosted on Supabase — with auth deciding whose todos are whose. That's Act 3 and Act 5, graduated.
Act 8 · Build day51 / 54
The iceberg behind "just an app"
☑
You built this
One file · one screen · one user · one machine · no memory.
▼
+
Memory
Database, backups, migrations.
+
People
Accounts, auth, permissions, roles.
+
The world
Hosting, domains, HTTPS, mobile, scale.
+
Trust
Tests, security, monitoring, rollback.
The punchline
Every app you've ever used carried this whole iceberg below the waterline.
You built the tip in ten minutes. The rest is why software teams exist — and why the map you now hold is worth having.
Act 9 · The graduation52 / 54
The graduation, live
the graduation — build + ship live
1. Ask the agent for a one-page site (Act 7)2. It writes index.html + style (Act 2)3. Preview on localhost (Acts 5, 4)4. Commit + push to GitHub (Act 6)5. Watch it go live (Act 5)
Narrate every act as it appears
The class should shout out which layer is happening. When the page goes live, that's the whole course in one sitting.
Act 9 · The graduation53 / 54
The map, complete
1
Terminal
How you — and agents — talk to the machine. pwd, ls, cd.
2
Files
Bytes plus a promise. Markdown and HTML: text you can read, agents can edit.
3
Apps
Frontend asks, backend decides, database remembers. Tokens at every door.
4
Browser
Name → address → request → files → pixels. Client displays; server decides.
5
Deployment
localhost to break safely; Vercel, Supabase, Docker to reach the world.
6
Git / GitHub / CI-CD
Snapshots, collaboration, and robots that check and ship.
7
Agent briefings
AGENTS.md and skills: the map, written down in plain text. Judgment stays human.
8
The human
Direction, taste, and judgment. Agents hold the wrench; you decide what's worth building.
Fin54 / 54
Thank you
You built the app. Now you hold the map.
Questions, challenges, and "wait, what about..." all welcome.