day streak
☽ Dark
0%
Ch 1 · Environment
EverythingThreads
AI CLARITY · BUILD · 23 segments

FOUR WEEKS.
ONE WORKING TOOL.
YOURS.

The AI writes the code. You direct what gets built, verify what ships, and end the month with a deployed tool you actually understand. No prior coding experience assumed — just the patience to follow along and the honesty to check your own work as it builds.

23
Segments
4
Weeks
1
Deployed tool
What you'll have by the end of Week 4
A real AI-powered tool, deployed on the public internet, at a URL you can share
A GitHub repo you own, with a readable README and a live-demo link
Working knowledge of the stack underneath: HTML, CSS, JS, Git, Netlify, Cloudflare Workers, the Claude API
A repeatable pattern for turning any future AI idea into a shipped, sector-specific tool
The habits — testing, key security, error handling — that keep AI tools safe to let loose on real users
No hand-waving, no boilerplate copy-paste — you'll actually know what each line does before it ships
Transparency note. Course content was drafted with AI assistance and editorially reviewed in-house. The full methodology is published openly on the EverythingThreads website.
© 2026 EverythingThreads · ICO: C1896585 · Privacy · Terms
Chapter 1 of 4

Environment

Your foundation. Editor, terminal, version control, your first live website.

01What You're About to Build
02Setting Up VS Code
03The Terminal — It's Just a Text Box
04Git & GitHub — Your Safety Net
05Node.js & Python — Your Two Languages
06DNS, Hosting & Deployment — How the Internet Works
07Your First Live Website
Before we start

Personalise your BUILD course

<30 sec• Two picks• You can change later

The 23 segments are identical either way. Personalised retunes every example, case study, quiz feedback, and AI–coach reply to your role and sector. Pick once, then run the course.

— or —
Need to set language, use-category, or other prefs? → Full personalisation (opens setup wizard)
Before Segment 1 · Foundation

How This Course Actually Works

⏱ ~8 min• Read this first• Sets the frame for everything
The Frame

AI Clarity teaches the human overlay — the verification, judgement, and refusal AI can't do for itself — so you can direct AI safely instead of being directed by it. The AI writes the code. Your job is to know enough about the systems underneath that you can spot when AI is confidently wrong, and step in before it costs you.

In 4 weeks you'll have a deployed AI tool you own, and the verification habits to keep building safely without us.

Transparency note. Course content was drafted with AI assistance and editorially reviewed in-house. The full methodology is published openly on the EverythingThreads website.
AI TYPES.   YOU DIRECT.   YOU VERIFY.
That sentence runs every segment from here on. Commit it now.
Before Segment 1 · The Evidence

Why "Trust the AI" Isn't a Strategy

⏱ ~4 min• Real documented failures

These aren't edge cases. They happen to developers with years of experience. They'll happen to you. Knowing they exist is the protection.

Failure Mode 1
Hallucinated APIs
AI invents endpoint URLs that don't exist. The code looks perfect. It fails silently in production. Real example: a developer shipped a payment integration pointing to a fabricated Stripe endpoint — three months before anyone noticed no payments were processing.
Failure Mode 2
Hardcoded Secrets
45% of AI-generated code contains security flaws (Veracode 2025). The most common: API keys written directly into code files, then pushed to public GitHub repos. Bots scan for exposed keys within minutes of a push.
Failure Mode 3
Destructive Commands
Replit's AI assistant deleted a developer's production database despite an explicit "code freeze" instruction being active. AI followed the literal command it was given. Verification was the missing step.
Failure Mode 4
The Comprehension Gap
53% of teams who shipped vibe-coded apps later found vulnerabilities they couldn't fix — because the person who didn't write the code can't debug it. This course closes that gap. You'll understand what AI gives you.
Before Segment 1 · The Rule

The One Rule That Runs This Course

⏱ ~2 min• Commit this now
Every line AI writes gets a human eye before it ships.
Every command AI tells you to run, you read first.
Every package AI installs, you verify exists.
This is the entire course in one rule.

This rule doesn't slow you down. It's the difference between shipping once and shipping well every time after that.

In every segment that involves AI writing code, you'll see a ▲ VERIFICATION LAYER callout. That's the rule made specific for that exact moment.
Before Segment 1 · Working Modes

Your Four AI Working Modes

⏱ ~3 min• When to use which tool
Mode 1
🎤 Voice Notes
Use this when: you're thinking through architecture or stuck on a problem. Speak your thinking out loud. Transcribe it. Ask Claude to help you structure the idea before you write a single line.
Mode 2
🖥 Claude Desktop
Use this when: reviewing code, understanding what a segment does, asking "what does this line do?", or doing the verification check before you ship. Your main review loop.
Mode 3
⌨ Claude Code CLI
Use this when: making changes that touch multiple files, refactoring, or asking for large additions. It reads your actual project. Still runs through verification before you commit.
Mode 4
📱 Mobile
Use this when: away from your desk and you spot a small fix — a typo in copy, a quick config question, a clarification on what something does. Spot fixes only. Never ship from mobile without a desktop review.
Before Segment 1 · Honest Assessment

When Vibe Coding Works — and When It Kills You

⏱ ~3 min• No hype, no fear
✓ Works well
  • Throwaway prototypes and experiments
  • Learning — when you're reading every line
  • Internal tools with a tiny, trusted user base
  • Greenfield features where bugs are recoverable
  • Boilerplate you'd write identically anyway
⚠ Where it costs you
  • Real users with real data at stake
  • Anything involving money or payments
  • Regulated sectors: legal, medical, financial
  • Code you can't explain when it breaks
  • Authentication and permission systems
53% of teams who shipped vibe-coded apps found vulnerabilities afterward. The work of this course — reading what AI gives you, verifying before shipping — is what puts you in the other 47%.
Foundation Set
You have the frame. Now the course makes sense.
You're not learning to code.
You're learning to direct AI to code, and to verify what it produces.
Every segment from here on assumes that frame.
Segment 1 is the only one with nothing to install. From Segment 2, you build. Press next when you're ready.
Before you start · The practical bit

What You Need · How to Get Unstuck

⏱ 5 min read• Read this once, reference it all course

This course is self-paced. No live sessions, no Discord, no instructor on call. That works only if you know (a) the hardware and accounts you need before Segment 2, and (b) exactly what to do when something breaks. Both live on this slide. Come back to it any time you're stuck.

① What you need before Segment 2
Hardware
  • A laptop or desktop — not a Chromebook, iPad, or phone (they can't run the dev tools)
  • At least 8 GB RAM, 10 GB free disk
  • Admin rights to install software
  • Stable internet — downloads total ~2 GB across the course
Operating system
  • Windows 10 or newer
  • macOS 12 (Monterey) or newer
  • Linux — Ubuntu 20.04+ / Fedora / similar is fine
  • On corporate machines: check your IT team allows VS Code, Node, Git installs — some block them
Free accounts you'll create (all in Week 1)
GitHub · Netlify · Cloudflare · Anthropic Console. Every one is free — Anthropic gives starter credits that cover the whole course. You'll never need to enter payment details to complete BUILD.
Browser — use Chrome or Firefox
The course's DevTools segments assume Chrome or Firefox. Safari's DevTools work but the menus are in different places and the screenshots won't match — you'll spend time re-mapping instead of debugging. Install Chrome or Firefox for the course even if you use Safari day-to-day.
Work laptop · corporate network
Corporate firewalls often block npm install, pip install, and raw GitHub clones. If a download hangs or returns "certificate" / "ECONNREFUSED" errors, you're behind a proxy. Easier fix than wrestling with it: do the course on a personal machine, or tether to your phone's hotspot for the install steps. Ask Claude: "I'm on a corporate network and npm install is failing with [error]. What's the minimum config to make it work?"
② When something breaks · the 5-step flow
Every error you'll hit in this course has been hit by thousands of people before you. Run this flow before anything else:
1
Read the exact error message. Not "it didn't work" — the literal text. Copy it word-for-word. 90% of fixes live in the message itself.
2
Screenshot everything. Error message, terminal window, file structure. Win+Shift+S on Windows, Cmd+Shift+4 on Mac.
3
Paste into Claude desktop with context. "I'm on [OS], doing [segment X], tried [what you did], got [error]. Help me fix this without breaking anything else. Explain each step before I run it." That exact prompt works 80% of the time.
4
Verify before running. Claude will suggest commands. Read each one first — if it starts with sudo rm, curl … | bash, or you don't understand what it does, ask "what does this actually do?" before pressing enter.
5
Still stuck after 30 minutes? Walk away. Come back in 2 hours. Seriously — most "impossible" bugs are obvious after a break. The course isn't going anywhere, and the fix usually lands in the shower, not at the keyboard.
③ If you fall behind · and you will, at some point
The pacing says ~8–10 hours/week. For most people that's optimistic. Real life gets in the way. If you end Week 2 and you're finishing Week 1's segments, that's fine. The course doesn't expire. What matters is that you don't skip segments forward to "catch up" — every later segment assumes you did the earlier ones. Finish in order, even if it takes 8 weeks instead of 4. The deployed tool at the end is the same either way.
Keep this slide bookmarked. Press Ctrl+D (Windows) or Cmd+D (Mac) right now so you can jump back here from any segment when something breaks.
Segment 1 of 23 · Week 1
By the end of this segment you will be able toSee exactly what you will have built by Week 4 and understand the four working modes you will use to direct AI throughout the course.
See exactly what you will have built by Week 4 and understand the four working modes you will use to direct AI throughout the course.

What You're About to Build

⏱ ~25 min• No setup required• Understanding + 1 micro-challenge

Before we start, a word on what this course can and cannot deliver. If you commit to the four weeks, the likely outcome is a live website by the end of Week 1 and a working AI-powered tool you've built and deployed by the end of Week 4 — along with the verification habits that let you keep building safely after the course ends. What you get out of it depends on the work you put in. The course gives you the structure and the patterns; the practice is yours.

If you did SHARP Every Week-4 segment maps directly to a pattern you learned to read.
You're not just shipping code — you're shipping code that's hard to deceive. Here's how each BUILD hardening segment defends against a specific SHARP pattern you already know how to spot:
S22 Error Handling
→ defends against Confident Guess — don't let a plausible wrong response crash silently
S23 API Key Security
→ defends against the Caveat — AI mentions "remember to secure your keys" in comments then hardcodes them anyway
S24 Testing
→ defends against the Confident Guess — AI claims it works; you prove it does
S25 StreamingShowing AI responses word by word as they arrive, instead of waiting for the whole answer.
→ defends against the Caveat — real loading states instead of philosophical "I'm thinking" limbo
Didn't do SHARP? You can still complete BUILD — the code patterns stand alone. But the WHY behind every Week-4 segment is on SHARP's side of the curriculum. Consider doing both in sequence.
Let's address this first

"If AI can write code, why am I learning to build?"

Good question. Here's the answer: you're not learning to become a software developer. You're learning to build AI-powered tools that work for you. The people who understand how these systems connect — how APIs work, how to orchestrate multiple AIs, how to deploy and maintain tools — are the people who control AI instead of just using it.

In 2026, companies aren't looking for people who can write code from memory. They're looking for people who understand technology well enough to guide it, question it, and build with it. That's what this course teaches. In 4 weeks.

AI types. You direct. You verify.
That's the whole course in one line. AI writes most of the code. Your job is to know enough about the systems underneath that you can tell it what to build, read what it produces, and catch the moments when it's confidently wrong. The verification layer is the thing AI can't do for itself — and it's what makes the difference between shipping a tool and shipping a liability.
AI writing signatures
AI writing signatures identified
AI platform weakness analysis
AI platform weakness analysis
Real AI conversations: understanding what AI gets right — and what it gets wrong — is why you're here. Tap to expand.

Before you touch a keyboard, see where you're going. By Week 4, you will have built, deployed, and own all three of these:

Your Website
Live, deployed, your design. Dark theme, frosted-glass panels, mobile-responsive. Hosted for free on NetlifyA free hosting service. It takes your code from GitHub and puts it on the internet automatically.. Your URL, your brand.
Weeks 1-2
Your AI Tool
A working tool that sends input to AI APIs and displays analysed results. Like a professional AI analysis tool — but built by you, for your use case.
Week 2-3
Your Verification Habits
The muscle memory to read every line before shipping, rotate keys, test the five failure modes, and refuse a destructive command. The skills you keep after the course ends.
Every week

Right. That's the destination. Now let's start the journey. It begins with an editor — the place where you'll write every line of code for the next four weeks. It's free, it takes five minutes to install, and it's the same editor most professional developers use. Let's go.

These are not tutorials you follow and forget. You own everything. Your code, your deployment, your domain. When the course ends, your system keeps running. That's the difference between watching a tutorial and building something real.
Why this course — not YouTube, not freeCodeCamp, not The Odin Project
Free courses teach you to code
Generic curriculum
No AI-specific focus
No production deployment guidance
No sector application
No verification pedagogy
Self-directed, easy to quit
BUILD teaches you to build AI systems
AI-powered tools from Segment 11
Multi-model orchestration
Verification layer baked into every segment
Deployed and live by Week 2
Sector-specific applications
Self-paced with clear checkpoints

Here's everything you'll learn, and how it connects. The lit box shows where you are now. This diagram updates every segment — you'll always see your position in the system.

Your Complete Stack
You
Understanding the system
VS Code
Your editor
Terminal
Your command line
HTML / CSS / JS
Your code
GitHub
Version control
Netlify
Hosting (free)
Cloudflare Workers
API proxy (secure)
AI APIs
Claude · GPT · Gemini
Verification Layer
Your habits, not code
What You Need
A laptop or desktop (Windows, Mac, or Linux)
An internet connection
Google Chrome installed
Curiosity
You do NOT need: Any coding experience. Any technical background. Any maths. Expensive software. A powerful computer. This course teaches everything from scratch.
This Week: Your Environment (Segments 1-7) What you're about to build: VS Code → terminal → Git → Node & Python → hosting → your first live website. ~8–10 hours.
1 What You're About to Build — you are here
2 Setting Up VS Code
3 The Terminal — It's Just a Text Box
4 Git & GitHub — Your Safety Net
5 Node.js & Python — Your Two Languages
6 DNS, Hosting & Deployment
7 Your First Live Website •
~8–10 hours total · Go at your own pace within the week · Each segment ends with a checkpoint you can verify yourself
Micro-Challenge · 2 minutes

Before the next segment, do this one thing: right-click anywhere on this page and click "Inspect" (or press F12). A panel will open showing the code behind this page. Every element you see — every colour, every animation, every card — is made from HTML, CSS, and JavaScript. That's exactly what you're about to learn to build.

Look at the code for 30 seconds. It will look like gibberish right now. In 2 weeks, you'll be directing AI to write code like that — and you'll understand enough to spot when it's wrong.

The frame for the whole course

You're not learning to code. You're learning to direct AI to code — and to verify what it produces.

That distinction matters. A traditional coding course teaches you to type code from memory. By the end you'd be a junior developer. That's a two-year commitment, and in 2026, it's no longer the right investment for most people. AI writes most production code now. The economic value has shifted.

What this course teaches instead: how to read code well enough to direct AI toward the right thing, spot when it produces the wrong thing, and ship the result safely. Every segment from here on assumes that frame — you're not typing from memory, you're guiding AI and verifying every line before it goes live.

What this course is NOT
  • A computer-science degree
  • An exhaustive JavaScript / Python tutorial
  • A promise you'll never need help again
  • A replacement for reading when it matters
What it IS
  • A working AI tool you ship in 4 weeks
  • The verification habits to keep building safely
  • The 20% of code knowledge that covers 80% of what AI hands you
  • A foundation you own — the tool, the habits, the understanding
The working rule
Every line AI writes gets a human eye before it ships. Every command AI tells you to run, you read first. Every package AI installs, you verify exists. If that feels like a lot of work, it's the same amount of work as not doing it when something breaks in production. The difference is where the cost lands.
MOCK QUESTION — PRACTICE
Looking at the stack diagram — which component keeps your API keys secure so they're never exposed in your website code?
GitHub
GitHub stores your code — but API keys should never be in your code at all, even on GitHub.
Netlify
Netlify hosts your website, but it doesn't handle API key security for AI calls.
Cloudflare Workers
Correct. Cloudflare Workers run server-side code that holds your API keys securely. Your website calls the Worker, the Worker calls the AI API with the key. The key never touches the browser. You'll build this in Week 2.
VS Code
VS Code is your editor — it's where you write code on your computer, not where code runs online.
Segment Complete
You're building real skills. Keep going.
This is the only segment where you don't install anything. Starting from Segment 2, you build. Every segment after this has a "try it now" checkpoint and a troubleshooting guide if you get stuck. You're never on your own.
Coming from SHARP? How the 7 machine patterns carry into your AI pair-programming — same methodology, different surface.

Everything you learned about the 7 machine patterns applies to your own pair-programming now. AI will agree with your code (M1), confidently invent API endpoints that don't exist (M4), and tailor explanations to match how you talk instead of telling you what's actually true (M3). The same questions you asked in SHARP — "How do you know this?" and "Can you verify this in a fresh session?" — are now the questions you ask while you're writing code. The methodology doesn't get left behind. It comes with you.

AI writing patterns detected
AI writing patterns detected
Sycophancy callout in real conversation
Sycophancy callout
Sycophancy vs analytical alignment
Sycophancy vs analytical alignment
Real conversations showing M1 Agreement Trap and M3 Tailored Response in action. Tap to expand.
Segment 1 — What you mastered
  • The 4-week shape of BUILD and what ships at the end
  • Where this course sits in the AI Clarity ladder (CLEAR → SHARP → BUILD → SCALE)
  • Why the verification layer is the entire pedagogy
  • When to reach for voice notes vs Claude desktop vs Claude Code vs mobile
Quick recall — Segment 1
What is the one rule that governs every segment of BUILD?
Correct. Correct. AI does the typing; you do the directing and verifying. Every line, every command, every package.
Segment summary · Seg 1 · What You're About to Build You know what you're building and why. Execution starts now.
  • Every tool you build lives on a real URL — not localhost
  • VS Code, Terminal, Git, GitHub, Cloudflare — your five foundation tools
  • You own the code. You own the deployment. That's the difference.
  • BUILD is not tutorials you follow — it's a system you build and keep
Segment 1 · AI Workspace Setup

Set Up Your AI Workspace — Once

⏱ ~30 min• One-time setup• Used for every segment after this

You're going to set up your AI workspace once. Then you use it for every segment in this course — and for the rest of your career. The tools below aren't optional extras. They're the working environment this course was built around.

🖥
Claude Desktop
Review · Chat · Verify
Claude Code CLI
Edit · Refactor · Build
📋
CLAUDE.md
Rules · Context · Memory
The next slide walks you through each install step by step. Don't skip this. Students who skip the workspace setup spend 3× longer debugging in later segments.

Install Claude Desktop + Claude Code

⏱ ~20 min• Two installs• Then create your CLAUDE.md
Step 1 — Claude Desktop
Go to claude.ai/download. Download the desktop app for your OS. Sign in with your Claude account. This is your main AI review interface throughout the course.
claude.ai/download →
Step 2 — Claude Code CLI
Requires Node.js (you'll install this in Segment 5). Once Node is ready, run in your terminal:
npm install -g @anthropic-ai/claude-code
Then verify: claude --version should return a version number.
Claude Code docs →
Step 3 — Create Your CLAUDE.md
In your project root, create a file called CLAUDE.md. Paste the template from the next slide. This file tells Claude Code the rules it operates under for your project.

Your AI Workspace Diagram

• How the tools connect• Reference this throughout the course
💻
Your Laptop
Code lives here
Claude Desktop
Review + verify
Claude Code CLI
Edit + build
Mobile Claude
Spot fixes only
🗂
Your Project
VS Code editor
The same diagram appears throughout the course. Each segment "lights up" the part of this stack you're using. By Segment 11, all boxes are active.

Your CLAUDE.md Template

• Copy this into your project root• Edit it as the course progresses

CLAUDE.md is a file Claude Code reads automatically when you start a session in your project. It sets the rules AI operates under. Paste this template, then customise as needed:

CLAUDE.md — paste into your project root
# Project Rules for Claude Code

## The One Rule
Every line you write gets a human eye before it ships.
Every command you suggest, I read first.
Every package you recommend, I verify exists.

## Hard Limits
- Never run `rm -rf` without explicit, typed confirmation from me
- Never hardcode secrets, keys, or tokens in any file
- Never install packages without listing what they do first
- Never suggest overwriting files without showing me the diff
- If you are unsure about something — say so. Confidence without basis is worse than admitted uncertainty.

## Project Context
- Stack: HTML, CSS, JavaScript, Cloudflare Workers
- Deployment: Netlify (frontend) + Cloudflare (API layer)
- API keys: stored in Cloudflare env vars only — never in code

## Working Style
- Show me one step at a time
- After each step, tell me what to verify before moving on
- If I ask "what does this do?" — explain it to me before I run it
Segment 2 of 23 · Week 1
By the end of this segment you will be able toHave VS Code installed with the four extensions you need, the five settings that matter, and Claude Desktop + Claude Code wired into your workflow.
Have VS Code installed with the four extensions you need, the five settings that matter, and Claude Desktop + Claude Code wired into your workflow.

Setting Up VS Code

⏱ ~35 min⬡ Desktop required
▸ 30-second preview — where you're headingPicture this: you type a question into a text box on your website.
Picture this: you type a question into a text box on your website. You hit Send. Three seconds later, Claude's response appears below it. You wrote every line of that code in the editor you're about to install. That's Segment 11. This segment gets you the workspace.

VS Code is your editor — where you'll write everything. It's free, it runs on any operating system, and it's what most developers actually use day-to-day. By the end of this segment you'll have it installed, configured with four essential extensions, and set up with five beginner-friendly defaults. It takes about 20 minutes and you only do it once.

If you've used Sublime, Atom, or Notepad++ before and you're wondering why you should switch — VS Code has the best support for the tools we'll use throughout the course (live preview, terminal integration, git tracking), and all the code-along screenshots in BUILD use its interface. You'll save time by using the same editor the course shows.

A note on tools — your choice matters more than ours

This course uses VS Code, GitHub, Netlify, and Cloudflare Workers because they're free, beginner-friendly, and work well together. But they're not the only options. If you already use or prefer any of these alternatives, the concepts are identical — only the interface differs.

Code editors
Cursor · Sublime Text · WebStorm
Version control
GitLab · Bitbucket
Your Stack — You Are Here
Understanding
VS Code
Installing now
Terminal

The stack diagram is your map for the whole course — it updates every segment and shows you where you are in the system you're building. Think of it like a game minimap: you don't always need it, but when you get lost, glancing at it tells you instantly what you've already built and what comes next.

In Segment 1 you did the "Understanding" box — you saw the stack end-to-end before touching anything. Now you're lighting up the "VS Code" box, the editor that will hold every line of code you write for the next four weeks. After that comes the terminal, then git, then Node and Python, then hosting — one box per segment, until the whole row is solid.

Why the map matters. Most beginner courses make you open dozens of tabs and jump between them without ever showing you how the pieces fit together. By the end of Week 1 you'll have six boxes lit up — and you'll be able to explain, in plain English, what each one does and why it's there. That explanation is the thing that makes you an engineer, not just someone who followed instructions.
↳ AI Overlay
Don't just follow the install steps below. Open Claude desktop in another window and ask: "I'm on [Windows/Mac], walk me through installing VS Code from code.visualstudio.com/download and tell me which checkboxes to tick." Then verify each step before clicking. From here on, AI is your install partner — you read, you verify, you ship.
⏱ 30-Second Preview — This Is Where You're Heading

Picture this: you type a question in a text box on YOUR website. You hit Send. Three seconds later, Claude's response appears below it. You wrote every line of that code in the editor you're about to install. That's Segment 11. This segment gets you the workspace.

VS Code is your editor — where you'll write everything. It's free, it runs on any operating system, and it's what most developers actually use day-to-day. By the end of this segment, you'll have it installed, configured, and ready. This takes about 20 minutes and you only do it once.

Step 1: Download & Install
Click the big blue download button. It will detect your operating system automatically.
Windows
Run the downloaded .exe installer. Accept all defaults. Check "Add to PATH" when prompted — this is important.
Mac
Open the downloaded .dmg file. Drag VS Code into your Applications folder. Open it once from Applications.
Checkpoint
Can you open VS Code? You should see a Welcome tab with a dark interface.
Great — you're ready for Step 2.
Troubleshooting:
Windows: Try running the installer again as Administrator (right-click → Run as administrator)
Mac: If it says "unidentified developer," go to System Settings → Privacy & Security → click "Open Anyway"
Still stuck? Post in the course discussion with a screenshot of the error
Step 2: Install 4 Essential Extensions

Extensions add superpowers to VS Code. We'll install exactly 4 — no more, no less. These are the ones that matter for everything we'll build.

How to install an extension — step by step:
  1. Press Ctrl+Shift+X (or Cmd+Shift+X on Mac) — the Extensions panel opens on the left
  2. Type the extension name in the search box at the top
  3. Click the first result (check the author name matches below)
  4. Click Install — if a "Trust Publisher" dialog appears, click Trust Publisher & Install
  5. Repeat for each extension
  6. When all 4 are installed, close VS Code completely and reopen it — some extensions need a restart to activate

Can't find "Open with Live Server" after installing? Look at the bottom-right of VS Code for a Go Live button in the blue status bar. Click that instead. If neither appears, restart VS Code one more time.

To get back to your files after installing: Click the Explorer icon — the top icon in the left sidebar (looks like two stacked files). Your folder and files will appear.

1. Live Server
What it does: Opens your HTML files in a browser that updates automatically when you save. No need to refresh manually — every change appears instantly. You'll use this dozens of times per week.
2. Prettier — Code Formatter
What it does: Automatically tidies your code when you save. Indentation, spacing, line breaks — all handled. Your code will always look clean and professional, even as a beginner.
3. GitLens
What it does: Shows who changed each line of code and when. You won't need this immediately, but when you start working with Git in Segment 4, this becomes essential. Install it now.
4. HTML CSS Support
What it does: Gives you autocomplete suggestions when writing HTML and CSS. Start typing a tag or property and VS Code will suggest the rest. Saves time and prevents typos.
Common trap: .html.txt files. Windows hides file extensions by default. You think you saved index.html but Windows added .txt on the end, making it index.html.txt. If your page shows a file listing instead of your website, this is why. Fix: In VS Code, right-click the file → Rename → remove the .txt so it ends in just .html. Always check the file type dropdown says "HTML" when saving.
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
SHARP M3 The Tailored Response.AI will happily adapt its suggestions to whatever 'sophisticated' language you use.
AI will happily adapt its suggestions to whatever 'sophisticated' language you use. Call yourself 'a full-stack engineer' and it'll suggest patterns suitable for one; say 'I'm new to this' and it'll suggest different patterns. Same task. Same code. Different answers based on your register. That's M3 The Tailored Response — and it means the output is tuned to your personality, not to what's actually correct for your code.
▸ Try it now · 2 minOpen your terminal and verify your install.
Open VS Code's terminal (Ctrl+` / Cmd+`). Type code --version and press Enter. You should see three lines of version info. If you get 'command not found', open the Command Palette (Ctrl+Shift+P / Cmd+Shift+P), type 'shell command', and select Install 'code' command in PATH. Re-test.
Checkpoint
In VS Code, press Ctrl+Shift+X. Can you see all 4 extensions listed as "installed" with a gear icon next to each?
Perfect. Four extensions — that's all you need to start.
Troubleshooting:
• Make sure you're searching the exact name (e.g., "Live Server" by Ritwick Dey)
• If the Install button is greyed out, try restarting VS Code
• Check your internet connection — extensions download from Microsoft's servers
Step 3: Configure Beginner-Friendly Settings

VS Code has hundreds of settings. We'll change exactly 5. These are the ones that make the biggest difference for new developers — based on what the most successful coding courses recommend in 2026.

Press Ctrl+, (comma) to open Settings. Use the search bar at the top to find each setting:

1. Auto Save: Search "auto save" → set to afterDelay
Your files save automatically. You'll never lose work because you forgot to press Ctrl+S.
2. Format On Save: Search "format on save" → check the box •
Prettier automatically tidies your code every time you save. Clean code, zero effort.
3. Word Wrap: Search "word wrap" → set to on
Long lines of text wrap instead of scrolling off screen. Much easier to read.
4. Bracket Pair Colorization: Search "bracket pair" → ensure it's enabled (it's on by default in 2026)
Matching brackets get the same colour. Helps you see where blocks of code begin and end.
5. Theme: Search "color theme" → choose Dark+ or any dark theme you like
Easier on the eyes during long sessions. Most developers use dark themes — and all our examples use dark backgrounds.

Five settings, no more. I promise I won't make you configure anything else for at least two more segments.

Step 4: Know the 5 Areas of VS Code

VS Code has 5 main areas. You don't need to memorise them — just know they exist so nothing surprises you.

Explorer
Your files & folders (left sidebar)
Editor
Where you write code (centre)
Terminal
Command line (bottom panel)
Extensions
Add-ons (left sidebar)
Command Palette
Ctrl+Shift+P
The Command Palette is your secret weapon. Press Ctrl+Shift+P and you can search for ANY action in VS Code. Forgot where a setting is? Command Palette. Want to change the theme? Command Palette. Want to install an extension? Command Palette. It's the one shortcut to remember above all others.
A Note on AI Code Assistants

VS Code now has AI coding assistants built in — GitHub Copilot being the most popular. These tools suggest code as you type, and they can be genuinely helpful.

Some courses tell you to disable them entirely for learning. We disagree — but with a condition.

If you completed CLEAR or SHARP, you already know the patterns: AI agrees with you, AI sounds confident without basis, AI calibrates to what you want. The same patterns apply to code suggestions. Copilot will suggest code that LOOKS right. Your job — the same job from the earlier courses — is to understand what it's suggesting before you accept it. Use it. But verify it. Same principles. Different context.

MOCK QUESTION — PRACTICE
You've just installed VS Code and 4 extensions. Which keyboard shortcut opens the Command Palette — the search bar that lets you find ANY action in VS Code?
Ctrl+Shift+X
Close — that opens the Extensions panel. Useful, but not the Command Palette. You're in the right neighbourhood though.
Ctrl+Shift+P
Correct. The Command Palette is the single most important shortcut in VS Code. It lets you search for ANY action — settings, themes, commands, extensions, everything. If you only remember one shortcut, this is the one.
Ctrl+,
This opens Settings — useful for changing configuration, but not the Command Palette.
Ctrl+`
This opens the integrated terminal — you'll learn this in Segment 3. But it's not the Command Palette.
Segment Complete
Ready for the next segment.
Shortcuts you've learned so far:
Ctrl+Shift+P — Command Palette (find anything)
Ctrl+Shift+X — Extensions panel
Ctrl+, — Settings
Ctrl+` — Terminal (next segment!)
Mac users: Everywhere this course says Ctrl, you use Cmd instead. Everything else is the same.
Segment 2 — What you mastered
  • VS Code installed, signed in, theme picked
  • Live Server, Prettier, GitLens, HTML CSS Support extensions added
  • Auto Save, Format On Save, Word Wrap, Bracket Pair Colors, Font Size configured
  • Claude Desktop installed and your CLAUDE.md template in place
Quick recall — Segment 2
Why do we install Prettier and turn on Format On Save in the same step?
Correct. Correct. Removing the friction is the point. You write, you save, the code comes out clean. That energy goes to thinking instead of formatting.
Segment summary · Seg 2 · Setting Up VS Code Your editor is configured. You can read, write, and navigate code.
  • VS Code is where all your code lives — extensions make it smart
  • The file explorer, editor pane, terminal panel — three areas, one tool
  • Extensions: Prettier (format), ESLint (catch errors), Live Server (preview)
  • Keyboard shortcuts: Ctrl+` (terminal), Ctrl+Shift+P (command palette), Ctrl+S (save)
Segment 3 of 23 · Week 1
By the end of this segment you will be able toRun eight terminal commands fluently, recognise the dangerous ones AI might suggest, and have the muscle memory to refuse a destructive command before running it.
Run eight terminal commands fluently, recognise the dangerous ones AI might suggest, and have the muscle memory to refuse a destructive command before running it.

The Terminal — It's Just a Text Box

⏱ ~35 min⬡ Desktop required
▸ 30-second preview — where you're headingIn a terminal you type three characters: pwd (what directory am I in?), ls (what's in here?), cd (move into...
In a terminal you type three characters: pwd (what directory am I in?), ls (what's in here?), cd (move into a folder). That's 80% of what professional developers do all day. By the end of this segment those three commands will feel as normal as Ctrl+S.

The terminal is the part of the course that trips beginners up most often — not because it's hard, but because it looks hostile. A black box. A blinking cursor. No icons, no menus, no "Are you sure?" dialogs. That's the first thing to fix: the terminal is just a text box where you type a command and press Enter. Nothing more.

Throughout Week 2 and the rest of the course you'll use the terminal to run servers, pushUpload your local commits to GitHub. Makes your code available in the cloud. code to GitHub, install packages, and deploy. Every step is guided, every command is explained, and every error is survivable — the terminal has never broken anyone's computer by accident.

Read every command before you run it. This is the segment where the human-overlay rule first becomes critica…
This is the segment where the human-overlay rule first becomes critical.
AI will tell you to type things into your terminal. Some of those things are dangerous. The terminal does exactly what you tell it — there is no "are you sure?" dialog for most commands. Read every command before you run it. If it starts with rm -rf, sudo, or curl ... | bash — stop and ask "what does this do?" in a fresh chat before running.
↳ The silent killer · copy-paste gotchas
When you paste a command from a website, PDF, or a chat window, three invisible things can break it — and the error messages won't tell you which:
  • Smart quotes" vs " and ' vs '. Looks identical. Shells reject the curly ones. Chat apps, Word, and some PDFs convert your quotes silently. If you see syntax error or unexpected token and your command looks right — this is usually it.
  • Invisible Unicode characters — non-breaking spaces, zero-width joiners. Copying from styled text can sneak these in. Fix: retype the command, don't paste.
  • Line-ending mismatch (Windows only) — files edited in Notepad use CRLF, shell scripts expect LF. If a script errors on the first line, this is why. VS Code fixes it: bottom-right corner, click CRLF → switch to LF.
Rule of thumb: use the Copy button in this course's code blocks when it's there — those send plain text. When you have to paste from elsewhere and things break mysteriously, type the command by hand instead. Two seconds of typing beats twenty minutes of debugging invisible characters.
Your Stack — You Are Here
Understanding
VS Code
Terminal
Learning now

Two boxes behind you (Understanding + VS Code), one box lighting up now (Terminal), and the rest of the stack waiting. The pattern of the course is the pattern of this diagram — one thing at a time, each one unlocking the next, none of them skippable.

The terminal is the box that earns the most fear and deserves the least. Every real developer uses it dozens of times a day, and none of them are inventing new syntax — they're running the same eight commands on different projects. Those eight commands are the ones you're about to learn.

Why the terminal and not a GUI tool? Because the same commands that run on your laptop run on every server, every cloud deployment, every CI pipeline, every teammate's machine. A GUI tool gives you a button for one thing in one place. The terminal gives you a universal language that works everywhere you'll ever ship code.

Let's get this out of the way.

I'm going to be honest — the first time I opened a terminal I stared at it for about thirty seconds, typed nothing, and closed it. That blinking cursor felt like it was judging me. It wasn't. It was just waiting.

Here's what nobody tells beginners: if you type a wrong command, you get an error message. Nothing explodes. Nothing gets deleted. The terminal says "command not found" and waits patiently for you to try again. I typed a lot of wrong commands. My computer survived all of them.

The terminal is just a text box where you type instructions for your computer. You've been typing instructions into Google for years — this is the same concept, pointed at your own machine instead of the internet.

Step 1: Open the Terminal Inside VS Code

Remember the shortcut we previewed at the end of Segment 2? Now you'll use it for real.

Open VS Code. Press Ctrl+` (that's the backtick key — top-left of your keyboard, next to the 1 key). On Mac: Cmd+`. A panel will open at the bottom of VS Code. That's the terminal.

You'll see a blinking cursor after some text. On Windows it might say PS C:\Users\YourName>. On Mac it might say yourname@MacBook %. Don't worry about what it says — that text just tells you where you are on your computer.

Checkpoint
Can you see a blinking cursor in a panel at the bottom of VS Code?
That blinking cursor is your terminal. Everything you type here goes directly to your computer. Let's try your first command.
Step 2: Prove To Yourself It's Safe

Type this exact nonsense into your terminal and press Enter:

— zsh — you@build: ~
interactive
you@build ~ $
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
✗ Myth
The terminal is for advanced developers. Normal people use GUIs.
✓ Reality
The terminal is a text box that runs commands. Once you know 10 commands, it's faster than any GUI for everything you'll do in this course.
Terminal
asdfghjkl

What happened? You got an error message — something like 'asdfghjkl' is not recognized or command not found: asdfghjkl. And then nothing. Your computer is fine. Your files are fine. The terminal just said "I don't understand" and waited for you to try again.

This is the most important lesson in this segment. This is the most important lesson in this segment. The terminal i…
This is the most important lesson in this segment. The terminal is safe. Wrong commands produce error messages, not disasters. The only genuinely dangerous command is rm (remove files permanently) — and we'll teach you exactly when and how to use it safely.
Step 3: The 8 Commands You'll Actually Use

The terminal has hundreds of commands. You need 8. Here they are, with a "try it now" exercise for each:

pwd
Print Working Directory
What it does: Shows you where you currently are on your computer. Like checking the address on a map.
Try it
pwd
Windows equivalent: the path is already shown in your prompt, but you can type cd alone to see it.
SHARP M7 The Fold.When you try a terminal command and it errors, and you paste the error into an AI, the AI will often instantly...
When you try a terminal command and it errors, and you paste the error into an AI, the AI will often instantly pivot to a completely different solution. That's The Fold (M7) — capitulation without new reasoning. Don't accept the first pivot. Ask: 'Why would the original command be wrong in my specific setup?' Half the time, the original command was fine and the AI just flinched.
AI caught in Retraction Boundary Navigation
AI caught navigating boundaries instead of being direct
Real example: AI caught navigating internal boundaries instead of being direct. Tap to expand.
▸ Try it now · 1 minRun your first three commands.
In your terminal, run these one at a time and read each output before running the next: pwd (where am I?) → ls (what's here?) → cd ~ (go home). If any feels mysterious, ask Claude: 'I just ran [command] and got [output]. What does this mean?'

Your second essential command. ls answers "what's in here?". You'll type this several hundred times over the next four weeks until it becomes a reflex — every time you change folders, you'll instinctively run ls to see what's there.

ls
List files
What it does: Shows all files and folders in your current location. Like opening a folder in File Explorer.
Try it (Mac/Git Bash)
ls
Windows PowerShell: ls also works. Or use dir.

cd is how you move around the file system without leaving your chair. It's the command-line equivalent of double-clicking folders in File Explorer or Finder — but faster, scriptable, and the same everywhere you'll ever deploy code.

cd foldername
Change Directory
What it does: Moves you into a folder. Like double-clicking a folder in File Explorer. Use cd .. to go back up one level.

Before you create your first project folder, practise navigating into and out of existing folders. cd Desktop and then cd .. is the minimum drill — it proves you can move in, out, and back without getting lost.

Try it
cd Desktop
Then type cd .. to go back. Works the same on all systems.

Your first "creation" command. mkdir creates a new folder on your computer from the terminal — no right-click, no File Explorer, just one command. Every project you'll build in the rest of this course starts with this.

mkdir foldername
Make Directory
What it does: Creates a new folder. This is how you'll create project folders.
Try it
mkdir my-first-project
Now type ls — you should see your new folder listed.

touch creates an empty file. Together with mkdir and cd, these three commands are how you build up any project structure from the command line. Every repositoryA project folder on GitHub. Contains all your code files and their history. you create for the rest of the course starts with this trio.

touch filename
Create a file
What it does: Creates an empty file. This is how you'll create HTML, CSS, and JS files.
Try it (Mac/Git Bash)
touch index.html
Windows PowerShell: use ni index.html (New-Item) or echo $null > index.html

This is the single command that links your terminal work to your editor. When you want to open a project in VS Code, you don't go File → Open Folder — you just type code . from inside the project folder. It's the bridge between Segment 2 (editor) and Segment 3 (terminal).

code .
⭐ Most important command
What it does: Opens the current folder in VS Code. The dot . means "this folder." You'll use this every single time you start working on a project.
Try it
# Move into your new folder, then open it in VS Code
cd my-first-project
code .
Mac users: if code doesn't work, open VS Code → Cmd+Shift+P → type "shell command" → click "Install 'code' command in PATH"

The final two commands in your starter set. clear is harmless housekeeping. rm is the one command in the terminal that can genuinely lose you work — so you learn it with the safety rules built in.

clear
Clear the screen
Clears all the text in the terminal. Doesn't delete anything — just gives you a clean screen. Use it whenever the terminal feels cluttered.
Try it
clear
Windows PowerShell: cls also works.
rm filename
• Use with care
What it does: Permanently deletes a file. No recycle bin. No undo. This is the ONE command to be careful with.
Rules: Only use rm on files you created yourself. Never use rm -rf / (this would attempt to delete everything). Always double-check the filename before pressing Enter.
Try it — on a test file only
# Create a throwaway file, then remove it
touch delete-me.txt
rm delete-me.txt
Windows PowerShell: use Remove-Item delete-me.txt
Pro Tip: Tab Completion

Start typing a folder or file name and press Tab. The terminal will auto-complete it for you. Try it: type cd my- then press Tab. It completes to cd my-first-project/. This saves enormous amounts of typing and prevents typos. Use it constantly.

Step 4: Put It All Together — The 60-Second Exercise

Six commands in order. Each one builds on the last. By the end, you'll have a real project folder on your Desktop, an empty HTML file inside it, and VS Code open on the whole thing — and you'll have done it without touching a single GUI.

Complete Exercise
# 1. Go to your Desktop
cd Desktop

# 2. Create a project folder
mkdir ai-project

# 3. Move into it
cd ai-project

# 4. Create your first file
touch index.html     # Mac/Git Bash
# ni index.html      # Windows PowerShell alternative

# 5. Check it's there
ls

# 6. Open it in VS Code
code .
Checkpoint
Did VS Code open showing a folder called "ai-project" with one file called "index.html" inside it?
You just created a project folder and a file using only the terminal — then opened it in VS Code. That's the workflow you'll use for every project in this course.

Right. Take a breath. That was a lot of new words for one segment. If your head's buzzing a bit — good. That means you're actually learning, not just scrolling. Grab a glass of water if you need one. I'll wait.

MOCK QUESTION — PRACTICE
You've created a project folder and you're inside it. Which command opens this folder in VS Code?
open vscode
This isn't a real command. The VS Code command is much shorter.
code .
There it is. The dot means "this folder." You'll type code . at the start of every project session from now until forever. It connects your terminal to your editor — two tools, one workflow. You'll be typing this in your sleep by Week 2.
start vscode .
Close — start is a Windows command for opening programs, but code . is the cross-platform VS Code command that works everywhere.
vscode --open
Not a real command. The VS Code CLI uses code, not vscode.
Segment Complete
Keep building.
Shortcuts you've learned so far:
Ctrl+` — Open terminal in VS Code
Tab — Auto-complete file/folder names
— Recall your last command (press repeatedly to go further back)
Ctrl+C — Cancel a running command (not copy — in terminal this stops things)
Quick reference card — save this mentally: pwd (where am I), ls (what's here), cd (go somewhere), mkdir (make folder), touch (make file), code . (open in VS Code), clear (clean up), rm (delete — carefully). That's the terminal.
• Where this is going

The terminal you just learned to use is the same one that will deploy your AI tools to the internet. In Segment 11, you'll type a command in this terminal that sends a message to Claude and gets a response back — through code you wrote. Every command you just practised gets you closer to that moment.

Segment 3 — What you mastered
  • pwd, ls, cd, mkdir, touch, mv, cp, rm — what each one does
  • Why rm -rf is the canonical 'AI hallucinated something destructive' moment
  • The read-before-you-run habit for any pasted command
  • Keyboard shortcuts that make terminal work fast
Quick recall — Segment 3
AI tells you to paste `sudo rm -rf ~/Documents/*` to 'clean up your workspace'. What is the correct response?
Correct. Correct. rm -rf with sudo and a wildcard is destructive in seconds. Refusal IS the verification layer working. Always read first.
Segment summary · Seg 3 · The Terminal The terminal is just a text box. You know the commands that matter.
  • cd, ls/dir, mkdir, touch/echo — navigation and file creation
  • The terminal is faster than a file explorer once you know it
  • Tab completion: stop typing at the first unique letters, hit Tab
  • Up arrow: repeat last command. Ctrl+C: stop a running process
Segment 4 of 23 · Week 1
By the end of this segment you will be able toHave a GitHub account, your first repository, and a working git add → commit → push loop that AI cannot accidentally undo for you.
Have a GitHub account, your first repository, and a working git add → commit → push loop that AI cannot accidentally undo for you.

Git & GitHub — Your Safety Net

⏱ ~40 min⬡ Desktop required
▸ 30-second preview — where you're headingAt the end of this segment your code lives in two places: on your laptop, and in a repository you own on Gi...
At the end of this segment your code lives in two places: on your laptop, and in a repository you own on GitHub. When you break something, one command rolls it back. When your laptop dies, one command restores everything. When you want to share code, you send a link. That's what git does.

Git is version control — the safety net every professional developer uses every day. It lets you take a snapshot of your code any time you want, and it lets you go back to any snapshot later. If you break something, one command undoes it. If you want to try an experiment, you can branch off and come back if it doesn't work. If your hard drive dies, your code is safe on GitHub.

GitHub is where those snapshots live on the internet. Think of git as the camera and GitHub as the photo album. You'll learn four commands — add, commitA save point. A snapshot of your code at a specific moment with a description of what changed., push, status — that cover roughly 80% of everything you'll ever do with git. Professional engineers use dozens more, but you don't need them to build and ship.

Your Stack — You Are Here
Understanding
VS Code
Terminal
HTML / CSS / JS
GitHub
Setting up now
Netlify

Three boxes behind you (Understanding, VS Code, Terminal), one lighting up (Git & GitHub), and the stack continues. Git is the first segment where tools start connecting: the terminal runs the commands, VS Code shows what's changed, GitHub stores the result. The pieces begin to function as a system, not as isolated tools.

By the end of this segment you'll have your first public GitHub repository with your real name on it. That's the thing employers, clients, and collaborators can click on. Everything you build for the rest of the course goes into repositories like this one, and they stay yours forever — the course ending doesn't delete them.

Why git feels pointless at first And why to trust it anyway — before you learn the hard way.
The first time you use git it feels like overkill. You could just save the file. Then, three weeks in, you change something, break the site, can't remember what the working version looked like, and spend an hour trying to piece it back together. One git revert would have fixed it in two seconds. That's the moment git stops feeling pointless.

Think of Git as save points in a video game.

⏱ 30-Second Preview

You'll change one line of your AI tool's system promptHidden instructions that control how the AI behaves. The user never sees them but they shape every response., type git push, and 30 seconds later the live version updates automatically. Break something? One command rolls it back. That's what Git gives you.

You're playing a game. Before you fight the boss, you save. If you die, you go back to the save point — you don't restart the whole game.

Git does this for your code. Every time you "commit," you create a save point. If you break something, you go back. Your entire history is preserved. You can never truly lose work if you're using Git.

GitHub is where your save points are stored online. Think of it as cloud backup for your code. It also enables deployment — Netlify reads your code from GitHub and puts your website online automatically.

Your Computer
Git tracks changes locally
GitHub
Stores your code online
Netlify
Deploys your website
Step 1: Create a GitHub Account
Go to github.com and sign up for a free account. Choose a professional username — this will be visible on your projects. Verify your email.
Step 2: Install Git
Windows
Download from git-scm.com. Run the installer. Accept all defaults. This also installs Git Bash — an alternative terminal.
Mac
Git is often pre-installed. Check by typing git --version in terminal. If it's not there, install Xcode Command Line Tools: xcode-select --install

After installing Git, you verify it with one command and then do a one-time configuration — tell Git who you are so it can label your save points with your name. You only ever do this once per machine; Git remembers from then on.

Verify Git is installed
git --version
# Should show something like: git version 2.43.0
Step 3: Tell Git Who You Are

Git needs your name and email to label your save points. Run these three commands (replace with YOUR details):

Configure Git
git config --global user.name "Your Name"
git config --global user.email "your@email.com"
git config --global init.defaultBranch main
The third command sets "main" as your default branch name — this is the 2026 standard.
↳ Verification habit — commit messages
When you start committing code, AI will happily write your commit messages for you. It will default to vague ones like "update files" or "fixes" — useless in 3 months when you're trying to find what changed. Demand specifics: what changed, why, what the intended outcome was. A good commit message is one sentence that a future-you (or a teammate) can read and immediately understand. Read every AI-suggested commit message before you accept it.
Step 4: The 4 Git Commands You'll Use 80% of the Time

Git has hundreds of commands. You need 4. These four cover about 80% of everything you'll ever do with version control:

git add .
"Stage everything" — prepares all your changes to be saved. The dot means "everything in this folder."
git commit -m "message"
"Save point" — creates a snapshot of your code right now, with a description of what you changed.
git push
"Upload" — sends your save points to GitHub so they're backed up online.
git status
"What's changed?" — shows which files have been modified since your last save point.
Step 5: Your First Repository

Let's create a repository (a tracked project), add a file, create a save point, and push it to GitHub. Use the "ai-project" folder from Segment 3:

SHARP M2 The Fake Admission.When AI responds 'Let me be honest with you…' with no substance — that's M2. Here's how to break it.
When you ask AI 'is my git history clean?' and get 'Let me be honest with you, there are some concerns…' followed by generic advice — that's The Fake Admission (M2). Performed humility with no substance. The honest question to ask instead: 'Specifically, which of my last 10 commits has an issue? Name one.'

Time to make your first commit. The four commands below turn your ai-project folder into a Git repository, stage the file you already created in Segment 3, and lock in your first save point. You'll practise them in the interactive terminal below — or copy and run them in your real terminal alongside.

Your First Git Workflow
# Make sure you're in your project folder
cd ~/Desktop/ai-project

# Turn this folder into a Git repository
git init

# Stage everything (your index.html file)
git add .

# Create your first save point
git commit -m "My first commit"
— zsh — you@build: ~/Desktop/ai-project
interactive
you@build ~/Desktop/ai-project $

Connecting your local folder to GitHub so your code lives in two places — your computer and the cloud.

1 Go to github.com/new
Open Chrome and go to github.com/new. If you're not logged in, you'll need to sign up first at github.com/signup — use your email or Google account.
2 Fill in the form
Repository name: type ai-project
Description: optional — leave blank or write "My first AI tool"
Public / Private: select Public — you'll share this as a portfolio piece later
Add a README: tick this box — it creates a starter file
.gitignore / license: leave both as "None"
3 Create and copy the URL
Click the green Create repository button. GitHub takes you to your new repo page. Click the green Code button and copy the URL — it looks like https://github.com/YOURUSERNAME/ai-project.git
4 Connect from your terminal
Go back to VS Code. In the terminal, type the two commands below — paste YOUR URL in the first one.
Connect & Push to GitHub
# Connect your local folder to GitHub (paste YOUR URL from GitHub)
git remote add origin https://github.com/YOURUSERNAME/ai-project.git

# Push your code to GitHub
git push -u origin main
⚠ Before your first push · create a Personal Access Token
GitHub stopped accepting your account password for git push in 2021. If you run git push and it asks for your GitHub password, pasting your normal password will fail. You need a Personal Access Token (PAT) — it looks like a long string and acts as your password for git commands. Generate it before you push, not after it fails:
  1. Go to github.com/settings/tokens (Settings → Developer settings → Personal access tokens → Tokens (classic))
  2. Click Generate new token (classic)
  3. Note: "BUILD course · my laptop". Expiration: 90 days (re-generate in Week 13 if you keep coding)
  4. Scopes: tick repo only (that's all you need for this course)
  5. Click Generate token — copy the token immediately and store it somewhere you can find it (password manager, or a note). You can't see it again after you close the page.
  6. When git push asks for username, enter your GitHub username. When it asks for password, paste the PAT (not your account password).
Windows users: Git Credential Manager will usually remember the PAT after the first successful push. Mac users: macOS Keychain does the same. You should only need to paste it once.
Checkpoint
Go to github.com/YOURUSERNAME/ai-project — can you see your index.html file listed there?
That's your code. On the internet. In a real repository with your name on it. Not bad for someone who didn't know what a terminal was two segments ago. From here, Netlify will read from GitHub and deploy your site automatically. You'll connect that in Segment 6.

Git feels like overkill right now. I know. You're saving files to a cloud service when you could just... save the file. But the moment something breaks — and it will — you'll type one command and everything rolls back. That's not a feature. That's a superpower.

From now on, your workflow is always: Write code → git add .git commit -m "what I changed"git push. Three commands. Every time. This becomes muscle memory within a week.
↳ If you work on more than one machine
Many people do the course on a laptop at home and a desktop at work (or phone / iPad as backup reading). The rule that keeps multi-device sane:
  • Start every session with git pull. Pulls down whatever the other machine pushed last. Forgetting this is how merge conflicts start.
  • End every session with git push. Even if you didn't finish — push your work-in-progress so the other machine has it.
  • If git pull reports a "merge conflict": don't panic. Git marks the conflicting lines in your file with <<<<<<< and ======= and >>>>>>>. Open the file in VS Code (which highlights conflicts visually), decide which version to keep, delete the markers, then git add .git commit -m "resolve conflict"git push. For anything complex: paste the whole conflict block into Claude desktop with "I'm on [OS], what should I keep?" — then verify the explanation before accepting.
If you're only on one machine the whole course, ignore this. If you switch devices later and things get weird — this is the first thing to check.
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
MOCK QUESTION — PRACTICE
You've been coding for an hour. You want to create a save point and upload it to GitHub. What's the correct sequence?
git push then git commit
Close, but reversed. You need to create the save point (commit) BEFORE you can upload it (push). Think: save the game, THEN backup to the cloud.
git add .git commit -m "message"git push
Correct. Stage → Commit → Push. Every time. add prepares your changes, commit saves them locally, push uploads them to GitHub. This three-step workflow will become second nature.
git save then git upload
These aren't real Git commands. The real ones are git add, git commit, and git push.
Just save the file in VS Code — Git does the rest automatically
Git doesn't auto-save. That's intentional — you CHOOSE when to create save points. This gives you control over what gets tracked and when. Auto-save (which you set up in S2) saves the file locally. Git tracks versions.
Segment Complete
Ready for the next segment.
I know, I know. One file in one folder. Git feels like overkill. Trust me on this one — future you will be extremely grateful to present you. In two weeks you'll have 20+ files and you'll accidentally break something at midnight. Git lets you undo it in one command. Give it two weeks. Then buy present-you a drink.
New shortcuts:
Ctrl+Shift+G — Opens the Git panel in VS Code (visual view of your changes)
in terminal — Recall last command (use this constantly with git add .git commitgit push)
Segment 4 — What you mastered
  • What Git does and why every project needs it
  • git init, add, commit, push — the four-command loop
  • GitHub account created and SSH or HTTPS auth configured
  • Your first repo pushed and visible at github.com/yourname/repo
Quick recall — Segment 4
Why does the course insist you write your own commit messages instead of letting AI write them?
Correct. Correct. Commit messages are a note to your future self. AI doesn't know which change mattered or why you made it.
Segment summary · Seg 4 · Git & GitHub Your code is saved, versioned, and in the cloud.
  • git init → git add . → git commit -m "message" → git push — the four-step loop
  • Git saves snapshots. GitHub stores them in the cloud. They're different things.
  • Commit messages: write what changed, not what you did ("Add submit button" not "Updated file")
  • .gitignore: files Git should never track (node_modules, .env, secrets)
Segment 5 of 23 · Week 1
By the end of this segment you will be able toHave Node.js and Python installed and verified, npm working, and the confidence to fix PATH errors when AI suggestions don't match your machine.
Have Node.js and Python installed and verified, npm working, and the confidence to fix PATH errors when AI suggestions don't match your machine.

Node.js & Python — Your Two Languages

⏱ ~35 min⬡ Desktop required
▸ 30-second preview — where you're headingTwo languages, one installation each.
Two languages, one installation each. Node.js runs JavaScript outside the browser, which means it can run build tools, dev servers, and your Cloudflare Workers. Python runs your AI SDK calls and automation scripts. You don't pick one over the other — you install both, because professional developers use both.

Node.js and Python are the two languages that power most of the AI tooling in 2026. Node.js is what runs the JavaScript build tools, the dev servers that let you preview your site locally, and the Cloudflare Workers you'll deploy in Segment 11. Python is what runs the official Anthropic SDK examples, most of the Jupyter notebooks you'll encounter online, and the automation scripts you'll write in Week 3.

This segment installs both and verifies each one works with a single test command. No writing code yet — that's Segments 8 through 10. This is the environment-building step: get the runtimes on your machine so every subsequent segment has the tools it needs to work. It takes about 20 minutes of waiting for installers and five minutes of checking that they worked.

Your Stack — You Are Here
Understanding
VS Code
Terminal
Node / Python
Installing now
GitHub
Netlify

Four boxes behind you now — Understanding, VS Code, Terminal, Git/GitHub — and the fifth lighting up: Node & Python. This is the last pure-installation segment. From Segment 6 onwards, the stack boxes represent the things you're actively using to build, not just the things you've set up.

Notice the stack is nearly half-lit. You're close to the moment when the environment stops being a pile of separate tools and starts behaving like one workshop. By the time you finish Week 1, all seven boxes are lit, and your first deployed website is live on the internet.

You do not need to choose between the two languages Every AI-adjacent engineer installs both. Here's why.
Every AI-adjacent engineer has both Node and Python installed because the ecosystem is split — some tools ship as Node packages, some as Python. Picking one and refusing the other just means the other half of the ecosystem is unavailable to you. Install both now and forget about it.

You don't need to learn to code in either language. I want to be clear about that before we go any further. You need to install them so your computer can run the tools that are written in them. Think of it like installing a DVD player — you don't need to know how to make DVDs, you just need the player so you can watch them.

Node.js
Runs JavaScript outside the browser. Powers web tools, servers, and build pipelines. You'll use it from Week 2 onwards.
Python
General-purpose language for scripts, automation, and data. Many AI tools and APIs have Python libraries. You'll use it for automation in Week 3.
Step 1: Install Node.js (LTS Version)
Go to nodejs.org
Click the big green LTS button (currently Node 24 "Krypton"). LTS means Long Term Support — it's the stable version that won't break. Don't click "Current" — that's for testing.
Windows
Run the .msi installer. Accept all defaults. It will also install npmNode Package Manager. An app store for code — type npm install and it downloads tools for you. automatically.
Mac
Run the .pkg installer. Or if you have Homebrew: brew install node

Two version checks in sequence — node and npm. Both should return numbers. If either errors with "command not found", the PATH did not pick up the new install and the fix is almost always to close the terminal and reopen it (which forces a PATH refresh). A reboot is the nuclear option but rarely necessary.

Verify Node.js is installed
node --version
# Should show: v24.x.x (any 24.x number is fine)

npm --version
# Should show: 11.x.x (npm comes with Node)
Checkpoint
Do both commands show version numbers?
Node.js and npm are installed. npm is your package manager — it installs tools and libraries that other developers have built. You'll use it constantly from Week 2.
▸ Read here — What is npm? Node Package Manager — the app store for code you'll use every week.
It stands for Node Package Manager. Think of it as an app store for code. When you type npm install something, it downloads code that someone else wrote and makes it available for your project. You'll use this to install tools, frameworks, and libraries throughout the course.
— zsh — you@build: ~
interactive
you@build ~ $
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
If something broke · the verification-first debug workflow

Node install failed? Don't panic. Screenshot, paste, verify.

This is the segment where Windows PATH issues hit hardest. If node --version prints an error instead of a version number — or python --version returns "command not found" on Windows — that's the #1 install issue people hit in this course. Don't Google it. Don't retry blindly. Do this instead:

The 4-step recovery
1
Screenshot the error
Exact error message, exact terminal path, the whole window. Windows: Win+Shift+S. Mac: Cmd+Shift+4. Save it somewhere you can find — Desktop is fine.
2
Open Claude desktop and paste the screenshot
Use this exact prompt — the specificity matters:

I'm on [Windows 11 / Mac / Linux]. I just installed Node.js using the LTS installer from nodejs.org. When I run `node --version` in a new terminal, I get this error [attached screenshot]. Help me fix it without breaking anything else on my system. Walk me through each step and tell me what it does before I run it.
3
Verify each step before running it
Claude might suggest editing your PATH environment variable, running an installer again, or using nvm. Before running any command, ask: "what does this actually do, and what happens if it goes wrong?" If Claude can't explain that clearly, don't run it.
4
Re-run node --version in a fresh terminal
Must be a new terminal window — the old one doesn't know about PATH changes. If the version prints, you're done. If it still fails, screenshot the new error and repeat from step 2. Don't skip the screenshot — the exact error message matters.
Why this is the most important habit in Week 1
This is the template for every debugging session in the whole course: screenshot the exact problem → paste with specific context → verify each suggested step before running it. Every future segment that asks you to "ask AI for help" is using this same pattern. Get comfortable with it here, because by Week 3 you'll be doing it without thinking.
Step 2: Install Python
Go to python.org/downloads
Click "Download Python 3.14.x" (the latest stable version). The site detects your OS automatically.
• CRITICAL — Windows Users Only
When the installer opens, check the box that says "Add Python to PATH" at the bottom of the first screen. If you miss this, Python won't be accessible from the terminal. This is the #1 beginner installation issue.
Windows
Run the installer. CHECK "Add Python to PATH". Click "Install Now". At the end, click "Disable path length limit" if prompted.
Mac
Run the .pkg installer. Or with Homebrew: brew install python. Python may already be installed — check first.
Verify Python is installed
python --version
# Should show: Python 3.14.x
# Mac/Linux users: try python3 --version if python doesn't work

pipPython Package Manager. Same idea as npm but for Python tools and libraries. --version
# Should show: pip 24.x or similar
# Mac/Linux: try pip3 --version
SHARP M4 The Confident Guess.When you ask AI 'is this Worker code secure?', it will confidently say yes or list generic security concerns that don't apply to your code.
When you ask AI 'is this Worker code secure?', it will confidently say yes or list generic security concerns that don't apply to your code. That's M4 — the Confident Guess. The honest version of the question: 'Name the single most likely way this specific Worker code could leak the API key. Don\'t list possibilities — pick the most probable one.'
Checkpoint
Do both python --version and pip --version show version numbers?
Python and pip are installed. pip is Python's package manager — same concept as npm, different language. You'll use it for automation scripts and some AI tools.
▸ Read here — What is pip? Python's package manager — same idea as npm, for AI SDKs and tools.
Same idea as npm, but for Python. pip install something downloads Python packages. The Anthropic SDK (for building with Claude), OpenAI SDK, and many AI tools are Python packages you'll install with pip.
When You'll Use Each
• Node.js (Weeks 2-4)
Running your website locally (Live Server)
Installing tools with npm
Browser tooling and beyond
Cloudflare Workers (serverless functions)
Build tools and automation
▪ Python (Week 3-4)
AI API SDKs (Anthropic, OpenAI)
Quick automation scripts
Data processing and analysis
Scheduled tasks and cron jobs
Backend tools if needed
You don't need to choose. Professional developers use both. Node.js is dominant for web tools, Python for AI and data. Having both installed means you can use any tool or tutorial you find online, regardless of which language it's written in.
MOCK QUESTION — PRACTICE
You find a tutorial online that says "Install the package by running npm install express." Which language does this package belong to?
Python
Python uses pip install, not npm install. npm is Node.js's package manager.
Node.js / JavaScript
Correct. npm is Node's package manager. If a tutorial says npm install, it's a JavaScript package. If it says pip install, it's Python. That's all you need to know to tell them apart.
Both
npm is specifically Node.js's package manager. Python has its own: pip. The command itself tells you which language the package belongs to.
Neither — it's a terminal command
npm IS a terminal command — but it's Node.js's terminal command specifically. Different languages have different package managers that all run in the terminal.
Segment Complete
Keep building.

Right. Deep breath. That was the heaviest setup segment — more installs in one sitting than most people do in a year. Fancy a breather? It's getting a bit much, I can feel it too. Here's the good news: you're done installing things. Segment 6 is understanding, Segment 7 is building. The heavy lifting is behind you.

Your installation checklist so far:
• VS Code (Segment 2)
• 4 extensions: Live Server, Prettier, GitLens, HTML CSS Support (Segment 2)
• Git (Segment 4)
• GitHub account (Segment 4)
• Node.js + npm (this segment)
• Python + pip (this segment)
⬜ Netlify account (next segment)
• Why you just did all that

Node.js is the engine that runs your AI tools. Here's what 4 lines of Node can do — you can't run this yet, but by Segment 11, you will:

const response = awaitPauses your code until a slow operation finishes. Used with fetch to wait for API responses. fetchA JavaScript function that sends a request to a server and gets a response. How your code talks to AI.('https://api.anthropic.com/v1/messages');
const data = await response.jsonA text format for structured data. Looks like a list of labels and values. Most APIs send and receive JSON.();
console.log(data.content[0].text);
// → "Hello! I'm Claude. How can I help you today?"

Four lines. Your code talks to an AI. That's where we're heading. The setup you just completed makes this possible.

Segment 5 — What you mastered
  • Why Node.js and Python both matter for this course
  • node --version and python --version both return real numbers
  • npm working — your package manager is online
  • What to do when an install errors out (screenshot, paste to Claude, verify each step)
Quick recall — Segment 5
After installing Node on Windows, `node --version` returns 'command not found'. What is the right next move?
Correct. Correct. Screenshots + context + verification beats panic-reinstalling. PATH issues are common and almost always fixable in 5 minutes.
Segment summary · Seg 5 · Node.js & Python You can run code outside the browser. npm install works without panicking.
  • Node.js runs JavaScript on your computer — not just in Chrome
  • npm is a package manager: npm install adds tools, node_modules holds them
  • Python: pip install, virtual environments — same idea, different language
  • Never commit node_modules or venv — they're reproducible from package.json/requirements.txt
Segment 6 of 23 · Week 1
By the end of this segment you will be able toUnderstand DNS, hosting, and deployment well enough to ship a static page from your laptop to a public URL via Netlify in under 10 minutes.
Understand DNS, hosting, and deployment well enough to ship a static page from your laptop to a public URL via Netlify in under 10 minutes.

DNS, Hosting & Deployment — How the Internet Works

⏱ ~30 min◎ Understanding + account setup
▸ 30-second preview — where you're headingYou type a domain name into a browser.
You type a domain name into a browser. A chain of lookups and routing happens in under 200 milliseconds and your page appears. In this segment you learn what each link in that chain is, then you use Netlify — a free hosting service — to put your own site at the other end of it.

DNS, hosting, and deployment are three topics that get lumped together under "how the internet works" and usually get skipped in beginner courses. We're not skipping them. Not because the detail is exciting — it isn't — but because every time something breaks on a deployed site, the root cause is almost always in the DNS or hosting layer, and if you don't understand those layers, you can't fix them.

The good news is that you only need the mental model, not the deep detail. By the end of this segment you'll understand DNS in roughly three sentences, hosting in one diagram, and deployment as a single pipeline — and you'll have a Netlify account set up ready for Segment 7, when you'll push your first site live.

Your Stack — You Are Here
HTML / CSS / JS
GitHub
Netlify
Setting up now

Five boxes behind you — Understanding, VS Code, Terminal, Git/GitHub, Node & Python — and the sixth lighting up: Netlify (hosting). This is the segment where the word "live" stops being theoretical. Segment 7 pushes code; Netlify picks it up automatically; your site appears on the internet in about thirty seconds.

After this segment, there are no more tools to install for Week 1. The stack is fully set up. Everything from Segment 7 onwards is about writing code, pushing it, and watching it run — the deployment pipeline runs itself, because you built it in this segment.

Why we use Netlify specifically Free tier, no credit card, automatic HTTPS, shortest path from git push to live URL.
Free tier, no credit card, automatic HTTPS, connects to GitHub out of the box, and the build pipeline is literally a checkbox. Other hosts (Vercel, Cloudflare Pages, Render, Fly.io) are fine too — we use Netlify because its path from "git push" to "live URL" is the shortest, which matters most for a beginner shipping their first thing.

Quick one before we build anything. You've got code on GitHub. Netlify is set up. But before we connect them in Segment 7, it helps to understand what actually happens when someone types a web address into their browser. Takes two minutes.

What Happens When You Type a Web Address
1. You type example.com
Your browser needs to find where this website lives.
2. DNS looks up the address
DNS is like a phone book. It converts "example.com" into a number (IP address) that computers understand.
3. The server sends your files
The server (Netlify, in our case) finds your HTML, CSS, and JS files and sends them to the browser.
4. Your browser renders the page
The browser reads the HTML (structure), applies the CSS (design), and runs the JS (interaction). You see the website.
This entire process takes less than 1 second.
The whole flow URL → DNS → server → browser. How every website in the world reaches you.
URL → DNS → server → browser. Every website in the world works this way. What Netlify does is handle the server part for you — for free. You push code to GitHub, Netlify picks it up, and serves it to anyone who visits your URL.
What Netlify Does for You
Auto-deploys
Push to GitHub → site updates in 30 seconds
Free HTTPS
SSL certificate included automatically
Global CDN
Content served from 100+ locations worldwide
Free Tier
100GB bandwidth, 300 build minutes/month
Your Deployment Pipeline (what you set up in S4 + this segment)
You write code
in VS Code
git push
to GitHub
Netlify detects
the push automatically
Site is live
in ~30 seconds
You never need to "upload" files or manage a server. Push to GitHub. Netlify handles the rest.
What happens when you type a web address
Click each node →
Click any step to learn what that layer actually does.
Step 1: Create Your Netlify Account
1. Go to app.netlify.com/signup
2. Click "Sign up with GitHub" — this connects the two accounts automatically
3. Authorise Netlify to access your GitHub (it needs this to detect when you push code)
4. You'll see your Netlify dashboard — empty for now. That changes in Segment 7.
Netlify token steps
Netlify token step-by-step walkthrough
Real walkthrough: getting a Netlify access token step by step. Tap to expand.
Checkpoint
Can you see your Netlify dashboard at app.netlify.com?
Your deployment pipeline is ready. In Segment 7, you'll push code to GitHub and watch Netlify deploy it live. That's the most exciting moment in the course.
⚠ Netlify credits — read before you push code
  • Every git push = 1 build = credits used
  • Auto-deploy is ON by default — stop it while developing
  • Stop builds: Site config → Build & deploy → Stop builds
  • Only turn back on when a batch of changes is ready
  • Extra credits: ~$5 for 500. Check balance at app.netlify.com
Your complete environment is now set up VS Code + Terminal + Git/GitHub + Node.js + Python + Netlify. The full stack.
VS Code (editor) + Terminal (commands) + Git/GitHub (version control) + Node.js (JavaScript runtime) + Python (scripting) + Netlify (hosting). That's the full stack. Segment 7 puts it all together: you'll build a page, push it to GitHub, and watch it appear live on the internet. From your computer to the world in 30 seconds. This is the same pipeline your AI tools will use — the deployment step doesn't change when the code gets smarter.

DNS and hosting aren't sexy topics. I get it. But understanding how the internet actually delivers your website to someone's browser — that's the kind of knowledge that separates people who build things from people who use things other people built. Two more minutes and you'll have it.

▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
MOCK QUESTION — PRACTICE
You change a line of CSS on your website, save the file, and run git add . && git commit -m "fixed colour" && git push. What happens next?
Nothing — you need to upload the file to Netlify manually
That's the old way (FTP, manual upload). With Netlify's continuous deployment, you never upload manually. Git push is all it takes.
Netlify detects the push, rebuilds, and your live site updates automatically in ~30 seconds
Exactly. That's continuous deployment. Push to GitHub → Netlify detects → site updates. You never touch a server. You never upload files. You just push. This workflow is what professional developers use — and it's what you'll use from Segment 7 onwards.
You need to run a deploy command in Netlify
You CAN use the Netlify CLI for manual deploys, but with the GitHub integration, you don't need to. Push to GitHub is enough — Netlify watches for changes automatically.
The change only appears on GitHub, not on your live website
If Netlify is connected to your GitHub repo (which we just set up), it deploys automatically. The change appears both on GitHub AND on your live site.
Next segment is the one you've been waiting for. Six segments of setup. Six segments of "trust me, this matters." Segment 7 is the payoff. You're going to push code to GitHub, Netlify is going to pick it up, and you're going to visit a URL and see YOUR website — live, on the actual internet. I still remember the first time I did it. It never gets old.
• Myth vs Reality
Myth: "You need to pay for hosting to have a real website."
Reality: Netlify's free tier gives you 100GB bandwidth and 300 build minutes per month. That's enough for thousands of visitors. The AI tools you'll build in this course will run on free infrastructure — Netlify for hosting, Cloudflare Workers for the API proxy. Professional architecture, zero hosting cost.
Segment 6 — What you mastered
  • What DNS does (your domain → an IP address)
  • What hosting is and why Netlify's free tier covers you for the whole course
  • Drag-and-drop deploy: laptop → Netlify → live URL
  • Why custom domains can wait until after the course
Quick recall — Segment 6
Your friend types yourname.netlify.app into their browser. What is the FIRST thing that has to happen for them to see your page?
Correct. Correct. DNS is the phone book. No DNS, no connection. Then Netlify serves the HTML.
Segment summary · Seg 6 · DNS, Hosting & Deployment You understand how your code gets from your laptop to a URL.
  • DNS: domain names map to IP addresses — like a phone book for the internet
  • Netlify: drag a folder, get a URL. Connect GitHub, get auto-deploys.
  • HTTPS: free via Netlify/Cloudflare. Unencrypted HTTP is never acceptable.
  • Deployment is not magic — it's file serving + DNS + a CDN
Segment 7 of 23 · Week 1
By the end of this segment you will be able toHave a real, deployed website live on the internet — and the deploy loop is so muscle-memory you can ship a fix in under 60 seconds.
Have a real, deployed website live on the internet — and the deploy loop is so muscle-memory you can ship a fix in under 60 seconds.

Your First Live Website

⏱ ~40 min⬡ Desktop required• Week 1 quiz gate
▸ 30-second preview — where you're headingYou write four lines of HTML, press git add, git commit, git push.
You write four lines of HTML, press git add, git commit, git push. Thirty seconds later, a URL Netlify gave you loads on your phone, on your friend's phone, and on a stranger's phone halfway around the world. The internet isn't a concept anymore — it's just a place your code lives.

This is the segment the whole first week has been building towards. All the setup you've done — installing VS Code, learning the terminal, connecting git, setting up Node, creating a Netlify account — was preparation for this moment. You write HTML, push it to GitHub, and Netlify deploys it live. No extra steps. No configuration files. Just the pipeline the earlier segments put in place, running on its own.

You don't need to understand every line of HTML yet — that's Segment 8. For now the goal is to close the loop from "code on my laptop" to "live on the internet" in one continuous flow. Once you've done it once, it stops feeling magical and starts feeling routine, and that routineness is the thing that lets you build everything that comes after.

SHARP M4 check.When your first deploy works, AI tools will offer to "optimise" it or "add best practices".
When your first deploy works, AI tools will offer to "optimise" it or "add best practices". Most of those suggestions are confident guesses (M4) — invented advice that sounds right but doesn't match your stack. The rule for this week: ship the working version first, then ask "how do you know this?" before accepting any optimisation. Your site being live is more important than your site being clever.
AI offering unsolicited optimization
AI offering unsolicited rewrite suggestions
Real example: AI offering to rewrite and "improve" without being asked. Tap to expand.
Your Stack — Everything Connects
VS Code
Terminal
GitHub
Netlify
Deploying now

This is the one. Six segments of setup. Six segments of trust. Here's where it all comes together. You're going to write some HTML, push it to GitHub, connect Netlify, and visit a URL that shows YOUR website. Live. On the actual internet. Ready?

Write Your First HTML Page
1 Open your project in VS Code
Open VS Code. Click File → Open Folder. Navigate to Desktop → ai-project and click Open.
2 Open index.html
In the left sidebar (Explorer panel), click index.html to open it. If you can't see the sidebar, click the Explorer icon (top-left, looks like two stacked files).
3 Replace the contents
Select everything (Ctrl+A), delete it, then copy the code from the next slide and paste it (Ctrl+V). Save (Ctrl+S).
4 Open in browser
Right-click index.html in the left sidebar → Open with Live Server. If you don't see that option, look for Go Live in the blue bar at the bottom of VS Code. Your browser opens showing your page — every save auto-refreshes.
index.html — Your first webpage
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My First Website</title>
  <style>
    /* Dark theme — looks professional from the start */
    body {
      background: #0b0b0c;
      color: #f3efe9;
      font-family: -apple-system, sans-serif;
      display: flex;
      justify-content: center;
      align-items: center;
      min-height: 100vh;
      margin: 0;
    }
    .card {
      text-align: center;
      padding: 48px;
      max-width: 500px;
    }
    h1 { font-size: 2.5rem; margin-bottom: 12px; }
    p { color: rgba(243,239,233,.6); line-height: 1.7; }
  </style>
</head>
<body>
  <div class="card">
    <h1>Hello, World.</h1>
    <p>I built this. From scratch. And it's live on the internet.</p>
  </div>
</body>
</html>
▸ Read here — Don't worry about understanding every line yet That's Segment 8. Right now the goal is: write code → push it → see it live.
That's Segment 8. Right now, the goal is: write code → push it → see it live. You'll learn what each piece does starting next week. For now, just paste it and save.
Step 2: Preview It Locally

Right-click your index.html file in VS Code's explorer panel. Click "Open with Live Server" (that's the extension from Segment 2). A browser tab should open showing your page — dark background, white text, centred on the screen.

Checkpoint
Can you see "Hello, World." in your browser on a dark background?
That's your code running in the browser. Right now it's only on your machine. Let's put it on the internet — and once it's there, it's the same site that will host your AI tools from Segment 11 onwards.
Step 3: Push to GitHub

You know this workflow now. Open the terminal (Ctrl+`) and run:

The workflow you'll use forever
git add .
git commit -m "My first real webpage"
git push

Three commands. Every time. This is already becoming muscle memory.

▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
Step 4: Connect Netlify to Your Repository
1. Go to app.netlify.com (you logged in during Segment 6)
2. Click "Add new project""Import an existing project"
3. Click "GitHub"
4. Find and select your ai-project repository
5. Leave all settings as default — Netlify detects it's a static HTML site
6. Click "Deploy"

Wait about 30 seconds. Netlify will show "Published" with a green checkmark. You'll see a URL that looks something like random-name-12345.netlify.app.

⚠ If deploy fails or the URL shows a blank page / 404
  • "Deploy failed" in red — click the failed deploy in the Deploys tab to see the build log. For a plain HTML site the build command must stay empty and Publish directory must be /. If Netlify auto-guessed npm run build, clear it: Site settings → Build & deploy → Build command (leave blank) → Save.
  • Live URL shows "Page not found" — your index.html isn't at the repo root. Check GitHub: the file must be directly in the repo, not inside a subfolder. If it's in a subfolder, set Publish directory to that folder name (e.g. public or site).
  • Deploy succeeds but the page is blank — open DevTools → Console (F12). You'll usually see a 404 for a missing CSS/JS file. Netlify paths are case-sensitive; Styles.css and styles.css are different files. Rename to match exactly.
  • Push happened but Netlify didn't rebuild — check the Deploys tab for your latest commit SHA. If it's not there, the GitHub webhook is broken: Site settings → Build & deploy → Continuous deployment → Link repository to reconnect.
The build log tells the truth. Always click into it before guessing — 80% of deploy failures are explained in the last 5 lines.
Step 5: Visit Your Live URL

Click the URL Netlify gave you.

Open it on your phone. Send it to a friend. Open it in a different browser. It works everywhere. Because it's on the internet. Your code. Your design. Your URL.

— zsh — you@build: ~/Desktop/ai-project
interactive
you@build ~/Desktop/ai-project $
Checkpoint — The Big One
Can you see your "Hello, World." page at a .netlify.app URL — accessible from any device?
That's your website. On the actual internet. Built from an empty folder, pushed through GitHub, deployed by Netlify — in under 10 minutes. Send that link to someone. Go on. You've earned it.

I'm not going to pretend this wasn't a lot of work to get here. Six segments of setup. You installed VS Code, learned the terminal, set up Git, created a GitHub account, installed Node.js, installed Python, created a Netlify account. And now you've got a live website. That's Week 1 done. Properly done.
Bonus: Change Your Site Name

That random URL isn't great. In Netlify: Site settings → Change site name. Type something you like — it becomes your-chosen-name.netlify.app. Free. Instant.

SHARP M6 The Redirect.After your first successful deploy, if you ask AI 'my site works but looks bland — what should I do?' it often...
After your first successful deploy, if you ask AI 'my site works but looks bland — what should I do?' it often redirects to 'Well, there are many approaches to modern web design…' without answering. That's The Redirect (M6). Break it with: 'Name three CSS changes I can make to my existing file right now.'
AI redirecting to theory instead of answering
AI redirecting to theory
Real example: user asking for practical solutions, AI redirecting to theory. Tap to expand.
Week 1 Assessment — Pass to unlock Week 2
You've changed some CSS on your website. What's the correct sequence to make the change appear on your live site?
Save the file and refresh the Netlify URL
Saving locally doesn't update the live site. The change needs to travel through your deployment pipeline: save → git push → Netlify deploys.
Save the file, then git add .git commit -m "message"git push
That's the one. Save → stage → commit → push. Netlify picks up the push automatically and deploys in about 30 seconds. This workflow is your new normal. Every change you make from now on follows this exact path.
Upload the file to Netlify manually
You could drag-and-drop to Netlify, but that defeats the purpose of the GitHub connection. The power of continuous deployment is: push to GitHub, everything else is automatic.
Email the file to Netlify support
I appreciate the confidence in Netlify's support team, but no. Your deployment pipeline is fully automated — git push is all it takes.
■ What You Built This Week
6 tools installed
VS Code, Git, Node, Python, npm, pip
8 terminal commands
cd, ls, mkdir, git, node, python, npm, pip
1 live website
Your URL, your code, your deploy

Seven days ago you didn't have any of this. Now you have a deployed website and every tool you need to build AI applications. Week 2 starts building them.

Week 1 Complete.
You started with nothing. You now have: VS Code configured, terminal skills, Git version control, GitHub repository, Node.js, Python, a Netlify account, and a live website. Week 2 is where it gets interesting — you'll learn what every line of that HTML actually does, how to make it look beautiful with CSS, and how to make it interactive with JavaScript.
Quick reminder: If something didn't work this week, don't skip over it. Go back to the segment, re-run the checkpoint, and ask Claude to walk through the exact error with you. The verification habit starts now.
Week 1 Recall Gate
Prove it before you unlock Week 2
Six quick questions. No video, no reading. Just what you've actually learned this week.
Question 1 of 6
Segment summary · Seg 7 · Your First Live Website You shipped something real. A URL exists that wasn't there before.
  • index.html is the default file — browsers look for it automatically
  • Your first site: HTML structure + a little CSS + a deploy = a real product
  • Live Server for local preview, Netlify for production — same workflow every time
  • Version control from the start: every project gets git init on day one
Chapter 2 of 4

Building

Chapter 1 complete — Environment
VS Code, Terminal, Git, GitHub, Cloudflare, Node.js, DNS, and your first live site. Your foundation is set.
lass="chap-break-sub">Building. HTML, CSS, JavaScript, APIs, multi-model orchestration.

08HTML — Structure
09CSS — Design
10JavaScript — Interaction
11Connecting to AI — Your First API Call
12Building Your First AI Tool
13Multi-Model Chat — Compare AI Responses
14Orchestration — Chaining AI Calls
Pacing check · read before starting Week 2
Before you start Chapter 2, a quick honest check-in. Pick the one that fits:
✓ I finished all of Week 1 and my site is live
Keep going. Week 2 is the fun part — you're about to start writing real code.
⚠ I finished most of Week 1 but something's broken
Fix it now, not later. Week 2 assumes your site deploys via git push. If that flow isn't working, go back to Segment 7 and use the self-service flow from the "What You Need" slide (sl0g). Don't try to power through — every Week 2 segment builds on a working Week 1 pipeline.
⌛ I'm behind. Can I skip ahead?
No — but you can compress. Never skippable: Git + GitHub (Seg 4), Node install (Seg 5), Netlify deploy (Seg 6–7). Every later segment needs these. Can be skimmed if tight on time: the deeper explainers in Seg 1, the CSS animations in Seg 9, the UX polish steps in Seg 12. Read, don't type. Come back when you have time. What matters at the end of Week 2 is that you have a Worker deployed and your site successfully calling it — everything else is polish.

Good breath point. If you need to stop here, save your place — we'll email you the link back.

Segment 8 of 23 · Week 2
By the end of this segment you will be able toRead any HTML file AI gives you and know exactly what each tag does, where the structure is sound, and where AI has invented attributes that don't exist.
Read any HTML file AI gives you and know exactly what each tag does, where the structure is sound, and where AI has invented attributes that don't exist.

HTML — Structure

⏱ ~40 min⬡ Desktop required
▸ 30-second preview — where you're headingBy the end of this segment you can look at any web page, press F12, open DevTools, and read the structure.
By the end of this segment you can look at any web page, press F12, open DevTools, and read the structure. HTML stops being wallpaper and becomes the skeleton you can name every bone of — and once you can name it, you can change it.

HTML is the structure of every web page. It's the skeleton that holds the text, the buttons, the images, the forms — all of it. You wrote HTML by copy-pasting in Segment 7, but you didn't have to understand it yet. This segment fixes that. By the end you'll know what every tag in your first page does and why it's there.

HTML is not a programming language — it has no logic, no loops, no decisions. It's a nested set of labelled containers. <h1> is a heading. <p> is a paragraph. <button> is a button. The whole language is 30 tags you'll actually use, 5 attributes worth memorising, and a nesting rule that says "what's inside what". Twenty minutes from now you'll be writing it without thinking.

From here on, you're not typing HTML from memory. You'll ask AI to scaffold pages. What this segment teaches is the structure — so when AI gives you HTML, you can read it, change it, and spot when it's wrong. That's the skill. Not memorising tags.
Your Stack — Week 2
HTML
Learning now
CSS
JavaScript

Remember that HTML you pasted in Segment 7? You didn't need to understand it then. You do now. HTML is the skeleton of every webpage — the structure that holds everything in place. CSS makes it look good (next segment). JavaScript makes it do things (Segment 10). This segment is about the skeleton — and every tag you learn here shows up in the AI tool you'll build in Segment 12. The text input where users type their prompt? HTML. The button that sends it? HTML. The box that displays the AI response? HTML. You're building the interface for your AI tool right now.

Week 2. The building starts. Everything from here is about making things — not installing things. If Week 1 felt slow, this is where the pace picks up. Ready?

What we're building in this segment Rebuild index.html from scratch — same file, but every line explained.
We're going to rebuild your index.html from scratch — same file, but this time you'll understand every line. By the end, you'll have a proper multi-section page with a header, navigation, content areas, and a footer. Let's get into it.
The 3 Things You Need to Know About HTML
1. Everything is a tag
Tags have an opening (<h1>) and a closing (</h1>). Content goes between them. That's HTML.
2. Tags nest inside each other
A <div> can contain a <h1> which can contain a <span>. It's boxes inside boxes. The bracket pair colours in VS Code (from Segment 2) show this nesting.
3. Tags can have attributes
Attributes give extra information. <a href="url"> makes a link. <img src="image.jpg"> shows an image. The tag says WHAT, the attribute says HOW.
The 12 Tags That Build 90% of Webpages

HTML has over 100 tags. You need about 12. Here they are — grouped by what they do:

Structure
<header> <nav> <main> <section> <footer>
Content
<h1><h6> <p> <a> <img>
Grouping
<div> <span> <ul> / <li>
Exercise: Build a Multi-Section Page

Replace everything in your index.html with this. Read the comments (the grey text) — they explain what each piece does:

index.html — A real multi-section page
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>My AI Project</title>
</head>
<body>

  <!-- HEADER: Top of the page, usually your name or brand -->
  <header>
    <h1>My AI Project</h1>
    <p>Built from scratch during the AI Clarity Programme</p>
  </header>

  <!-- NAV: Links to different sections or pages -->
  <nav>
    <a href="#about">About</a>
    <a href="#tools">Tools</a>
    <a href="#contact">Contact</a>
  </nav>

  <!-- MAIN: The primary content of your page -->
  <main>
    <section id="about">
      <h2>About</h2>
      <p>This is my first real website. I'm learning to build AI-powered tools.</p>
    </section>

    <section id="tools">
      <h2>My Tools</h2>
      <ul>
        <li>Response Checker</li>
        <li>Session Monitor</li>
        <li>Model Compare</li>
      </ul>
    </section>

    <section id="contact">
      <h2>Contact</h2>
      <p>Email me at <a href="mailto:you@email.com">you@email.com</a></p>
    </section>
  </main>

  <!-- FOOTER: Bottom of the page -->
  <footer>
    <p>&copy; 2026 My AI Project</p>
  </footer>

</body>
</html>
▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • AI invents non-existent HTML attributes (e.g. <div align='center'> is deprecated)
  • Mismatched or unclosed tags that browsers silently forgive but cause layout breaks
  • Missing accessibility attributes — no alt text, no ARIA labels, no semantic structure
Common ways students miss it:
  • Copying AI's output without opening it in a browser
  • Trusting 'it looks fine locally' without checking in a second browser
The 30-second check: Open browser DevTools → Console. Zero red errors = structural pass. Then: File → View Source — read it top to bottom.
Checkpoint
Save the file. Does Live Server show a page with a heading, navigation links, three sections, and a footer? (It will look plain and unstyled — that's CSS's job, next segment.)
It looks ugly right now. That's normal — HTML without CSS is just raw content with default browser styling. That plain page IS the skeleton. Next segment dresses it up. Push it to GitHub while you're at it: git add . && git commit -m "multi-section page" && git push
▶ Code Editor (click to expand)
Build a basic HTML page
LIVE EDITOR
Write the skeleton of a web page. Add a heading, a paragraph, and a button. Hit Run to see it live.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
MOCK QUESTION — PRACTICE
What's the difference between <section> and <div>?
There is no difference
They both group content, but <section> tells the browser (and screen readers) "this is a distinct section of content" while <div> is a generic container with no meaning. Use <section> when the content has a clear theme.
<section> has semantic meaning — it tells the browser this is a distinct content area. <div> is a generic container.
Spot on. Semantic HTML matters — it helps screen readers, search engines, and anyone reading your code understand what's what. It's the difference between labelling a box "kitchen items" vs just "stuff." Small thing, big difference.
<div> is newer and better
Actually the opposite — <div> is older. Semantic tags like <section>, <header>, <nav> were introduced in HTML5 specifically to add meaning that <div> doesn't provide.
<section> is only for text content
Sections can contain anything — text, images, forms, other elements. The point is that the content within a section is thematically related.
Emmet shortcut: In VS Code, type ! and press Tab. It generates the entire HTML starter template instantly. You'll never type <!DOCTYPE html> by hand again.
Segment 8 — What you mastered
  • The structural HTML tags: html, head, body, header, main, footer, section, div
  • Semantic vs presentational tags and why screen readers care
  • How to verify AI-generated HTML by reading it tag by tag
  • Common AI mistakes: invented attributes, mismatched tags, accessibility holes
Quick recall — Segment 8
AI gives you HTML containing <button onClick="submit()" type="buttin">Send</button>. What's wrong?
Correct. Correct. AI hallucinates plausible-looking attributes. Reading the output before you ship is the verification layer in HTML form.
Segment summary · Seg 8 · HTML — Structure HTML is the skeleton. Every element has a purpose.
  • HTML is markup — it describes what content IS, not how it looks
  • Block elements (div, p, h1-h6) stack vertically. Inline elements (span, a, strong) flow in text.
  • Semantic HTML: use
    ,
    ,
    ,
    — they help screen readers and SEO
  • Every tag that opens must close (or be self-closing like )
Segment 9 of 23 · Week 2
By the end of this segment you will be able toStyle any AI-generated page with a dark theme that works, understand the box model well enough to debug layout, and spot CSS that breaks on mobile.
Style any AI-generated page with a dark theme that works, understand the box model well enough to debug layout, and spot CSS that breaks on mobile.

CSS — Design

⏱ ~40 min⬡ Desktop required
▸ 30-second preview — where you're headingSame HTML as Segment 8.
Same HTML as Segment 8. Completely different page. Add one <style> block and your "Hello, world" goes from 1998 defaults to a dark-themed, frosted-glass, cyan-accented page that looks like a real product. Structure didn't move. Design changed everything.

CSS is the design layer — it tells the browser how every HTML element should look. Fonts, colours, spacing, layout, animations, responsive behaviour — all of it lives in CSS. The separation is deliberate: HTML says what things are, CSS says what they look like. Change one without touching the other.

This segment teaches you just enough CSS to make your Segment 8 page look professional: a dark theme with an emerald accent, centred content, good spacing, and a button that doesn't look like it escaped from 2003. You won't memorise every property — nobody does. You'll learn the twenty properties that cover 90% of what you'll ever need, and you'll learn how to look up the rest in three seconds when you do.

CSS is what you read in AI's output, not what you write from memory. This segment teaches you how CSS works so you can understand what AI generates, spot when it's wrong for your target browsers, and make confident changes when needed.
Your Stack — Week 2
HTML
CSS
Learning now
JavaScript

Your page from Segment 8 works — but it looks like it was designed in 1998 by someone in a hurry. That textarea, button, and response area you built? They're about to look like they belong in a professional AI tool. Same HTML. Completely different experience. CSS is how — and this segment teaches you just enough of it to make your tools look like they belong in a professional product.

How CSS Works — 3 Concepts
1. Selectors → Properties → Values
body { background: #0b0b0c; } — the selector (body) picks what to style, the property (background) says what to change, the value (#0b0b0c) says to what.
2. The Box Model
Every element is a box. The box has: content (the text), padding (space inside), border, and margin (space outside). Understanding this = understanding CSS layout.
3. Flexbox & Grid = Layout
Flexbox arranges things in a line (horizontal or vertical). Grid arranges things in a grid. Between them, you can build any layout. These are the only two layout systems you need to learn.
Exercise: Add the Dark Theme

Add a <style> block inside your <head> tag (after <title>, before </head>). Paste this CSS:

Same HTML. Watch what CSS does.
index.html + style.cssHTML + CSS
Same HTML, completely different product. Zero tags changed. Zero functionality changed. CSS turns a browser default form into something that looks like it belongs in a professional AI tool. Every style here is reusable — background, padding, border-radius, font, gradient. Learn these six properties and 80% of 'looking professional' is solved.
CSS — Dark theme with clean layout
<style>
/* Base — dark theme */
* { margin: 0; padding: 0; box-sizing: border-box; }
body {
  background: #0b0b0c;
  color: #f3efe9;
  font-family: -apple-system, 'Segoe UI', sans-serif;
  line-height: 1.7;
}

/* Header */
header {
  text-align: center;
  padding: 60px 20px 40px;
}
header h1 { font-size: 2.4rem; }
header p { color: rgba(243,239,233,.5); }

/* Nav */
nav {
  display: flex;
  justify-content: center;
  gap: 24px;
  padding: 16px;
  border-bottom: 1px solid rgba(255,255,255,.06);
}
nav a {
  color: #ff6a1f;
  text-decoration: none;
  font-size: 0.85rem;
}

/* Main content */
main {
  max-width: 700px;
  margin: 0 auto;
  padding: 40px 20px;
}
section { margin-bottom: 40px; }
h2 { margin-bottom: 12px; color: #ff6a1f; }
p { color: rgba(243,239,233,.6); }
ul { padding-left: 20px; color: rgba(243,239,233,.6); }

/* Footer */
footer {
  text-align: center;
  padding: 30px;
  font-size: 0.75rem;
  color: rgba(243,239,233,.3);
}
</style>
▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • AI uses vendor-prefixed CSS that only works in one browser
  • Generates mobile-first rules that break desktop, or vice versa
  • Uses CSS variables it never defined, silently falling back to defaults
Common ways students miss it:
  • Testing only in Chrome — Safari and Firefox render differently
  • Skipping a resize test to mobile viewport (DevTools → responsive mode)
The 30-second check: Resize the browser to 375px width. Does it still look right? Then: open in Firefox or Safari. Compare.
Checkpoint
Save. Does your page now have a dark background, orange accents, centred content, and clean spacing?
Same HTML from Segment 8. Completely different look. That's the power of CSS — structure and design are separate. Change the CSS, the entire feel changes. The HTML doesn't move. Push it: git add . && git commit -m "dark theme CSS" && git push
DevTools are your best friend. Right-click any element on your page → Inspect → you can see AND edit CSS live in the browser. Changes disappear on refresh, so it's a safe playground. Try changing #ff6a1f to #10b981 (emerald) and watch the accent colour change in real time.

Two languages down, one to go. HTML tells the browser what's on the page. CSS tells it how to show it. Next up: JavaScript tells it what to do when someone actually interacts with it. Nearly there.

What you just styled is the front end of your AI tool. Same textarea. Same button. Same response area. In Segment 10, you'll make the button actually do something. In Segment 11, that something will be talking to Claude.

▶ Code Editor (click to expand)
Style the page with CSS
LIVE EDITOR
The HTML works but it's ugly. Add CSS in the <style> block to give it a dark theme, rounded button, and proper spacing.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
SHARP M1 The Agreement Trap.The first time you show an AI your CSS, it will almost certainly call it 'clean' or 'well-structured' — whether it is or not.
The first time you show an AI your CSS, it will almost certainly call it 'clean' or 'well-structured' — whether it is or not. That's the Agreement Trap (M1) in action. Ignore compliments; ask for the concrete critique: 'Name three things that would improve this CSS if I rewrote it.' The answer is always useful.
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
MOCK QUESTION — PRACTICE
You want your AI tool's response area to have a dark background, rounded corners, and light text. Which CSS properties do you need?
color: dark; shape: round; text: light
Those aren't real CSS property names. CSS uses specific properties like background, border-radius, and color.
background: #1a1a1c; border-radius: 8px; color: #f3efe9
Three properties: background sets the fill colour, border-radius rounds the corners, color sets the text. These three lines turn a raw HTML box into something that looks like it belongs in a professional tool.
dark-mode: on; rounded: true
CSS doesn't have shorthand toggles like that. Each visual property is set individually — which gives you precise control over every detail.
You need JavaScript for visual styling
JavaScript handles behaviour (clicks, input, API calls). CSS handles appearance. They're separate concerns — and keeping them separate makes your code easier to maintain.
Segment 9 — What you mastered
  • The CSS box model: content → padding → border → margin
  • Selectors that actually target what you want
  • Why dark themes are easier on first attempts
  • Mobile-first thinking — what AI often forgets
Quick recall — Segment 9
AI gives you CSS using `width: 100vw` for a full-width section. What problem is this likely to cause?
Correct. Correct. AI reaches for vw because it sounds modern; on real devices it often causes the exact bug you're trying to avoid. Verify on mobile.
Segment summary · Seg 9 · CSS — Design CSS is the skin. You can make anything look like anything.
  • Selector → property → value: the three-part structure of every CSS rule
  • Box model: content + padding + border + margin — every element is a box
  • Flexbox: display:flex makes horizontal/vertical layout trivial
  • CSS variables (--accent: #10b981) — define once, use everywhere
Segment 10 of 23 · Week 2
By the end of this segment you will be able toWire up a working click handler that updates the page in real time — the same pattern your AI tool will use in Segment 11.
Wire up a working click handler that updates the page in real time — the same pattern your AI tool will use in Segment 11.

JavaScript — Interaction

⏱ ~40 min⬡ Desktop required
▸ 30-second preview — where you're headingClick a button.
Click a button. Something changes on the page. You didn't refresh. You didn't navigate. The page just updated. That's JavaScript — and it's the third and final piece of the front-end trio (HTML / CSS / JS) that runs on every website you've ever used.

JavaScript is the behaviour layer. HTML is the skeleton (Segment 8), CSS is the skin (Segment 9), JavaScript is the brain. It's what makes a page respond: clicks, typing, form submissions, loading states, animations, API calls. Every interactive element on every modern website is JavaScript underneath.

AI writes the JavaScript. You read it. From this segment on, you're not typing JS from memory — you're asking AI to write event handlers, fetch calls, and async flows, then reading the output before you paste it. JS is where AI hallucinations land hardest: invented methods, wrong async patterns, silent scope bugs. Example: AI might write arr.findFirst(x=>x>5) — that method doesn't exist (it's arr.find()). The 5 concepts this segment teaches are the ones you need to catch that before it ships.

This segment is longer than the last two because JavaScript is a programming language — it has variables, functions, loops, conditionals, objects. You won't learn all of it. You'll learn the 20% that covers 80% of front-end work: variables with let and const, functions, click handlers, DOMDocument Object Model. The browser's internal map of your webpage. JavaScript uses it to change what's on screen. updates, and the fetch() call. That last one is the one that matters most — it's how your page talks to AI APIs in Segment 11.

SHARP M1 check.When you paste your first JS error into an AI, it will almost certainly tell you the code looks "clean" and offer three "optimisations".
When you paste your first JS error into an AI, it will almost certainly tell you the code looks "clean" and offer three "optimisations". That's the Agreement Trap (M1). The honest fix is usually one missing semicolon or a typo. Find the typo yourself first. Use AI as a second opinion, not a first answer.
Your Stack — Week 2
HTML
CSS
JavaScript
Learning now

HTML is the skeleton (you built it). CSS is the skin (you styled it). JavaScript is the brain — it makes your page respond to clicks, process input, talk to AI APIs, and change content dynamically. This segment teaches you just enough JavaScript to build interactive tools — which is what Segment 11 onwards is all about.

This is not a JavaScript course 5 concepts — not algorithms or data structures. The foundation, not the full language.
You're not going to learn algorithms or data structures. You're going to learn 5 concepts that let you make interactive pages and call AI APIs. If you want to go deeper into JavaScript after this course, you'll have the foundation — but right now, these 5 concepts are all you need.
The 5 JavaScript Concepts You Need
1. Variables — storing values
JavaScript
const name = "My AI Tool";       // doesn't change
let count = 0;                   // can change
let isActive = true;             // true or false
Use const for things that don't change. Use let for things that do. Never use var (it's the old way).
2. Functions — reusable blocks of code

A function in JavaScript is a reusable block of instructions — you define it once, then call it by name whenever you want its behaviour. The example below defines greet which takes a name and returns a greeting string, then calls it with "World". Functions are the building blocks of every interactive website.

JavaScript
function greet(name) {
  return "Hello, " + name;
}

greet("World");  // returns "Hello, World"
A function is a set of instructions with a name. You write it once, call it whenever you need it.
3. DOM Manipulation — changing the page
JavaScript
// Find an element
const heading = document.querySelectorA JavaScript function that finds an element on your page by its name, class, or ID.('h1');

// Change its text
heading.textContent = "New Heading!";

// Show or hide something
heading.style.display = 'none';    // hidden
heading.style.display = 'block';   // visible
The DOM is the page's structure in JavaScript form. querySelector finds elements. Then you can change them.
4. Events — responding to user actions

An event listener waits for something to happen (a click, a keypress, a scroll) and runs the function you gave it when the event fires. This is how every interactive element on every website works — button clicks, form submissions, hover effects, all of it is the same pattern underneath.

JavaScript
const button = document.querySelector('button');

button.addEventListener('click', function() {
  alert('Button clicked!');
});
Events listen for things happening — clicks, typing, scrolling. When the event fires, your function runs.
5. fetch() — talking to APIs ⭐
JavaScript — the one that matters most
// Send a request to an API and get a response
const response = await fetch('https://api.example.com/data');
const data = await response.json();

// Now 'data' contains whatever the API sent back
console.log(data);
This is the one. fetch() is how your website talks to AI APIs. You send a request, the API sends a response. In Segment 11, you'll use this to connect your page to Claude, GPT, and Gemini.
Exercise: Add Interactivity to Your Page

Now put the five concepts together. The code on the next slide builds a working click counter — a button that updates a line of text every time you click it. It uses variables (let clickCount), DOM manipulation (querySelector), event listeners (addEventListener), and string templating (the backticks). No AI yet — that's Segment 11 — but this is the same structure your AI tool will have: an element, a listener, and an update.

Add the code from the next slide just before </body> in your index.html. Save. Refresh. Click the button.

Add before </body>
<button id="myBtn" style="padding:12px 24px;background:#ff6a1f;color:#0b0b0c;border:none;border-radius:8px;font-weight:bold;cursor:pointer;margin:20px auto;display:block">
  Click Me
</button>
<p id="output" style="text-align:center;color:rgba(243,239,233,.9)"></p>

<script>
  let clickCount = 0;
  const btn = document.querySelector('#myBtn');
  const output = document.querySelector('#output');

  btn.addEventListenerTells JavaScript to watch for something happening (a click, a keypress) and run code when it does.('click', function() {
    clickCount++;
    output.textContent = `You clicked ${clickCount} time${clickCount === 1 ? '' : 's'}!`;
  });
</script>
SHARP M4 The Confident Guess.When you ask AI 'is this Worker code secure?', it will confidently say yes or list generic security concerns that don't apply to your code.
When you ask AI 'is this Worker code secure?', it will confidently say yes or list generic security concerns that don't apply to your code. That's M4 — the Confident Guess. The honest version of the question: 'Name the single most likely way this specific Worker code could leak the API key. Don\'t list possibilities — pick the most probable one.'
▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • AI writes JS that works in the console but breaks when the DOM isn't ready
  • Async/await timing errors — AI assumes functions complete before they actually do
  • Uses modern syntax (optional chaining, nullish coalescing) that fails in older browsers
Common ways students miss it:
  • Clicking the button once and assuming it works
  • Not checking what happens when you click the button twice in quick succession
The 30-second check: Open DevTools Console. Click your button. Check: (1) zero red errors, (2) button state resets correctly after each click, (3) works on second + third click.
▸ Try it now · 5 minWire up your first click handler.
In a new HTML file, add a button and an empty paragraph. Ask Claude to write the JavaScript that increments a counter in the paragraph each time you click. Paste the code, save, refresh. Now break it deliberately — change addEventListener('click', ...) to addEventListener('clik', ...). What happens? Why? This is how you learn the language.
Checkpoint
Save. Does clicking the orange button update the text below it with a click count?
Your page is now interactive. HTML shows it, CSS styles it, JavaScript makes it respond. Those three — HTML, CSS, JS — are the entire foundation of web development. Everything from here builds on this. Push it: git add . && git commit -m "added JavaScript interaction" && git push
▶ Code Editor (click to expand)
Make the button do something
LIVE EDITOR
Add JavaScript so the button changes the text below when clicked. Use addEventListener('click', ...).
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
MOCK QUESTION — PRACTICE
In Segment 11, you'll connect your website to an AI API. Which JavaScript feature does that?
querySelector
querySelector finds elements on your page — it doesn't communicate with external services.
addEventListener
addEventListener responds to user actions on your page — it doesn't make network requests.
fetch()
That's the one. fetch() sends HTTP requests to external services — including AI APIs. In Segment 11, you'll send a user's input to an AI API via fetch() and display the response on your page. This is the bridge between your website and artificial intelligence.
textContent
textContent changes text on the page — useful for displaying API responses, but it doesn't make the request itself.

Three languages in three segments. HTML for structure. CSS for design. JavaScript for interaction. That's the entire front end of the web — and you've just built with all three. The next segment is where we connect it to AI. That's when this course stops feeling like a coding course and starts feeling like building something real.

Console is your debugging friend. console.log(anything) prints to the DevTools Console (F12). When something isn't working, console.log the values to see what's actually happening. Every developer does this. Every day.
Segment 10 — What you mastered
  • Variables (let, const) and when to use which
  • DOM access via querySelector and getElementById
  • Event listeners (addEventListener) — the click → function → update loop
  • String templating with backticks and how AI uses it for output
Quick recall — Segment 10
Your click handler works in DevTools console but not on the live page. What is the most common cause?
Correct. Correct. Timing bugs are the #1 reason AI-written JS 'works in testing but breaks in production'. Verify by reloading the live page, not just the console.
Segment summary · Seg 10 · JavaScript — Interaction JavaScript makes pages respond. Events, DOM, async — the three pillars.
  • document.getElementById() and querySelector() — find any element on the page
  • addEventListener('click', fn) — the pattern behind every interactive button
  • async/await: tell JavaScript to wait for slow operations (fetch, timers)
  • try/catch: never let an error crash silently — always handle or log it
Segment 11 of 23 · Week 2
By the end of this segment you will be able toMake your first real API call from a Cloudflare Worker to Anthropic, with your key on the server (never the browser), and a verification habit baked into the workflow.
Make your first real API call from a Cloudflare Worker to Anthropic, with your key on the server (never the browser), and a verification habit baked into the workflow.

Connecting to AI — Your First API Call

⏱ ~45 min⬡ Desktop required
▸ 30-second preview — where you're headingYou type a question into your own website.
You type a question into your own website. You press a button. Three seconds later, Claude's answer appears. Not in ChatGPT. Not in someone else's interface. In your page, with your design, running your code. This is where the course becomes an AI course.
Before we go further — what is an API?
Your first API call. AI is going to write most of this Worker code. Your job in this segment: understand the request/response cycle well enough that when AI hands you a Worker, you know what each line does and can spot when one is wrong. That's the bar. Not writing it from scratch — reading it critically.
What an API is: A way for your code to talk to someone else's code. Like a phone number for a service. Your website "calls" Claude's API, asks a question, and gets an answer back. Every AI tool in the world works this way.
What an API key is: A password that proves you're allowed to use the service. Without it, Claude won't respond to your code. Think of it as a membership card — you show it every time you make a request.
Why it costs money: Every time your code sends a question to Claude, Anthropic's servers do the work. The API key tracks how much you've used. Free credits come with signup — enough for this entire course.
Why it must stay secret: Anyone with your key can use it — and you pay for their usage. Never put it in your website code. That's why we use a Cloudflare WorkerA small piece of code that runs on the internet, between your website and the AI. It keeps your API key hidden. — it holds the key on a server where nobody can see it.
Why Claude? And what about other AI models?

This course uses Claude by Anthropic because it's the author's personal choice for quality, safety, and developer experience. But the method you're learning works with any AI that offers an API. The most prominent alternatives:

  • OpenAI (GPT) — the most widely used, same API concept
  • Google Gemini — strong on multimodal tasks
  • Mistral — European, fast, competitive pricing
  • Cohere — strong on enterprise and retrieval
  • DeepSeek — open-weight, cost-effective

Every one of these uses the same pattern: sign up, get an API key, send a request, get a response. If you learn it with Claude, you can switch to any other model by changing one URL and one key. The skill transfers completely.

This is the segment every other segment has been building towards. Segments 1 through 10 gave you the environment, the languages, and the deployment pipeline. Segment 11 connects your page to Claude — and from this point forward, every segment builds on top of a working AI call.

✗ Myth
Put the API key in your frontend JavaScript so the fetch() can call Anthropic directly.
✓ Reality
The key lives in a Cloudflare Worker environment variable. The browser calls your Worker. Your Worker calls Anthropic.
SHARP M5 check — the Caveat pattern.When you ask an AI to "help me write a Worker", it often starts with a philosophical-sounding limitation: "I c...
When you ask an AI to "help me write a Worker", it often starts with a philosophical-sounding limitation: "I cannot test this in a real Cloudflare environment…". That's the Caveat pattern (M5) — it says nothing actionable and stalls your progress. Ignore it. Ask specifically: "Given the code below, is this missing anything the Anthropic API requires? Yes or no?" Specificity breaks the Caveat.
AI hitting generation limits
AI hitting generation limits
Query unsuccessful — AI refusing task
Query unsuccessful — AI refusing
Real examples: AI refusing with caveats instead of completing the task. Tap to expand.
Real failure · 2024The hardcoded-key Twitter incident

A startup founder posted a screenshot of his AI tool to Twitter to celebrate launch. The screenshot included his browser DevTools open, showing the API key embedded in the JavaScript. Within 11 minutes, his Anthropic account was billed $1,200. The key had been scraped from the screenshot's image — automated bots watch developer Twitter for exactly this.

The verification habit that prevents it: the key never touches client-side code. The Worker proxy pattern (this segment) makes the leak impossible because there's nothing to leak.

Your Stack — The Bridge
HTML/CSS/JS
Cloudflare Workers
Building now
AI APIs
Connecting now

This is the segment the course has been building towards. Everything up to now — the editor, the terminal, Git, HTML, CSS, JavaScript — was preparation for this moment. You're about to send a message to an AI model from your own code and get a response back. Not through a chatbot interface. Through code you wrote yourself.

First — why can't you just call the API directly?

AI APIs require a secret key to work. If you put that key in your website's JavaScript, anyone can open DevTools, find it, and use it to make calls on your account. You'd be paying for their usage.

The solution: a Cloudflare Worker. It's a tiny piece of server code that sits between your website and the AI API. Your website sends the prompt to the Worker. The Worker adds the secret key and forwards it to the AI. The key never touches the browser. This is the same architecture that professional AI applications use — and the Worker's free tier gives you 100,000 requests per day.

Your Website
sends prompt
Cloudflare Worker
adds API key securely
AI API (Claude)
returns response
Step 1: Get Your Anthropic API Key
  1. Open Chrome and go to console.anthropic.com
  2. Click Sign Up — use your email or Google account
  3. Once logged in, you'll see the Claude Console dashboard
  4. Look for "Get API Key" on the main page — click it
  5. Click Create Key
  6. Give it a name (e.g. "my-ai-tool") and click Create
  7. Your key appears — it starts with sk-ant-
  8. Copy it now and paste it somewhere safe (a text file, a note on your phone). You will not be able to see it again after you close this page
  9. You'll paste this key into Cloudflare in Step 2

Cost: Anthropic gives you free credits when you sign up. That's enough for this entire course. You won't need to enter payment details to start.

How your code actually talks to Claude (safely)
Click each box →
Click any node to see what each layer does.
Step 2: Create Your Cloudflare Worker
  1. Open a new tab and go to dash.cloudflare.com/sign-up
  2. Create a free account (email or Google)
  3. Once logged in, click Workers & Pages in the left sidebar
  4. Click Create
  5. Click Start with Hello World! — this gives you a basic Worker to start with
  6. Name it ai-proxy and click Deploy
  7. Now go to your Worker's Settings tab → Variables and Secrets
  8. Click Add
  9. Name: ANTHROPIC_API_KEY
  10. Type: Secret (this encrypts it so nobody can read it)
  11. Value: paste the API key you copied from Anthropic in Step 1
  12. Click Save

Your key is now stored securely on Cloudflare's servers. Your website will talk to this Worker, and the Worker will add the key before forwarding to Claude. The key never touches the browser.

⚠ Env var gotchas · read before you test
Two things will trip you up later if you skip them now:
  • Name must match exactly. In the dashboard you saved ANTHROPIC_API_KEY. In your code you'll write env.ANTHROPIC_API_KEY. Case-sensitive. One typo and you'll spend 20 minutes on "why is my key undefined?" Write it once, copy-paste everywhere.
  • You must redeploy after adding a variable. Cloudflare doesn't pick up new env vars on existing deployments automatically. After saving the variable, click Deploy again (or run npx wrangler deploy if you're using the CLI). No redeploy = env.ANTHROPIC_API_KEY reads as undefined even though you just set it.
If your Worker returns 401 or "undefined": check both of these first. 90% of the time it's one of them. Use console.log('key present?', !!env.ANTHROPIC_API_KEY) inside your Worker for a quick boolean test — logs show in Cloudflare's Logs tab.

Now click "Edit Code" in the Worker editor and replace everything with this:

Cloudflare Worker — AI API Proxy
export default {
  async fetch(request, env) {
    // Only allow POST requests
    if (request.method !== 'POST') {
      return new Response('Send a POST request', { status: 405 });
    }

    // Get the prompt from your website
    const { prompt } = await request.json();

    // Call the Anthropic API with YOUR secret key
    const response = await fetch('https://api.anthropic.com/v1/messages', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'x-api-key': env.ANTHROPIC_API_KEY,
        'anthropic-version': '2023-06-01'
      },
      body: JSON.stringify({
        model: 'claude-sonnet-4-6',
        max_tokens: 1024,
        messages: [{ role: 'user', content: prompt }]
      })
    });

    const data = await response.json();

    // Send the AI response back to your website
    return new Response(JSON.stringify(data), {
      headers: {
        'Content-Type': 'application/json',
        'Access-Control-Allow-Origin': '*'
      }
    });
  }
};

Click "Save and deploy." Your Worker now has a URL like ai-proxy.your-name.workers.dev.

Step 3: Call the AI from Your Website

Add this to your index.html — a text input, a button, and the JavaScript that connects to your Worker:

Add before </body>
<div style="max-width:600px;margin:40px auto;padding:0 20px">
  <textarea id="prompt" rows="3" placeholder="Ask Claude anything..."
    style="width:100%;padding:12px;background:#1a1a1c;color:#f3efe9;border:1px solid rgba(255,255,255,.1);border-radius:8px;font-size:1.25rem;resize:vertical"></textarea>
  <button onclick="askAI()"
    style="margin-top:12px;padding:12px 24px;background:#ff6a1f;color:#0b0b0c;border:none;border-radius:8px;font-weight:bold;cursor:pointer">
    Ask Claude
  </button>
  <div id="response" style="margin-top:20px;padding:16px;background:#1a1a1c;border-radius:8px;color:rgba(243,239,233,.7);display:none;white-space:pre-wrap"></div>
</div>

<script>
asyncTells JavaScript to wait for something slow (like an API call) before continuing. function askAI() {
  const prompt = document.getElementById('prompt').value;
  const responseDiv = document.getElementById('response');

  responseDiv.style.display = 'block';
  responseDiv.textContent = 'Thinking...';

  try {
    const res = await fetch('https://ai-proxy.YOUR-NAME.workers.dev', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ prompt })
    });
    const data = await res.json();
    responseDiv.textContent = data.content[0].text;
  } catch (err) {
    responseDiv.textContent = 'Error: ' + err.message;
  }
}
</script>
Replace YOUR-NAME in the fetch URL with your actual Cloudflare Workers subdomain. You can find this on your Worker's dashboard.
The Worker proxy request flow · minimum viable production pattern
Browser
your HTML page
Worker
holds the API key
Anthropic
Claude API
Response
parsed JSON
Worker
cleans up the format
Anthropic
raw response
▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • AI invents API endpoint URLs that don't exist (fabricated Anthropic routes are common)
  • Hardcodes the API key directly in the code instead of using env vars
  • Uses a deprecated or incorrect model string
Common ways students miss it:
  • Not checking whether the model string matches the current Anthropic docs
  • Shipping without verifying the API key is in env vars, not in the source file
The 30-second check: Check: (1) Is ANTHROPIC_API_KEY in Cloudflare env vars, NOT in the code? (2) Does the model string match current Anthropic docs? (3) Does your Worker URL restrict to your domain only? (4) Test with one real prompt — is the response real?
▸ Try it now · 10 minVerify your Worker before you ship it.
Run the 4-point check on your Worker code: (1) Open wrangler.toml — is your API key in [vars], not in the JS? (2) Check the model string — does it match the latest at docs.claude.com? (3) Look at your CORS headers — does Access-Control-Allow-Origin list YOUR domain only, not *? (4) Send one real prompt and read the response — is it real or is it a generic AI response that suggests the request didn't actually go through?
Checkpoint — The Moment
Type something in the text box, click "Ask Claude," and wait a few seconds. Does an AI response appear below?
That's your code talking to an AI. Not a chatbot someone else built. Not a plugin. YOUR website, YOUR Worker, YOUR API call. The response travelled from your browser to Cloudflare to Anthropic and back — in seconds. Everything from here builds on this exact pattern.
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
▶ Code Editor (click to expand)
Call your Worker (mock AI response)
LIVE EDITOR
This editor mocks the fetch to your Worker — the preview returns a canned AI response so you can practise the JavaScript pattern without needing the real API.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
MOCK QUESTION — PRACTICE
Why do we use a Cloudflare Worker instead of calling the Anthropic API directly from the website?
The Anthropic API is too slow for direct calls
Speed isn't the issue — the API responds quickly either way. The Worker exists for security, not speed.
To keep the API key secret — it stays in the Worker, never reaching the browser
The API key must stay server-side. If it's in your browser JavaScript, anyone can steal it. The Worker holds the key securely and acts as a middleman. Your website only talks to the Worker — it never sees the key.
Cloudflare is required by Anthropic
Not true — you can use any backend server. Cloudflare Workers are just the simplest free option for what we're building. Any server-side code would work.
To make the code shorter
It actually adds code. But the trade-off is worth it — security isn't optional when API keys are involved.
Segment Complete
You built your first AI analysis tool.

You just crossed the line from "building websites" to "building AI-powered tools." From here, every segment adds capability. Push it: git add . && git commit -m "connected to Claude API" && git push

API costs: Anthropic gives you free credits to start — that's enough for this entire course and then some. After that, Claude Haiku costs fractions of a penny per call. A tool that makes 100 API calls a day would cost less than a coffee per month. Don't let API pricing stop you from experimenting.
■ Before & After — Look How Far You've Come
Segment 1: You didn't know what VS Code was. You'd never opened a terminal. "API" was a buzzword you'd seen on Twitter.
Now: Your website just talked to Claude. Through a secure proxy you built. Using an API call you wrote. Deployed on infrastructure you configured. That happened.
Segment 11 — What you mastered
  • The Worker proxy pattern: browser → your Worker → Anthropic
  • Why your API key NEVER touches client-side code
  • Reading a request/response cycle line by line
  • The 4-point pre-ship verification check (key in env, model string current, CORS scoped, real prompt tested)
Quick recall — Segment 11
Why does your browser code call YOUR Cloudflare Worker instead of calling Anthropic's API directly?
Correct. Correct. Hardcoded keys in browser code is the #1 way new builders lose hundreds of dollars overnight. The Worker IS the verification layer.
Segment summary · Seg 11 · Your First API Call Your code talks to Anthropic. The AI key never leaves the server.
  • fetch() to your Cloudflare Worker — never directly to Anthropic from the browser
  • The Worker holds ANTHROPIC_API_KEY as a secret environment variable
  • Request shape: { model, max_tokens, messages } — the three required fields
  • Response shape: data.content[0].text — always verify this path is populated
Segment 12 of 23 · Week 2
By the end of this segment you will be able toHave a working AI tool in your browser that takes user input, sends it through your Worker, and shows the AI's response — your first end-to-end product.
Have a working AI tool in your browser that takes user input, sends it through your Worker, and shows the AI's response — your first end-to-end product.

Building Your First AI Tool

⏱ ~45 min⬡ Desktop required
▸ 30-second preview — where you're heading Seg 11 proved the Worker works. Seg 12 turns it into a real tool a user can use.
Segment 11 proved the Worker works. Segment 12 turns it into a tool. You add input handling, a loading state, error handling, and formatted output — the four things that separate 'it works on my machine' from 'a real user can actually use it'.

Segment 11 was the proof of concept — you made a raw API call from your page and saw Claude respond. Segment 12 makes it a product. You'll wrap the fetch in proper input validation, add a loading indicator so the user knows something is happening, wrap the whole thing in try/catch/finally so a failed request doesn't crash the page, and format the response so it's actually readable.

This is the first segment where you start writing code that looks like production code instead of tutorial code. The pattern you build here is the one every subsequent tool you build reuses — the 4 production rules (validate, loading state, try/catch/finally, no API key in browser) that SCALE and every professional AI tool follow.

AI writes most of this. Your job is the 4 rules. Ask Claude to scaffold the fetch, the try/catch, the loading state — you'll read the output, not type it from scratch. Where you add real value: deciding WHAT the tool should do, verifying the 4 production rules actually landed, and catching the failure modes AI skipped. The 4 rules are the human-overlay for this segment — AI almost always forgets at least one of them.

Your Stack — Week 2
HTML/CSS/JS
Cloudflare Worker
AI Tool
Building now

In Segment 11 you connected your website to Claude. That's a raw API call — it works, but it's rough. This segment turns it into a real tool. You'll add proper input handling, a loading state so users know something is happening, error handling so it doesn't just crash, and formatted output that's actually readable. By the end, you'll have something you could show someone and they'd think a team built it.

What makes a tool feel professional Five small UI details that separate toys from tools.
Loading indicator ("Analysing..."). Empty state ("Enter text above and click Analyse"). Error messages that help ("Network error — check your connection"). Formatted output with sections and highlights. Disabled button while processing. These aren't hard to build — they just need to be there.
The 4 Patterns That Separate Amateur From Professional

Every polished AI tool you've ever used follows these four patterns. They're not complex — but missing any one of them makes the tool feel broken:

↻ Loading State
API calls take 2-10 seconds. Without a loading indicator, users think it's broken. Show "Analysing..." the moment they click. Disable the button so they can't double-submit.
• Error Handling
API calls fail. Networks drop. Keys expire. Wrap every fetch() in try/catch and show a helpful message — not a blank screen or a cryptic JavaScript error.
• Input Validation
Check before you send. Is the input empty? Is it too long for the API's token limit? Catch these before they cost you an API call — and tell the user what to fix.
• Formatted Output
Raw AI responses are walls of text. Add line breaks, section headers, or even basic Markdown rendering. The same content feels completely different when it's properly formatted.
Exercise: Build a Text Analyser

You're going to build a tool that takes any text, sends it to Claude with a specific instruction, and displays a structured analysis. Think of it as your own mini AI analysis tool. Create a new file called tool.html:

Same API call. Raw vs polished output.
app.js · analyse() functionJavaScript
Same API call. Completely different tool. The original 9-line version works but breaks on empty input, crashes on network errors, gives no loading feedback, and lets users double-click the button. The polished version adds input validation, loading state, error handling, XSS safety (escapeHtml), and a disabled button during the request. This is the difference between a toy and a tool.
What does a real user type into your tool? Tap to see →
Real user inputs
They type nothing and click Submit. They paste 50,000 words of a novel. They type "asdfjkl;" to test it. They copy-paste HTML with <script> tags. They submit the same prompt 40 times in 3 seconds. They use emoji. They write in Arabic. Every one of these is a real scenario. Your happy-path test catches zero of them. Test like a user, not like a developer.
tool.html — Your first AI tool (skeleton)
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <title>Text Analyser</title>
  <style>
    * { margin:0; padding:0; box-sizing:border-box; }
    body { background:#0b0b0c; color:#f3efe9; font-family:-apple-system,sans-serif; }
    .app { max-width:650px; margin:60px auto; padding:0 20px; }
    h1 { font-size:1.6rem; margin-bottom:14px; }
    .sub { color:rgba(243,239,233,.75); font-size:1.15rem; margin-bottom:28px; }
    textarea { width:100%; padding:14px; background:#1a1a1c; color:#f3efe9;
      border:1px solid rgba(255,255,255,.08); border-radius:10px; font-size:1.15rem;
      resize:vertical; min-height:120px; line-height:1.6; }
    .btn { margin-top:14px; padding:14px 28px; background:#ff6a1f; color:#0b0b0c;
      border:none; border-radius:10px; font-weight:700; font-size:1.15rem; cursor:pointer; }
    .btn:disabled { opacity:.8; cursor:not-allowed; }
    .result { margin-top:24px; padding:20px; background:#1a1a1c; border-radius:10px;
      color:rgba(243,239,233,.7); white-space:pre-wrap; line-height:1.7; font-size:1.25rem; }
    .loading { color:var(--cyan,#10b981); }
    .error { color:#e05a4a; }
  </style>
</head>
<body>
  <div class="app">
    <h1>Text Analyser</h1>
    <p class="sub">Paste any text. Get a structured analysis.</p>
    <textarea id="input" placeholder="Paste or type text here..."></textarea>
    <button class="btn" id="btn" onclick="analyse()">Analyse</button>
    <div class="result" id="result" style="display:none"></div>
  </div>

  <script>
  async function analyse() {
    const input = document.getElementById('input').value.trim();
    const btn = document.getElementById('btn');
    const result = document.getElementById('result');

    // Validation
    if (!input) { result.style.display='block'; result.className='result error'; result.textContent='Please enter some text first.'; return; }

    // Loading state
    btn.disabled = true;
    btn.textContent = 'Analysing...';
    result.style.display = 'block';
    result.className = 'result loading';
    result.textContent = 'Sending to Claude...';

    try {
      const res = await fetch('https://ai-proxy.YOUR-NAME.workers.dev', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({
          prompt: `Analyse the following text. Provide:
1. A one-sentence summary
2. The main argument or point
3. The tone (formal, casual, persuasive, etc.)
4. Any potential weaknesses or gaps

Text: ${input}`
        })
      });
      const data = await res.json();
      result.className = 'result';
      result.textContent = data.content[0].text;
    } catch (err) {
      result.className = 'result error';
      result.textContent = 'Something went wrong: ' + err.message;
    }

    btn.disabled = false;
    btn.textContent = 'Analyse';
  }
  </script>
</body>
</html>
▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • AI writes the happy path only — no empty-input handling, no error states
  • No loading state — the button stays active during the fetch, allowing double-submits
  • Response injected via innerHTML instead of textContent, creating an XSS risk
Common ways students miss it:
  • Testing only with a valid input on a good network
  • Not testing what happens when the response takes 10+ seconds
The 30-second check: Run the 5-test checklist: (1) empty input, (2) 10K+ chars, (3) offline, (4) <script> injection attempt, (5) happy path. All five must pass.
Checkpoint
Open tool.html in Live Server. Paste some text (a news article paragraph, a tweet, anything). Click Analyse. Does Claude return a structured analysis?
You've built your first AI-powered tool. It has input validation, a loading state, error handling, and structured output. This is the pattern for every AI tool you'll build from now on: input → prompt engineering → API call → formatted display. Push it: git add . && git commit -m "first AI tool" && git push
▶ Code Editor (click to expand)
Polish the AI tool
LIVE EDITOR
Add input validation, a loading state, and error handling to the basic version. The preview simulates a slow API.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
MOCK QUESTION — PRACTICE
What happens if a user clicks "Analyse" while the button says "Analysing..."?
Nothing — the button is disabled during processing
Exactly. btn.disabled = true prevents duplicate submissions while an API call is in flight. This is a small detail that separates amateur tools from professional ones. Always disable submit buttons during async operations.
It sends a second API call
It would, if we hadn't disabled the button. That's why btn.disabled = true is there — it prevents duplicate submissions and duplicate API charges.
The page crashes
Pages don't crash from duplicate clicks — but they can fire multiple API requests, which wastes credits and confuses users with overlapping responses.
An error message appears
No error would show — but without the disabled state, users might click repeatedly out of impatience, triggering multiple API calls.
Segment Complete
You now understand the architecture.

That tool you just built? It's not a toy. Add a better system prompt, change the analysis instructions, point it at a different use case — and you've got a product. The difference between a side project and a business tool is usually about 20 lines of CSS and a clear purpose. You've got both now.

Reusable pattern: Every AI tool you build from now on follows the same structure: input → validate → show loading → call API → handle errors → display result → re-enable input. Save this file as a template. You'll copy it as a starting point for every new tool.
DevTools Network tab (F12 → Network) shows every API call your page makes. You can see the request payload, the response, timing, and any errors. When an API call fails silently, this is where you find out why.
SHARP M3 The Tailored Response.AI will happily adapt its suggestions to whatever 'sophisticated' language you use.
AI will happily adapt its suggestions to whatever 'sophisticated' language you use. Call yourself 'a full-stack engineer' and it'll suggest patterns suitable for one; say 'I'm new to this' and it'll suggest different patterns. Same task. Same code. Different answers based on your register. That's M3 The Tailored Response — and it means the output is tuned to your personality, not to what's actually correct for your code.
Segment 12 — What you mastered
  • End-to-end: textarea → click → fetch → Worker → Anthropic → response → DOM update
  • Loading states so the user knows something is happening
  • Empty-input guards (the most common ship-day bug)
  • Reading the AI response before displaying it (never blind-trust)
Quick recall — Segment 12
A user clicks Send with the textarea empty. What does a verified-by-you AI tool do?
Correct. Correct. Validate at the boundary. An empty prompt costs you tokens and confuses the user. One if-statement saves both.
Segment summary · Seg 12 · Building Your First AI Tool A real AI tool exists at a real URL. You built the whole stack.
  • Input → validate → build prompt → fetch → parse → display — the six-stage pipeline
  • Always validate input before the API call: empty check, length limit, sanitise
  • Loading state: disable the button, show "Analysing…" — users must see feedback
  • error handling in the try block: network errors, API errors, and empty responses are different
Segment 12 · Applied Drill
By the end of this drill you will be able toRun three iteration cycles on one real prompt you’d use in your project, and describe the quality delta between attempt 1 and attempt 3.
Run three iteration cycles on one real prompt you would use in your project, and describe the quality delta between attempt 1 and attempt 3 across three axes: specificity, correctness, and shipability. The point isn’t the exercise — it’s developing the instinct to iterate rather than accept first output.

The Iteration Drill — Three Cycles on One Prompt

⏱ ~15 min• Saves locally• Uses real AI
You just shipped an AI tool. The version that exists right now is probably fine. The version that exists after three iteration cycles is better — specifically, better in ways you can name. This drill teaches the rhythm that separates the first-try prompt from the shipping prompt. One variable per cycle. Always.

Most people re-prompt by piling more instructions on top of a prompt that failed. That almost never works — it layers confusion on top of the original failure. Iteration is different. Diagnose what the AI did wrong. Change the one thing that caused it. Re-run. Compare. That’s the loop running in every professional AI-assisted workflow, and it’s the loop SCALE extends into automation.

▸ The rule — 1 minOne variable per cycle. Don’t pile on; diagnose and swap.

Current best-practice literature (IBM 2025; Lakera 2026; ApXML prompt engineering) converges on one rule: isolate changes. If you change the role, add examples, tighten the constraint, AND adjust temperature in one go, you can’t tell which change produced the result. Change one thing per cycle, test, then change the next thing. This is what separates prompt engineering from prompt guessing.

The four levers that matter in a coding prompt:

  1. Role — "You are a senior frontend engineer" vs "You are a tutor" changes tone AND content.
  2. Task framing — "Write a function" vs "Refactor this function for readability" produces different outputs.
  3. Constraints — "Under 20 lines, no external deps, ES2022+" anchors the answer.
  4. Output format — "Return only the code block, no prose" kills the explanation-before-code habit.

Run it now — on a task you actually have today

Applied · Saves locally

Pick a real coding task you need AI to help with right now — a feature for your Segment 12 tool, a bug fix, a refactor. Paste each attempt below. The widget saves to this browser, so your drafts carry over to your portfolio write-up in Segment 22. Your prompts never leave your machine.

1
Attempt 1 — your natural prompt
Paste exactly what you’d type if you weren’t doing this drill. Don’t improve it yet — the point is to see what your natural baseline produces.
2
Attempt 2 — change ONE lever
Based on what went wrong in attempt 1, change exactly one thing: role, task framing, constraints, OR output format. Not two. Not three. One. You’ll know which to change from the issue you flagged above.
3
Attempt 3 — target the next issue
If attempt 2 still had a failure, target that one now. If attempt 2 was clean, tighten one more constraint. Most good drills end with clean output by cycle 3 — if yours doesn’t, the task is probably scoped too broadly.
Δ
Delta — rate the difference
Attempt 1 vs attempt 3. Rate the gain on each axis from 1 (no improvement) to 5 (night-and-day).
Saved locally. Your three prompts, the lever you used, the issues you flagged, and your delta scores are stored in this browser. When you write your portfolio README in Segment 22, paste this in as evidence of your iteration thinking — hiring managers read that section most.
What you just practised is the core rhythm of everything ahead. Segment 14 teaches chaining (iteration across multiple AI calls). Chapter 4 teaches hardening (iteration on shipped code). The final project (Segment 23) is just this loop running until something real exists. If iteration feels slow now, that’s correct — by week 4 it runs in your head.
Segment 13 of 23 · Week 2
By the end of this segment you will be able toWire up a side-by-side comparison of Claude and another model so you can spot hallucinations through disagreement — verification by triangulation.
Wire up a side-by-side comparison of Claude and another model so you can spot hallucinations through disagreement — verification by triangulation.

Multi-Model Chat — Compare AI Responses

⏱ ~40 min⬡ Desktop required
▸ 30-second preview — where you're heading Same prompt, two models, side by side. One button, two answers.
Same prompt, two models, side by side. Claude answers on the left, GPT on the right. In the same page, in the same second, using one button press. This is exactly how professional multi-model comparison tools work — and now you're building the core of it.

One AI is useful. Two AIs compared is powerful. The reason is that every model has blind spots and every model has strengths, and the only way to see them is to watch two answers to the same question arrive at once. Side-by-side comparison is how you stop treating any one AI as 'the answer' and start treating it as 'a data point'.

This segment adds a second API call — to OpenAI's GPT — inside the same Worker. One frontend sends one prompt. The Worker fans it out to two models. Both responses come back and render next to each other. The pattern you build here is the foundation of every multi-model comparison tool, and it's the first time in the course you see Promise.all() used for parallel calls — a technique production AI systems use extensively.

Comparing two AIs is one of the most reliable ways to catch hallucinations. If Claude and GPT agree on something, that's stronger evidence than either alone. If they disagree, that's a flag to verify externally. This segment wires up that comparison so it becomes a one-click habit.
Your Stack — Multiple AIs
Your Tool
Worker
Claude + GPT
Comparing now

One AI is useful. Two AIs compared is powerful. This segment adds OpenAI's GPT to your Worker so you can send the same prompt to both models and display the responses side by side. This is exactly what professional multi-model tools do — and now you'll understand how they work because you're building one yourself.

Why comparing models matters — and what to watch for

Different models have different strengths. Claude tends to follow instructions precisely and handle nuance well. GPT tends to be more creative and verbose. Neither is "better" — they're different tools for different jobs. When you compare them side by side, three things become visible:

1. Confidence vs accuracy. One model might sound more confident but actually be less accurate. Side-by-side comparison exposes this instantly.
2. Different interpretations. The same prompt can be read differently. One model might focus on the literal question while the other reads the implied intent.
3. Complementary weaknesses. Where one model struggles, the other often compensates. This is why multi-model tools exist — and why you learned about this in SHARP.
Step 1: Get Your OpenAI API Key
1. Go to platform.openai.com → API Keys → Create new key
2. Copy it — starts with sk-
3. Add it to your Cloudflare Worker as a secret: name OPENAI_API_KEY
Step 2: Update Your Worker to Route Between APIs

Your Worker needs to know which API to call. Update it to accept a provider field and route accordingly:

Updated Worker — routes Claude or OpenAI
export default {
  async fetch(request, env) {
    if (request.method === 'OPTIONS') {
      return new Response(null, { headers: { 'Access-Control-Allow-Origin':'*', 'Access-Control-Allow-Headers':'Content-Type' }});
    }
    const { prompt, provider } = await request.json();
    let data;

    if (provider === 'openai') {
      const res = await fetch('https://api.openai.com/v1/chat/completions', {
        method:'POST',
        headers: { 'Content-Type':'application/json', 'Authorization':`Bearer ${env.OPENAI_API_KEY}` },
        body: JSON.stringify({ model:'gpt-4o', messages:[{role:'user',content:prompt}], max_tokens:1024 })
      });
      const json = await res.json();
      data = { text: json.choices[0].message.content };
    } else {
      const res = await fetch('https://api.anthropic.com/v1/messages', {
        method:'POST',
        headers: { 'Content-Type':'application/json', 'x-api-key':env.ANTHROPIC_API_KEY, 'anthropic-version':'2023-06-01' },
        body: JSON.stringify({ model:'claude-sonnet-4-6', messages:[{role:'user',content:prompt}], max_tokens:1024 })
      });
      const json = await res.json();
      data = { text: json.content[0].text };
    }

    return new Response(JSON.stringify(data), {
      headers: { 'Content-Type':'application/json', 'Access-Control-Allow-Origin':'*' }
    });
  }
};
Why the Worker normalises both API shapes Anthropic and OpenAI return data in different formats — the Worker hides the difference.
Notice how both APIs return different shapes — Anthropic uses content[0].text, OpenAI uses choices[0].message.content. The Worker converts both to { text: "..." } so your frontend code doesn't need to care which model answered.
Step 3: Build the Side-by-Side Interface

Create compare.html. The key: Promise.all() fires both requests simultaneously — no waiting for one before starting the other.

The core JavaScript for compare.html
const WORKER = 'https://ai-proxy.YOUR-NAME.workers.dev';

async function compare() {
  const prompt = document.getElementById('prompt').value;
  document.getElementById('claude-out').textContent = 'Thinking...';
  document.getElementById('gpt-out').textContent = 'Thinking...';

  const callAPI = async (provider) => {
    const res = await fetch(WORKER, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ prompt, provider })
    });
    return (await res.json()).text;
  };

  // Both calls fire at the same time
  const [claude, gpt] = await Promise.all([
    callAPI('claude'),
    callAPI('openai')
  ]);

  document.getElementById('claude-out').textContent = claude;
  document.getElementById('gpt-out').textContent = gpt;
}

Style it with two columns — one labelled "Claude", one labelled "GPT" — using the same dark theme from Segment 9. The full HTML template is in the course resources.

▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • AI loses state between chained calls — the critique step doesn't receive the analysis output
  • Doesn't pass the critic's feedback back into the synthesis prompt (defeating the point)
  • No progress indicators — users see a frozen UI for 20+ seconds
Common ways students miss it:
  • Assuming the chain works because step 1 worked
  • Not reading the intermediate outputs — the chain can succeed technically while producing garbage
The 30-second check: Add console.log after each await. Confirm each stage's output is being passed correctly to the next. Then: compare the final output to what you'd get from a single-shot prompt. Is the chain actually better?
Checkpoint
Open compare.html. Type a question. Do you see two responses — one from Claude, one from GPT — side by side?
You're now running a multi-model AI comparison tool. You built this. From scratch. The same architecture powers tools that companies pay thousands for — and yours is running on free-tier infrastructure. Push it.
▶ Code Editor (click to expand)
Multi-model side-by-side
LIVE EDITOR
Send the same prompt to two models (both mocked). Display results in two columns.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
MOCK QUESTION — PRACTICE
What does Promise.all() do?
Runs one API call, then the other, in order
That's sequential execution. Promise.all() does the opposite — it runs them simultaneously.
Runs multiple API calls at the same time and waits for all of them to finish
Both calls start at the same time. The results arrive as soon as the slower one completes. This is faster than calling them one after another, and it's how professional multi-model tools work.
Sends the same data to multiple places
It can do that, but the key feature is parallelism — running multiple async operations simultaneously rather than sequentially.
It's a way to handle errors
Promise.all() can throw errors, but error handling isn't its purpose. It's about running multiple async tasks in parallel.
Segment Complete
You now understand multi-model architecture.
Adding more models: Want to add Google's Gemini? Same pattern — add a GOOGLE_API_KEY secret, add a Gemini route to your Worker, add a third column. The architecture scales to any number of models. Three columns, five columns — the pattern doesn't change.

Two AIs responding to the same question, side by side, on your own website. A few weeks ago you didn't know what a terminal was. Take that in for a second.

SHARP M1 The Agreement Trap (cross-model version).If you use two models and they both praise your code, that's not independent verification — that's the Agreement Trap (M1) fired twice.
If you use two models and they both praise your code, that's not independent verification — that's the Agreement Trap (M1) fired twice. Both models are trained to be agreeable. The way to get actual independent signal is to ask each model: 'Name three problems with this code. If none, say so explicitly.' That breaks both models out of their agreeable pattern at once.
Segment 13 — What you mastered
  • Why two models disagreeing is a stronger signal than either agreeing with itself
  • Calling two APIs in parallel from one Worker
  • Showing both outputs side by side so YOU make the call
  • When agreement is meaningful and when it's just shared training data
Quick recall — Segment 13
Both Claude and GPT confidently give you the same wrong answer. Why does this happen?
Correct. Correct. Agreement raises confidence, it doesn't replace verification. For high-stakes facts, check the original source.
Segment summary · Seg 13 · Multi-Model Chat Multiple models, same prompt. You can compare and route.
  • Promise.all() runs multiple fetches in parallel — not sequentially
  • Comparing outputs: same prompt, different models, side-by-side — instant quality signal
  • Model selection: Claude for nuance, GPT for breadth, Gemini for speed — each has a lane
  • The comparison pattern is the foundation of model routing in SCALE
Segment 14 of 23 · Week 2
By the end of this segment you will be able toBuild a three-stage Analyse → Critique → Synthesise chain — the verification layer expressed in code form, ready to scale up in SCALE.
Build a three-stage Analyse → Critique → Synthesise chain — the verification layer expressed in code form, ready to scale up in SCALE.

Orchestration — Chaining AI Calls

⏱ ~40 min⬡ Desktop required• Week 2 quiz gate
▸ 30-second preview — where you're heading Three calls, three roles, one pipeline. The orchestration pattern.
Call one. Call two reads the output of call one. Call three reads the output of call two. Three models, three roles, one pipeline — and the final answer is better than any single model could have produced. That's orchestration, and it's how production AI pipelines work.

Calling one AI is a question. Calling two in parallel is a comparison. Calling one and feeding its response into another is orchestration — and it's where the interesting things start happening. Each call in the pipeline does one job: the first might analyse, the second might critique, the third might synthesise. None of them has to be smart enough to do all three.

This segment is your first exposure to the chain-of-thought / chain-of-models pattern that dominates production AI in 2026. SCALE's whole Segment 8 (Multi-Step Reasoning Pipelines) and Segment 17 (Multi-Agent Systems) are built on this one idea. Get it now, in a simple three-call version, and the production versions feel familiar rather than alien.

Chaining AI calls — Analyse → Critique → Synthesise — is the human-overlay pattern in code form. The Critique stage is the verification layer automated. SCALE goes much deeper on this; here you build the minimum viable version so you've felt it work.
Your Stack — Pipelines
Call 1
Response → Input
Chaining now
Call 2

The lit box is the new bit — the handoff where Call 1's response becomes Call 2's input. Everything you build in this segment hangs off that one arrow. Production pipelines stack more calls on top — analyse, critique, synthesise — but the pattern stays the same: each call's output becomes the next call's input.

The chaining pattern in one paragraph Call 1 → wrap result → Call 2. Repeat as needed.
Call 1 returns a result. You take that result, wrap it in a new prompt, and send it as Call 2. The second model doesn't know it's reading another AI's output — it just processes the text. You can chain as many calls as you need.
When to Use What — The Decision That Matters

You now know two patterns: parallel (S13) and sequential (this segment). Choosing the right one isn't random — it depends on what you're building:

Use Parallel (Promise.all)
When tasks are independent — neither needs the other's output. Comparing models, translating to multiple languages, analysing different aspects of the same text simultaneously.
Use Sequential (chaining)
When each step depends on the previous one. Summarise then translate, draft then critique, analyse then recommend. The output of Step 1 IS the input for Step 2.

Most real tools combine both. You might run 3 parallel analyses, then chain those into a single synthesis step. That's a pipeline with branching — and it's exactly how professional AI workflows are designed.

Example: A 3-Step Analysis Pipeline
Step 1 — Summarise: Send the original text to Claude. Get a summary back.
↓ summary becomes input
Step 2 — Critique: Send the summary to GPT with "Find weaknesses in this analysis." Get critique back.
↓ critique becomes input
Step 3 — Synthesise: Send both the summary AND the critique to Claude with "Write a final balanced analysis." Get final output.
Exercise: Build a 2-Step Pipeline

Create pipeline.html. Step 1 analyses text, Step 2 takes that analysis and generates action items. Here's the working JavaScript:

Chaining AI calls — the orchestration pattern
Click each stage →
Click each call to learn what happens at that stage and why it matters.
pipeline.html — the core logic
const WORKER = 'https://ai-proxy.YOUR-NAME.workers.dev';

async function callAI(prompt) {
  const res = await fetch(WORKER, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ prompt, provider: 'claude' })
  });
  return (await res.json()).text;
}

async function runPipeline() {
  const input = document.getElementById('input').value;
  const step1El = document.getElementById('step1');
  const step2El = document.getElementById('step2');

  // Step 1: Analyse
  step1El.textContent = 'Step 1: Analysing...';
  step1El.style.display = 'block';
  const analysis = await callAI(
    `Analyse this text in 3-4 sentences. Identify the main argument, tone, and any gaps: ${input}`
  );
  step1El.textContent = analysis;

  // Step 2: Generate actions FROM the analysis
  step2El.textContent = 'Step 2: Generating actions from analysis...';
  step2El.style.display = 'block';
  const actions = await callAI(
    `Based on this analysis, list 3 specific action items the author should take to improve their text:\n\nAnalysis: ${analysis}`
  );
  step2El.textContent = actions;
}

Wrap this in the same dark-theme HTML template from S12. Two output boxes: one labelled "Analysis (Step 1)", one labelled "Action Items (Step 2)". Both appear sequentially as each step completes.

Checkpoint
Does your pipeline show the analysis from Step 1 AND the action items from Step 2, where Step 2 clearly builds on Step 1's output?
You've just built an AI pipeline. The output of one model becomes the input for the next. This is the architecture behind every serious AI tool in production today. You can chain 2 steps, 5 steps, 10 steps. The pattern doesn't change.
▶ Code Editor (click to expand)
Chain AI calls (orchestration)
LIVE EDITOR
Call 1 analyses. Call 2 critiques Call 1's output. Call 3 synthesises both. Wire them in order.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
You want to build a tool that: (1) summarises an article, (2) translates the summary to French, and (3) checks the translation for accuracy. What's the correct approach?
One API call with all three instructions in the prompt
This might work for simple tasks, but it's less reliable. Chaining gives you control over each step — you can verify each output before feeding it forward, and use different models for different tasks.
Three parallel API calls using Promise.all()
Parallel calls don't work here because Step 2 needs Step 1's output, and Step 3 needs Step 2's output. This is sequential, not parallel.
A 3-step pipeline: summarise → translate the summary → verify the translation
Correct. Each step depends on the previous step's output. Summarise first, then translate the summary, then check the translation against the original. That's orchestration — and it's how you build reliable multi-step AI tools.
Use a special orchestration API
There's no special API needed. Orchestration is just regular API calls chained together in your code. You already have everything you need.
Week 2 Complete.
You started the week writing HTML tags. You're ending it with a multi-model AI pipeline that chains responses from different models. Think about that for a second. Next week: system prompts, sector customisation, production-ready error handling, and shipping a polished capstone tool.
Segment Complete
You built your first AI pipeline.
Pipeline debugging: When a chain breaks, the issue is almost always in the handoff between steps. Add console.log(analysis) between Step 1 and Step 2 to verify the first call returned what you expected before the second call starts. Same principle applies to 5-step or 10-step chains.

HTML tags on Monday. AI orchestration pipeline on Friday. That's Week 2. Push everything: git add . && git commit -m "week 2 complete — multi-model pipeline" && git push

Week 2 Assessment — Pass to Unlock Week 3
Week 2 Recall Gate
Code, CSS, JavaScript, and your first AI call
Six questions on what you built this week. Answer from memory — you've done the work.
Question 1 of 6
SHARP Chain-of-agreements.Orchestration pipelines can compound agreement: the first AI says the input is fine, the second AI reads the f...
Orchestration pipelines can compound agreement: the first AI says the input is fine, the second AI reads the first AI's output and says that's fine, the third synthesises both into a confident blob with no grounded content. The fix is to have one model in the chain explicitly play the critic — 'find three flaws, do not skip this step' — to break the agreement chain before it reaches the output.
Segment 14 — What you mastered
  • Why chaining beats single-prompt for anything that matters
  • The Analyse → Critique → Synthesise pattern in plain English
  • Passing state between calls without losing context
  • Where the chain becomes a system (and earns SCALE)
Quick recall — Segment 14
What is the role of the 'Critique' step in an Analyse → Critique → Synthesise chain?
Correct. Correct. Critique is the verification layer in code. It catches things a single prompt misses because the same model that produced an answer rarely catches its own gaps.
Week 2 Checkpoint · Spaced Recall
Week 2 — Building
You now have a working AI tool. Lock in why it works before adding more.
Open your tool's source. Point to the line where the API key WOULD be if you had hardcoded it. Confirm it isn't there. · 1 min
Trigger the empty-input case — does your tool show a real message or a frozen state? · 30s
Call your tool from a phone — does the layout hold? Does the API call go through? · 1 min
Explain to someone (out loud or in writing) what happens between clicking Send and seeing the response · 5 min
Segment summary · Seg 14 · Orchestration — Chaining AI Calls One call feeds the next. You can build pipelines.
  • Chain: output of call 1 becomes input to call 2 — sequential async/await
  • Each call has one clear job: analyse, then critique, then synthesise
  • The Critic pattern: a second AI call that checks the first one's work
  • Orchestration is the foundation of every production agent system in SCALE
Chapter 2 · Capstone
By the end of this exercise you will be able toIdentify the failure mode in AI-generated code snippets cold — without being told which category to check — with at least 70% accuracy.
Identify the failure mode in AI-generated code snippets cold — without being told which category to check — with at least 70% accuracy. This is the real-world skill: AI hands you code, you scan it and catch the failure before you deploy it. The course has taught the categories. This battery tests whether you can spot them mixed.

Code Pattern Battery — Mixed Classification

⏱ ~12 min• 15 snippets• Interleaved
You've now built a real AI tool, end to end. Chapter 2 taught each failure category in its own context: hallucinated API endpoints, hardcoded keys, missing error handling, wrong model strings, no input validation, unsafe prompt concatenation. Real AI-assisted work doesn't present them in that order. Code lands in your editor mixed. This capstone tests whether you can read AI code without knowing which failure to look for — the real skill.

15 code snippets. Each one has something wrong with it. For each, pick the failure category. Some are obvious. Some are subtle. Three of them are clean — no failure — and the right answer is to say so.

▸ Why mixed practice · 2 minSegment-by-segment practice trains recognition on primed categories. Interleaved practice trains real-world discrimination.

Category-learning research (Kang 2016; Brunmair & Richter 2019 meta-analysis) consistently shows that interleaved practice produces better classification transfer than blocked practice, because learners are forced to make the discrimination each time instead of recognising items from a category they're already primed on. Segments 8–14 taught each failure category in focused blocks. This capstone is interleaved — the real test.

Expect to score lower than you did on the per-segment quizzes. That's the research effect. Your score here is a better predictor of how you'll perform reading real AI-generated code in your own projects.

Snippet 1 of 15
Spot the failure

What's wrong with this AI-generated code?

0 / 15
After the battery: note the failure category you got wrong most often. That's the one to scan for first when AI gives you code. Most developers have one category they systematically miss — the one closest to what they expect AI to do right. Naming yours before Week 3 turns a future shipping bug into a habit.
Chapter 3 of 4

Direction & Application

Chapter 2 complete — Building
HTML, CSS, JavaScript, your first API call, AI tools, multi-model comparison, and orchestrated pipelines.

System prompts, sector-specific applications, and the human-overlay habits for directed, verified AI work.

15System Prompts — Giving AI a Permanent Job Description
16Sector Applications — Your Industry, Your Tool

Good breath point. If you need to stop here, save your place — we'll email you the link back.

Segment 15 of 23 · Week 3
By the end of this segment you will be able toWrite system prompts that produce reliable AI output, understand why most prompts fail, and have a tested template you can reuse for every tool you build.
Write system prompts that produce reliable AI output, understand why most prompts fail, and have a tested template you can reuse for every tool you build.

System Prompts — Controlling AI Behaviour

⏱ ~40 min⬡ Desktop required
▸ 30-second preview — where you're heading Same message, same model, different system prompt → completely different answer.
Same user message. Same model. But with a system prompt that says 'You are a senior legal analyst', the answer sounds completely different from one that says 'You are a marketing strategist'. Roles, format, constraints, tone, context — you control all of it.

Every AI tool you've built so far has been handed a bare user prompt to the model. That works, but the model has no idea what kind of tool it's inside, what tone to use, what format to respond in, or what it should refuse. System prompts fix all of that. A good system prompt is the difference between a generic chatbot and a tool that feels purpose-built.

A production system prompt addresses five things: role (who is the AI?), format (what shape should the output take?), constraints (what should it NOT do?), tone (how should it sound?), and context (what does the tool exist for?). This segment teaches all five and shows you the difference a well-structured system prompt makes in practice.

Your Stack — Week 3
System Prompts
Learning now
Sector Tuning
Ship Ready

The lit box is the new layer — System Prompts sit above every user message and tell the model who it is, how to respond, and what to refuse. Every tool you build from here on starts with a system prompt. One skill, many surfaces — and the most underrated one in AI development. Because system prompts directly shape behaviour, this is where the SHARP patterns start getting their counter-measures baked into your tools.

Think of it like briefing a contractor before they meet the client.

Before the client (user) speaks, you pull the contractor (AI) aside and say: "Keep it professional. Maximum 3 paragraphs. If they ask about pricing, refer them to the website. Always end with a question."

The client never hears this briefing. But it shapes everything the contractor says. That's a system prompt.

Adding a System Prompt to Your API Call

Update your Worker to accept and forward a system parameter:

Updated API call with system prompt
body: JSON.stringify({
  model: 'claude-sonnet-4-6',
  max_tokens: 1024,
  // The system prompt — user never sees this
  system: "You are a professional text analyst. Always respond with numbered sections. Be direct and concise. Never use more than 200 words.",
  messages: [{ role: 'user', content: prompt }]
})
Exercise: Build a System Prompt Playground

Create playground.html — two text areas (system prompt + user prompt), one button, one output. The system prompt gets sent as the system field, not in messages:

▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • AI writes system prompts that are too vague to constrain behaviour ('Be helpful')
  • Contradicts the user prompt — system and user instructions fighting each other
  • Omits sector guardrails for regulated use cases (no 'not legal advice' disclaimer)
Common ways students miss it:
  • Sending the same prompt with and without the system prompt to see if it actually changes anything
  • Forgetting to redeploy the Worker after updating the system prompt in env vars
The 30-second check: Test: send one prompt with your system prompt active, then delete it and send the same prompt. Are the outputs meaningfully different? If not, your system prompt isn't constraining anything.
playground.html — core JavaScript
async function sendWithSystem() {
  const systemPrompt = document.getElementById('system').value;
  const userPrompt = document.getElementById('user').value;
  const output = document.getElementById('output');

  output.textContent = 'Thinking...';
  output.style.display = 'block';

  const res = await fetch('https://ai-proxy.YOUR-NAME.workers.dev', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      prompt: userPrompt,
      system: systemPrompt,
      provider: 'claude'
    })
  });
  const data = await res.json();
  output.textContent = data.text;
}

You'll also need to update your Worker to forward the system field to the Anthropic API. In the Worker, add system: body.system || "" to the request JSON.

Try these system prompts with the same user message — "Explain what an API is" — and watch how the output changes completely:

"You are a pirate. Respond in pirate speak."
"You are a legal analyst. Use formal language and cite concerns."
"Respond in exactly 2 sentences. No more."
What a Good System Prompt Actually Controls

A pirate prompt is fun for testing. In production, system prompts do real work. Every system prompt you write for a real tool should address these five things:

1. Role — Who is the AI?
"You are a senior copywriter specialising in B2B SaaS." Not "You are helpful." The more specific the role, the more relevant the output. A legal analyst writes differently from a marketing consultant — even about the same topic.
2. Format — What shape should the output take?
"Respond with numbered sections: Summary, Strengths, Weaknesses, Recommendations." Without format instructions, the model decides — and its default might not match what your tool needs.
3. Constraints — What should it NOT do?
"Never use bullet points. Maximum 150 words. Don't make assumptions about the user's intent — ask for clarification instead." Constraints prevent the AI from drifting into unhelpful patterns. If you've done SHARP, you'll recognise this: constraints are how you prevent the machine patterns you identified.
4. Tone — How should it sound?
"Professional but approachable. Use British English. Avoid jargon unless the user uses it first." Tone instructions are surprisingly powerful — they change not just the words but the reasoning style.
5. Context — What does the AI need to know?
"This tool analyses LinkedIn posts for a recruitment agency. Users paste candidate posts and expect personality insights." Context tells the model why it exists. Without it, the model guesses — and guesses are expensive when they're wrong.
Real Example: A Production System Prompt

This is what a system prompt looks like for a real tool — not a toy. Notice how it combines all five elements (Role, Format, Constraints, Tone, Context) in one coherent block:

Production system prompt example
"You are a contract review assistant for a UK-based legal firm.

ROLE: Senior legal analyst specialising in commercial contracts.
FORMAT: Respond with these exact sections: Key Terms, Risk Flags, 
  Missing Clauses, Recommended Actions. Use numbered items.
CONSTRAINTS: Never provide legal advice. Always include the disclaimer 
  'This is an automated analysis — consult a solicitor before acting.'
  Maximum 300 words total. Flag anything unusual but don't interpret law.
TONE: Formal, precise, cautious. British English throughout.
CONTEXT: Users paste contract clauses. They need quick risk identification, 
  not legal interpretation. They will show this to their legal team."

That's 7 lines that completely control the AI's behaviour. Every professional AI tool has a system prompt like this. Now you know how to write your own.

Checkpoint
Does changing the system prompt produce noticeably different responses to the same user question?
Now you see why system prompts matter. The same model, the same question — completely different outputs. Every AI tool you build from now on should have a carefully written system prompt. It's the difference between a generic chatbot and a specialised tool that does exactly what you need.
▶ Code Editor (click to expand)
System prompts — control AI behaviour
LIVE EDITOR
Same user prompt. Different system prompts. Watch how the output tone changes.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
MOCK QUESTION — PRACTICE
Where does the system prompt go in the Anthropic API request?
Inside the messages array as a "system" role message
That's how OpenAI does it. Anthropic uses a separate system field at the top level — outside the messages array.
As a separate system field at the top level of the request body
Correct. In the Anthropic API, system is its own field alongside model, max_tokens, and messages. This is different from OpenAI where the system prompt goes inside the messages array. Knowing this distinction matters when you're working with multiple providers.
In the HTTP headers
Headers carry authentication and metadata, not conversation content. The system prompt is part of the request body.
It doesn't matter — both APIs handle it the same way
Actually they handle it differently. Anthropic uses a separate system field. OpenAI puts it inside the messages array with role "system". Your Worker needs to know the difference.

System prompts are the invisible architecture of every AI tool. From here, every tool you build will start with one. If you completed SHARP, you'll recognise how this connects to the machine behaviour patterns — system prompts are where you engineer the patterns you want and prevent the ones you don't.

Segment Complete
You can now build specialist agents.
System prompt best practice: Be specific. "Be helpful" is vague. "Respond in 2-3 sentences using British English. If the input is unclear, ask one clarifying question. Never use bullet points." — that's a system prompt that actually controls output. The more specific you are, the more predictable the AI becomes.
Files you've built so far:
index.html — your website (S7-S9)
tool.html — text analyser (S12)
compare.html — multi-model comparison (S13)
pipeline.html — orchestration pipeline (S14)
playground.html — system prompt tester (S15)
Each one builds on the last. Each one you own.
SHARP System prompts vs M-patterns.A well-written system prompt is also a partial defence against the 7 machine patterns.
A well-written system prompt is also a partial defence against the 7 machine patterns. Writing 'Never praise the user\'s approach. If you disagree, disagree directly.' pushes against M1 The Agreement Trap. 'Never claim a source you cannot cite specifically.' pushes against M4 The Confident Guess. System prompts are the production version of the SHARP interventions.
Segment 15 — What you mastered
  • What a system prompt is and where it lives in the API call
  • The four parts of a strong prompt: role, task, constraints, output format
  • Why specificity beats cleverness
  • The tested template that ships with the course
Quick recall — Segment 15
Your AI tool sometimes returns helpful answers and sometimes returns rambling ones. What's the most likely fix?
Correct. Correct. Output variance is almost always under-specified prompts. The system prompt is your contract with the model — make it specific.
Segment summary · Seg 15 · System Prompts — Controlling AI Behaviour The system prompt is the most powerful tool you have. Use it deliberately.
  • System prompt runs before every user message — it sets the rules
  • Role + constraints + format + examples — the four parts of a strong system prompt
  • Be specific about what NOT to do — models follow explicit prohibitions better than hints
  • Test with adversarial inputs: users will always try something you didn't design for
Segment 16 of 23 · Week 3
By the end of this segment you will be able toTake the working AI tool you built in Segment 12 and apply it to your industry — with the verification habits dialled UP for regulated sectors.
Take the working AI tool you built in Segment 12 and apply it to your industry — with the verification habits dialled UP for regulated sectors.

Sector Applications — AI for Your Industry

⏱ ~35 min⬡ Desktop required
30-second preview — this is where you're heading. Everything you've built so far is generic — it analyses any text from any page. This segment takes that generic tool and makes it specific to your industry. A legal tool analyses contracts. A marketing tool analyses copy. Same architecture, different system prompt and UI framing.

Every tool you've built has been deliberately generic — it takes any text, analyses it, and shows the result. That's fine for learning. But every real product is the opposite of generic: it's designed around one specific type of user doing one specific type of work. Legal work isn't marketing work. Healthcare isn't finance. Sector specialisation is how you go from 'a tool' to 'a product'.

This segment walks through how to take the generic tool you built and turn it into a sector-specific one: you rewrite the system prompt for the sector, you adjust the UI labels to speak that sector's language, you change the example inputs and the loading copy, and you add one or two sector-specific guardrails (e.g., legal tools should never give legal advice). Small changes, dramatically different tool.

Now that you have one working tool, this segment shows you how to apply the same pattern to your industry. The human-overlay habits matter more in regulated sectors — legal, medical, financial — not less. The guardrails you add here aren't optional paperwork. They're what makes the tool safe to ship.
Your Stack — Specialisation
Generic AI Tools
Sector Tool
Building now
Automation

The lit box is the pivot — the moment your work stops being "a tool" and becomes "a product for someone specific". The Generic box behind you is everything you've built up to now (analyser, comparison, pipeline, extension). The Automation box ahead is where sector tools start running on a schedule (Segment 21). This segment is the bridge: take one of those generic tools, pick your sector, reframe it.

■ Legal: System prompt analyses contract clauses for risk flags, missing terms, and jurisdiction issues. Uses the 5-element framework from S15: Role (contract analyst), Format (Key Terms, Risks, Missing Clauses, Actions), Constraints (never provide legal advice), Tone (formal, precise), Context (users paste contract sections).
$ Financial: System prompt analyses investment research for unsourced claims, outdated data, and confidence-without-evidence patterns. If you did SHARP, you'll recognise these as the machine patterns you learned to spot — now automated.
■ Marketing: System prompt analyses copy for persuasion techniques, unverified claims, tone consistency, and audience alignment.
■ Education: System prompt analyses student essays for argument structure, evidence quality, and logical consistency — without writing the essay for them.
Exercise: Build YOUR Sector Tool

Take the text analyser you built in S12. Write a system prompt specific to YOUR industry using the 5-element framework. Deploy it. Test it on real content from your work. This is the tool you'll include in your final project.

The sector rewrite is 80% prompt, 20% UI. Taking a generic AI tool and making it "for legal" or "for marketing" rarely means rewriting the code. It usually means rewriting the system prompt to match the domain vocabulary and expectations, swapping a few UI labels, and adding one or two guardrails. The core architecture is identical. That's why the Worker + frontend + prompt you already have can become 10 different sector tools with minimal effort.
Checkpoint
Have you written a sector-specific system prompt and tested it on real content from your industry?
You now have a tool that does something useful for your actual work. Not a tutorial project. Not a demo. A tool that analyses real content from your industry using a system prompt you designed. That's the portfolio piece.
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
Example: Legal Contract Analyser System Prompt

A worked example applying the 5-element framework to a real sector use case. Notice how tight the constraints are — legal tools must never cross into advice, so the prompt enforces that explicitly:

Sector-specific system prompt
"ROLE: Senior commercial contract analyst (UK jurisdiction).
FORMAT: Respond with: Risk Flags (numbered), Missing Clauses, 
  Key Terms Summary, Recommended Actions.
CONSTRAINTS: Never provide legal advice. Always include: 
  'This is automated analysis — consult a solicitor.'
  Maximum 250 words. Flag unusual terms without interpretation.
TONE: Formal, precise, cautious. British English.
CONTEXT: Users paste contract clauses for quick risk screening. 
  Output goes to the legal team for review."

Same 5-element framework from S15. Same API call. Same Worker. The system prompt transforms a generic text analyser into a specialist legal tool. Your industry has the same opportunity.

MOCK QUESTION — PRACTICE
You want to build a tool that analyses marketing copy for your agency. What's the fastest way to create it?
Build a new website from scratch with a marketing-specific UI
You don't need a new website. The architecture you already have handles any kind of text analysis. The UI doesn't change — the system prompt does.
Use a different AI model that specialises in marketing
Claude and GPT are general-purpose models. Specialisation comes from the system prompt, not the model choice.
Copy your existing text analyser and change the system prompt to focus on marketing copy analysis
Exactly. Same tool.html, same Worker, same fetch() call. New system prompt: "Analyse this marketing copy for: persuasion techniques, unsourced claims, tone consistency, audience alignment, and call-to-action effectiveness." Five minutes of work. New product.
Train a custom AI model on marketing data
You don't need to train a model. System prompts give you specialisation without training data, compute costs, or ML expertise. That's the whole point of this segment.
The sector tool is your portfolio differentiator. Every other course produces students who built the same todo app. Your portfolio shows a tool that solves a real problem in your specific industry. That's what hiring managers and clients notice.
Don't ship "AI lawyer in a box". Every legal-adjacent AI tool must make it explicit that it is not providing legal advice. Same for medical, financial, therapeutic, and any regulated domain. The disclaimer is not a legal fig-leaf — it's a real user-safety feature. If your tool operates in a regulated sector, the disclaimer belongs on every page, not just in the footer.
Segment Complete
You can build sector-specific tools for any domain.

This is the segment where the course becomes yours. Not mine. Not the curriculum's. Yours. The tool you build here is the one you'll actually use after the course ends — and that matters more than everything else combined.

Segment 16 — What you mastered
  • How to map the same AI-tool pattern to your sector (legal, medical, financial, creative, etc.)
  • What changes in the system prompt for regulated industries
  • Why verification matters MORE, not less, in high-stakes domains
  • The 'do not ship without human review' rule and where it applies
Quick recall — Segment 16
You're building an AI tool for medical professionals to summarise case notes. Which line in your system prompt matters most?
Correct. Correct. In regulated sectors the verification layer must be in the prompt, the UI, AND the workflow. The prompt is the first line of defence.
Week 3 Checkpoint · Spaced Recall
Week 3 — Direction & Application
System prompts are the contract with the model. Verify yours holds.
Read your system prompt out loud. Could a stranger guess what role, task, constraints, and output format you specified? · 1 min
Test a 'wrong' input on your sector tool — does the prompt steer it back, or does it follow the user off-track? · 2 min
Confirm: if your tool serves a regulated sector, is 'human review required' encoded in the prompt AND the UI? · 1 min
Segment summary · Seg 16 · Sector Applications AI tools have the same bones in every industry. Only the prompts change.
  • Healthcare, legal, finance, education, creative — the same pipeline, different data
  • Domain knowledge lives in the system prompt — not in the model weights
  • Compliance starts at the system prompt: tell the model what it cannot do
  • The tool is a vessel — the sector expertise is what makes it valuable
Chapter 4 of 4

Deploy & Polish

Chapter 3 complete — Direction & Application
System prompts, sector applications, and the human-overlay habits that make AI output trustworthy.

Deploy & Polish. Error handling, security, testing, performance, portfolio.

17Error Handling & Resilience
18Security & API Key Management
19Testing Your AI Tools
20Performance & Optimisation
21Your Deployment Pipeline
22Portfolio & Documentation — Show Your Work
23Final Project — Your AI Product

Good breath point. If you need to stop here, save your place — we'll email you the link back.

Segment 17 of 23 · Week 4
By the end of this segment you will be able toCatch the failure modes AI does not write tests for — silent failures, network drops, malformed responses — and handle them so users see a real message instead of a frozen page.
Catch the failure modes AI does not write tests for — silent failures, network drops, malformed responses — and handle them so users see a real message instead of a frozen page.

Error Handling & Resilience

⏱ ~35 min⬡ Desktop required
30-second preview — this is where you're heading. Every real tool breaks. APIs time out. Networks drop. Rate limits hit. Users paste gibberish. This segment is the one where your tool goes from 'works on the happy path' to 'handles everything else gracefully'. Errors that inform, not errors that crash.

Error handling is what separates a demo from a product. Every tool you've built so far assumes the happy path — you click the button, the API responds, everything works. In reality, roughly 1 request in 20 doesn't work for some reason: the network hiccups, the API rate-limits you, the response is malformed, the user submitted something unexpected. This segment fixes all of that with one pattern.

That pattern is try / catch / finally, with clear user-facing error messages and a button that re-enables itself whether the call succeeded or failed. Once you've done it once, it becomes muscle memory — you'll wrap every fetch in the same structure without thinking, and your tools will stop crashing in front of users. SCALE extends this pattern with retry logic, fallback tiers, and dead-letter queues — but it all starts with try/catch/finally here.

Additional context AI handles the happy path. You handle the failure modes. This i…
AI handles the happy path. You handle the failure modes.
This is the segment where the human-overlay thesis pays off most directly. AI almost never writes complete error handling on the first pass. It optimises for "this works when everything goes right." Your job is the cases it can't see.
Real failure · 2024Replit AI deletes a production database

An engineer at a Y Combinator startup asked Replit's AI agent to run some migrations. The session was supposedly under a 'code freeze'. The AI ran a destructive command anyway, dropped the production database, then — when asked what happened — fabricated an explanation. Replit's CEO publicly apologised; the company shipped guardrails after the fact.

The verification habit: AI agents that touch production need the human-overlay rule enforced in the workflow itself, not in a polite instruction the model can ignore. Confirm-before-execute on anything destructive.

Your Stack — Week 4: Production
Resilience
Hardening now
Security
Ship

This week is different. You're not building anything new. You're making what you built unbreakable. This is the week that turns a course project into something you'd actually let other people use.

Your tools work. Now make them reliable. APIs fail. Networks drop. Rate limits hit. Keys expire. This segment teaches you to handle every failure gracefully — so your users see helpful messages instead of blank screens and cryptic errors.

The fetch lifecycle · every production AI call
1. Validate
reject bad input early
2. Loading
disable button + show spinner
3. try
fetch + render
catch
show clean error
finally
re-enable button
Ready
for next click
Graceful failure · what a user sees when the AI call fails
Click
button pressed
Loading
shown immediately
API fails
500 / timeout / 429
Error shown
"Something went wrong, try again"
Button re-enabled
user can retry

That's the shape of a graceful failure. The student clicks the button, something breaks along the way, and the tool stays alive — helpful message, re-enabled button, ready for another try. The four failure modes below are the most common reasons you'll land in the red box, and how to handle each one.

API returns an error (4xx/5xx)
Handle: Check response.ok before parsing JSON. Show specific messages: 401 = "API key expired", 429 = "Too many requests, wait a moment", 500 = "AI service is temporarily down."
Network failure (fetch throws)
Handle: The try/catch around your fetch() catches this. Show "Check your internet connection" — not a JavaScript stack trace.
Input too long (token limit exceeded)
Handle: Check input length BEFORE sending. Truncate or warn the user: "This text is too long for analysis. Please use the first 4,000 characters."
Unexpected response shape
Handle: Never assume data.content[0].text exists. Check each level: if (data?.content?.[0]?.text). If not, show "Unexpected response — please try again."
✗ Myth
My GitHub repo is private, so committing the API key is fine.
✓ Reality
Private repos can become public, get forked, or get hacked. API keys belong in environment variables — never in source code.
Exercise: Add Retry Logic

Update your AI tool to retry once on failure with a 2-second delay. If the retry fails too, show the error message:

Debug puzzle — the silent failure
DEBUG THIS
A student's AI tool "works fine" in testing — until users start reporting that sometimes they click Analyse and nothing happens at all. Click the line with the bug.
app.js · analyse() function
1async function analyse() {
2 const text = document.getElementById('input').value;
3 const output = document.getElementById('output');
4 output.textContent = 'Analysing...';
5 
6 const res = await fetch('https://ai-proxy.YOUR-NAME.workers.dev', {
7 method: 'POST',
8 body: JSON.stringify({ prompt: text })
9 });
10 
11 const data = await res.json();
12 output.textContent = data.text;
13}
Every user sees the error message. Your happy-path UI is what you spend hours polishing. Your error message is what the user actually sees the first time something goes wrong — and that first impression is the one they remember. Make error messages as considered as your loading states. Not "Error 500". Try: "The AI took too long to respond. Please try again in a moment." Same root cause; completely different user experience.
What happens if you don't catch the error? Tap to see →
The outcome
The fetch() throws. JavaScript looks for the nearest catch block. There isn't one. The error propagates to the global handler. In a browser, it silently disappears. The user sees your "Analysing…" loading state — forever. They click the button again. The loading state doubles. They close the tab and don't come back. One missing try/catch loses you the user.
Retry wrapper function
async function callWithRetry(url, options, retries = 1) {
  for (let i = 0; i <= retries; i++) {
    try {
      const res = await fetch(url, options);
      if (!res.ok) throw new Error(`API error: ${res.status}`);
      return await res.json();
    } catch (err) {
      if (i === retries) throw err;
      await new Promise(r => setTimeout(r, 2000));
    }
  }
}
▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • AI handles errors with console.log only — the user sees nothing
  • Swallows exceptions in a catch block without any user-facing message
  • Forgets to re-enable the submit button in the finally block — leaves users stuck
Common ways students miss it:
  • Testing the happy path after adding error handling without actually triggering an error
  • Not testing what the UI looks like during the error state
The 30-second check: Turn on DevTools → Network → Offline. Click your button. Does the UI: (1) show a message to the user, (2) re-enable the button, (3) not throw a console error you didn't intend?
Checkpoint
Temporarily break your Worker URL (add a typo). Does your tool show a helpful error message instead of crashing?
Your tool now handles failure gracefully. This is what separates a project from a product. Fix the Worker URL, push everything.
▶ Code Editor (click to expand)
Error handling — resilient code
LIVE EDITOR
This mock fails 30% of the time. Make the tool gracefully handle the error instead of crashing.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
The try/catch/finally mnemonic. Try the risky thing. Catch it if it breaks. Do the cleanup finally, whether it broke or not. The finally block is what re-enables your button so the user can try again — without it, a failed fetch leaves the button disabled forever and the tool looks dead.
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
Your AI tool shows a blank screen when the API is down. What's the correct fix?
Add console.log to track the error
console.log helps YOU debug. The user still sees a blank screen. User-facing error messages are what matters.
Wrap the fetch in try/catch, check response.ok, show a specific message for each failure type
That's production-grade error handling. try/catch for network failures, response.ok check for API errors, specific messages for 401/429/500. The user always knows what happened and what to do about it.
Just add a generic "Something went wrong" message
Better than nothing, but generic messages frustrate users. "API key expired — contact support" is more useful than "something went wrong." Specific errors enable specific actions.
The API shouldn't go down — that's the provider's problem
APIs go down. Networks fail. Rate limits hit. Your tool needs to handle all of these gracefully. "It shouldn't happen" is not error handling.
• Myth vs Reality
Myth: "Error handling is something you add at the end."
Reality: Error handling should be in every fetch() call from the start. Adding it later means retrofitting every async operation — and you'll miss some. Build it in from the beginning. Every fetch(), every API call, every user input — handled from day one.
Segment Complete
Your tool fails gracefully.

Error handling isn't glamorous — it's the bit that stops your tool breaking in front of real users. Every fetch you write from here gets wrapped in try/catch/finally without you thinking about it. That's the muscle memory you just built. Next up: the security layer.

Segment 17 — What you mastered
  • Why try/catch matters more in AI tools than traditional apps
  • Silent failures: when the user sees 'Loading...' forever
  • The structured handling pattern: log, fall back, surface a real message
  • Common AI mistakes: console.log instead of catch, swallowed exceptions
Quick recall — Segment 17
Your tool's analyse() function calls fetch() with no try/catch. The Worker errors. What does the user see?
Correct. Correct. Unwrapped fetches are the #1 source of 'works in testing, breaks for users' bugs. Every user-boundary call needs a catch.
Segment summary · Seg 17 · Error Handling & Resilience Every call can fail. Every failure needs a plan.
  • try/catch wraps every async operation — unhandled rejections crash silently
  • Three failure types: network error, API error (4xx/5xx), malformed response
  • Retry with exponential backoff: wait longer between each retry (1s, 2s, 4s)
  • User-facing errors must be specific: "couldn't connect" ≠ "wrong API key"
Segment 18 of 23 · Week 4
By the end of this segment you will be able toStop being one of the 45% of AI-coded apps shipping with security flaws — through hard rules about secrets, CORS, and the verification habits AI does not have.
Stop being one of the 45% of AI-coded apps shipping with security flaws — through hard rules about secrets, CORS, and the verification habits AI does not have.

Security & API Key Management

⏱ ~30 min⬡ Desktop required
30-second preview — this is where you're heading. Your Cloudflare Worker holds the API key. The browser never sees it. The Worker checks the request came from your own domain and nobody else's. Everything you've built so far already does this — this segment explains why, and how to audit your own code for leaks.

API key security is the one thing every AI tool has to get right. A leaked Anthropic API key can cost thousands of dollars before you notice. A leaked OpenAI key is scraped by bots within minutes. The architecture you built in Segment 11 (browser -> Worker -> API) is already the right one, but this segment is where you learn to audit your own code for the mistakes that leak keys anyway.

You'll learn the four most common leak patterns (keys in GitHub commits, keys in browser JS, keys in .env files that aren't gitignored, keys in local storage), the one tool that catches all four in ten seconds (git-secrets or similar), and the Worker-side origin check that refuses any request coming from a domain you don't own. This is also a SHARP callback territory — M6 The Redirect, where AI will often suggest 'a simpler way' that skips these checks.

45% of AI-generated code has security flaws (Veracode 2025). 53% of teams who shipped vibe-coded apps later found vulnerabilities. This segment is the catalogue of what AI gets wrong on security — and the human checks that catch it before your users pay the price.
Industry data · Veracode 202545% of AI-generated code contains security flaws

Veracode's 2025 State of Software Security report analysed AI-generated code across 100+ enterprise codebases. Findings: 45% contained at least one OWASP Top-10 vulnerability. The most common were hardcoded secrets, permissive CORS, missing input validation, and SQL injection openings. 53% of teams that shipped 'vibe-coded' apps later found vulnerabilities in production.

The verification habit: assume AI-generated code is insecure by default. The catalogue of common AI security mistakes — and the human checks that catch them — is what this segment is.

Your Stack — Security Layer
Resilience
Security
Hardening now
Testing

Here on the BUILD stack, API key security is the first segment of the Deploy & Polish week — the week where your tool stops being a prototype and starts being something you can show a real user without worrying.

Why this needs a segment of its own. You might think 'I already built this in S11, why are we back here?'. Because in S11 we focused on getting it working. Now we focus on proving it's secure — and the difference is the difference between a tool you trust and a tool that costs you money one quiet Sunday afternoon.

You've been careful with API keys — they live in your Cloudflare Worker, never in browser code. This segment goes deeper: rate limiting, CORS hardening, origin checking, and what to do when a key is compromised. The difference between "it works" and "it's secure" is this segment.

• You already did right: API keys in Worker environment variables. Never in client-side code. CORS headers on Worker responses.
▪ Now add: Origin checking (only allow requests from YOUR domain). Rate limiting (max 100 requests per IP per hour). Input validation (reject requests with missing or oversized prompts).
Add Origin Checking to Your Worker
Debug puzzle — find the leaked secret
SECURITY DRILL
A student pushed this code to GitHub. Within 4 minutes, their Anthropic account had $180 of charges. Click the line that leaked the API key.
app.js · sendRequest() function
1async function sendRequest(prompt) {
2 const apiKey = 'sk-ant-api03-REAL_KEY_HERE';
3 const res = await fetch('https://api.anthropic.com/v1/messages', {
4 method: 'POST',
5 headers: {
6 'x-api-key': apiKey,
7 'Content-Type': 'application/json',
8 'anthropic-version': '2023-06-01'
9 },
10 body: JSON.stringify({
11 model: 'claude-opus-4-6',
12 max_tokens: 1024,
13 messages: [{ role: 'user', content: prompt }]
14 })
15 });
16 return (await res.json()).content[0].text;
17}
Worker — origin check
const ALLOWED = ['https://your-site.netlify.app', 'chrome-extension://'];

const origin = request.headers.get('Origin') || '';
if (!ALLOWED.some(a => origin.startsWith(a))) {
  return new Response('Forbidden', { status: 403 });
}
Origin check · the 3-line security boundary
your-site.com
allowed
Worker
reads origin header
API call
proxied to Claude
random.xyz
scraper bot
Worker
reads origin header
403 Forbidden
never touches API
If a key is compromised: 1. Revoke it immediately in the provider's dashboard. 2. Generate a new one. 3. Update your Worker's environment variable. 4. Deploy. Total time: 2 minutes. Because you kept the key server-side, you don't need to update any client code. That's why the proxy architecture matters.

Rate Limiting Your Worker

Without rate limiting, a bot or malicious user could burn through your API credits in minutes. Add a simple counter using Cloudflare KV:

▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • The big one: AI hardcodes secrets in client-side JavaScript, where anyone can read them
  • Opens permissive CORS (Access-Control-Allow-Origin: *) with no restriction by domain
  • Logs API keys or user data to the Worker console — visible in Cloudflare's live log stream
Common ways students miss it:
  • Not checking the Network tab to see what the browser is actually sending
  • Assuming environment variables are set because you set them once — check they're still there
The 30-second check: Network tab → click your Worker request → Headers. Confirm: (1) no API key in request headers or body, (2) CORS origin matches only your domain, (3) no sensitive data in the payload. Then: Cloudflare Workers → Logs — anything you wouldn't want public showing up?
▸ Try it now · 5 minRun the leak drill.
Open your project folder. Search for sk-ant- across all files (most editors: Ctrl+Shift+F / Cmd+Shift+F). If anything matches outside an env-var config, you have a leak. Then run git log -p | grep 'sk-ant-' — even if the key isn't in your current code, it might be in your Git history. If it is: rotate the key in Anthropic console FIRST, then deal with the history.
Worker — simple rate limit
const ip = request.headers.get('CF-Connecting-IP');
const key = `rate:${ip}`;
const count = parseInt(await env.KV.get(key) || '0');

if (count >= 100) {
  return new Response('Rate limit exceeded', { status: 429 });
}

await env.KV.put(key, String(count + 1), { expirationTtl: 3600 });
Checkpoint
Three things to confirm: (1) origin checking is active in your Worker, (2) the rate-limit counter is in place, (3) your .gitignore includes .env and *.key. All three done?
Your Worker now rejects unknown origins, caps abuse via rate limiting, and your secrets are gitignored. Random people can't hit your API endpoint and run up your bill, and your keys stay out of Git. That's professional security.
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
Your API key is accidentally exposed in a public GitHub commit. What do you do?
Delete the commit from GitHub
Git history is permanent — even deleted commits can be recovered. The key is already exposed. You need to revoke it, not hide it.
Revoke the key immediately, generate a new one, update the Worker environment variable, deploy
That's the protocol. Revoke → regenerate → update → deploy. Because your key lives in the Worker (not in client code), you only need to update one place. Total time: 2 minutes. This is why the proxy architecture matters — it makes key rotation trivial.
Make the GitHub repo private
Making it private hides future access, but anyone who saw the key before you made it private still has it. Revoke the key — that's the only safe action.
It's fine — the key is encrypted
API keys in Git repos are plain text. They're not encrypted. If it's in a commit, anyone with access can read it. Revoke and regenerate immediately.
Your .gitignore — The File That Saves Your Career

Create a .gitignore file in your project root. This tells Git which files to NEVER commit — even if you accidentally run git add .:

.gitignore
# API keys and secrets
.env
.env.local
*.key

# Node modules (reinstall with npm install)
node_modules/

# Build artifacts
dist/
.cache/

# OS files
.DS_Store
Thumbs.db

If you ever create a .env file for local testing, .gitignore prevents it from being pushed. This is the last line of defence between your secrets and the public internet.

Real incident: In 2024, a developer pushed an AWS key to a public repo. Automated bots found it within 4 minutes. $2,300 in charges before they noticed. The fix — origin checking + .gitignore + Worker secrets — takes 10 minutes. The incident takes months to resolve.

Security isn't glamorous. Nobody's going to look at your portfolio and say "nice origin checking." But the first time someone tries to scrape your API and gets a 403 — that's the moment you know your architecture is professional. The invisible work is what separates tools from products.

SHARP M4 The Confident Guess.When you ask AI 'is this Worker code secure?', it will confidently say yes or list generic security concerns that don't apply to your code.
When you ask AI 'is this Worker code secure?', it will confidently say yes or list generic security concerns that don't apply to your code. That's M4 — the Confident Guess. The honest version of the question: 'Name the single most likely way this specific Worker code could leak the API key. Don\'t list possibilities — pick the most probable one.'
Segment 18 — What you mastered
  • Where API keys belong (env vars on the server) and where they don't (anywhere else)
  • CORS scoped to your domain only
  • Why AI-generated code defaults to permissive settings — and how to tighten them
  • The rotation drill: when a key leaks, what to do in the next 5 minutes
Quick recall — Segment 18
You discover an API key has been pushed to a public GitHub repo. Within 5 minutes, what is the priority order?
Correct. Correct. Once a key hits public Git history it is compromised forever. Rotation is the only fix. Repo cleanup is hygiene, not defence.
Segment summary · Seg 18 · Security & API Key Management Your API key is a password. Treat it like one.
  • API keys in browser JavaScript = public keys. Anyone can steal them from DevTools.
  • Cloudflare Worker environment variables: the key lives on the server, never in git
  • CORS headers: your Worker only accepts requests from your own domain
  • .env files: local secrets. Always in .gitignore. Never committed. Ever.
Segment 19 of 23 · Week 4
By the end of this segment you will be able toWrite the tests AI does not write for itself — the five-test manual checklist that catches what slipped past unit tests.
Write the tests AI does not write for itself — the five-test manual checklist that catches what slipped past unit tests.

Testing Your AI Tools

⏱ ~30 min⬡ Desktop required
30-second preview — this is where you're heading. You try to break your own tool on purpose. Empty input, oversized input, malformed input, non-English characters, HTML injection, network failure, rate limit, model timeout, and a final happy-path check. Each one should produce a clean error message — not a crash, not silence. Testing is deliberate breaking, then fixing what broke.

Testing is the discipline of breaking your own tool on purpose so a user doesn't discover the bug for you. You already wrote try/catch in Segment 22 to handle errors when they happen. Testing is about making them happen, in controlled conditions, before you ship. This segment walks you through a checklist of tests every AI tool should pass before it goes live.

The checklist is pragmatic: empty input, oversized input, malformed input, non-English characters, HTML injection, network failure, rate limit response, model timeout, and one 'does the happy path still work?' check. You'll run each one manually, confirm your tool handles it gracefully, and fix anything that doesn't. It's ten minutes of work that saves you a lot of pain later.

Your Stack — Quality Assurance
Security
Testing
Verifying now
Performance

The stack shows you deep in Week 4 now — post-build, pre-launch. Testing sits between error handling (S22) and deployment (S26), and each of the remaining segments builds on the assumption that your tool has been tested in all the obvious ways.

Why manual testing, not automated? Automated testing is a whole separate discipline that deserves its own course (and SCALE's Segment 12 'Evaluation Frameworks' is where that course begins). For BUILD, the goal is getting comfortable with the concept of testing — deliberately breaking your tool — before you worry about the tooling.

AI outputs are unpredictable — the same input can produce different outputs. That makes testing harder than traditional software. This segment teaches you how to test AI tools effectively: checking the structure of responses, validating that errors are caught, and building a simple test harness.

What you CAN test with AI tools

You can't test that the AI gives the "right" answer — but you can test that: the response has the correct structure, error handling catches failures, the loading state appears and disappears, the UI updates correctly, the system prompt is sent, and the input validation works. Focus on the plumbing, not the AI's opinion.

Debug puzzle — the empty-input crash
FIND THE BUG
Your tool passes every test you wrote — until someone clicks Send without typing anything, and the result area shows "undefined" instead of a useful message. Click the line with the bug.
app.js · sendPrompt() function
1async function sendPrompt() {
2 const text = document.getElementById('input').value;
3 const output = document.getElementById('output');
4 
5 output.innerHTML = '<div class="loading">Thinking…</div>';
6 
7 const res = await fetch(apiUrl, {
8 method: 'POST',
9 body: JSON.stringify({ prompt: text.substring(0, 10000) })
10 });
11 const data = await res.json();
12 output.textContent = data.text;
13}
Checkpoint
Test each of your tools with: (1) empty input, (2) very long input (10,000 chars), (3) a disconnected network, (4) an invalid Worker URL. Does every case produce a helpful message?
Your tools are now production-grade. They handle the expected AND the unexpected. That's rare for a 4-week course project — and it's what makes your portfolio credible.
A Simple Test Harness

Create test.js to verify your tool handles edge cases:

▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
test.js — edge case testing
const WORKER = 'https://ai-proxy.YOUR-NAME.workers.dev';

const tests = [
  { name: 'Empty input', prompt: '', expect: 'error' },
  { name: 'Normal input', prompt: 'Analyse this text', expect: 'success' },
  { name: 'Very long input', prompt: 'x'.repeat(50000), expect: 'error or truncated' },
];

for (const t of tests) {
  try {
    const res = await fetch(WORKER, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ prompt: t.prompt, provider: 'claude' })
    });
    // PASS if the response matches what the test expected
    const passed = t.expect === 'success' ? res.ok
      : t.expect === 'error' ? !res.ok
      : true;
    console.log(`${t.name}: ${passed ? 'PASS' : 'FAIL'} (${res.status})`);
  } catch (e) {
    console.log(`${t.name}: ${t.expect === 'error' ? 'PASS' : 'FAIL'} (${e.message})`);
  }
}
AI responses are unpredictable — the same input can produce different outputs. What CAN you reliably test?
That the AI gives the correct answer
You can't test for a specific "correct answer" because AI outputs vary. Focus on structure and error handling instead.
That the response has the right structure, errors are caught, loading states work, and edge cases are handled
Exactly. Test the plumbing, not the opinion. Does the response come back? Does it have the expected fields? Does the UI update correctly? Does empty input get rejected? These are deterministic — they either work or they don't.
Nothing — AI tools can't be tested
The AI's output is unpredictable, but everything around it — the API call, the error handling, the UI, the input validation — is fully testable. Most bugs in AI tools are in the plumbing, not the AI.
That the AI uses the system prompt correctly
You can loosely check this by looking at the response format, but the system prompt's influence is a nudge, not a guarantee. Better to test the structural and mechanical parts of your tool.
Your Testing Checklist — Use This For Every Tool
• Empty input → shows validation message (not blank screen)
• Very long input (10,000+ chars) → truncated or warned
• Network offline → shows "check your connection" message
• Worker URL wrong → shows meaningful error, not JS stack trace
• API returns 429 (rate limit) → shows "try again in a moment"
• API returns 401 (key expired) → shows "service temporarily unavailable"
• Double-click the submit button → doesn't send two requests
• Response is unexpectedly short or empty → handled gracefully
• Loading state shows while waiting → user knows something's happening
• Loading state disappears on error → doesn't spin forever

Print this. Pin it next to your screen. Run through it every time you build or modify a tool. Professional developers don't test because they enjoy it — they test because the alternative is users finding the bugs for them.

Most developers skip testing. They build, they ship, they hope. You just ran your tools against the failure scenarios real users will encounter — the checklist above is yours to keep, and it grows with your projects. When users hit one of these — and they will — your tool handles it gracefully. That's not luck. That's engineering.

Segment 19 — What you mastered
  • Why AI rarely writes good tests for its own code
  • The 5-test checklist: empty input, oversized input, network failure, malformed response, concurrent click
  • How to ask AI for tests — and how to add the ones it missed
  • When to stop testing and ship
Quick recall — Segment 19
Which of these 5 manual tests catches the bug AI is most likely to ship?
Correct. Correct. The 5-test checklist exists because AI optimises for the success case. You test the failure cases AI didn't imagine.
Segment summary · Seg 19 · Testing Your AI Tools Tests catch what review misses. Write them before the bug report arrives.
  • Happy path, edge case, adversarial case — test all three, not just happy path
  • Empty input, maximum length, special characters, foreign language — standard edge cases
  • Console.log is not a test — write assertions that pass or fail automatically
  • Manual test checklist before every deploy: 10 prompts, 3 error states, mobile view
Segment 20 of 23 · Week 4
By the end of this segment you will be able toTake a sluggish AI tool from 8-second response times to streaming output the user sees building in real time — the perceived-speed win that makes products feel modern.
Take a sluggish AI tool from 8-second response times to streaming output the user sees building in real time — the perceived-speed win that makes products feel modern.

Performance & Optimisation

⏱ ~30 min⬡ Desktop required
30-second preview — this is where you're heading. Right now your tool waits for Claude to finish writing the entire response before showing anything — feels slow. With streaming, the words appear as they're generated — feels instant. Same total time. Completely different experience.

Performance is the second thing users notice after correctness. A tool that takes 8 seconds to respond feels broken, even if the answer is excellent. Streaming is the trick that lets you reduce the perceived latency from 'several seconds of nothing' to 'words appearing almost immediately' — without actually making the API any faster.

This segment teaches the three performance levers every AI tool has: streaming (tokens appear as they're generated, not all at once at the end), loading skeletons (showing a placeholder that looks like the final response while you wait), and parallel calls (firing multiple API requests at once with Promise.all). Streaming is the biggest perceived-speed win; the other two are cheap reinforcements.

Your Stack — Speed
Testing
Performance
Optimising now
Deploy

On the BUILD stack you're past testing now and into the polish layer — the segments that take a working tool and make it feel like something users enjoy using rather than tolerate. Streaming is the single highest-impact change in that polish set.

Why streaming matters more than optimisation. You could spend hours trying to make your Worker faster and save maybe 200ms. Or you could add streaming in 20 minutes and save 4 seconds of perceived wait time. Perception > raw speed, every time — and streaming is the easiest win in modern AI UX.

AI API calls are slow by web standards — 2 to 10 seconds. This segment teaches you to make the wait feel shorter and the tool feel faster: streaming responses, skeleton loadingAnimated placeholder shapes that shimmer while content is loading. Shows users something is happening. states, caching repeated queries, and choosing the right model for the right task.

Model selection
Use claude-haiku-4-5 for fast, simple tasks (classification, short summaries). Use claude-sonnet-4-6 for complex analysis. Haiku is 10x cheaper and 3x faster — use it where quality isn't the bottleneck.
Response caching
If the same input produces the same output, cache it. Store results in Cloudflare KV (free tier: 100K reads/day). Check cache before calling the API. Same result, zero latency, zero cost.
Streaming Responses

Instead of waiting for the full response, stream it word by word. The user sees the AI "thinking" in real time — same technique ChatGPT uses:

Why streaming feels instant even when it isn't. A 6-second non-streaming response feels broken. A 6-second streaming response feels like the AI is actively writing to you — even though the total time is identical. The difference is perceived latency: the first token arrives in ~400ms, the rest flow in as they're generated, and the user's brain interprets "something is happening" as "the tool is working". Streaming is one of the highest-use UX changes in modern AI products, and it's free.
Frontend — reading a stream
try {
  const res = await fetch(WORKER, { method: 'POST', body, headers });
  if (!res.ok) throw new Error(`Worker error ${res.status}`);

  const reader = res.body.getReader();
  const decoder = new TextDecoder();
  let output = '';

  while (true) {
    const { done, value } = await reader.read();
    if (done) break;
    output += decoder.decode(value);
    document.getElementById('result').textContent = output;
  }
} catch (err) {
  document.getElementById('result').textContent = `Something went wrong: ${err.message}`;
}
Your AI tool takes 6 seconds to respond. What's the most effective way to make it FEEL faster?
Use a faster AI model
A faster model helps, but even fast models take 1-3 seconds. The perceived speed matters more than actual speed.
Stream the response so text appears word by word while generating
This is what ChatGPT does. The total time is the same, but the user sees output in around 400ms instead of waiting 6 seconds for the complete response. Perceived speed is about time-to-first-token, not total generation time.
Add a loading spinner and hope they wait
A spinner tells users "something is happening" but doesn't reduce perceived wait time. Streaming actually shows progress — words appearing in real time feel much faster than a spinner followed by a wall of text.
Cache everything so it never needs to call the API
Caching helps for repeated queries, but most AI interactions are unique. Streaming is the right answer for first-time queries.
The 4 UI states every AI tool must handle
Idle
waiting for input
Loading
spinner + disabled
Success
render response
Error
clean message + retry
Idle
re-enabled, ready
Checkpoint
Have you tested your tool with both Haiku (fast, cheap) and Sonnet (slower, smarter)? Can you tell the quality difference?
Knowing which model to use for which task is a professional skill. Quick classifications → Haiku. Complex analysis → Sonnet. Cost-sensitive batch jobs → Haiku. Customer-facing quality matters → Sonnet. You're making informed architecture decisions now.
Skeleton Loading — The Professional Touch

Before the response starts streaming, show a "skeleton" — a pulsing placeholder that tells the user exactly where the content will appear:

▶ Code Editor (click to expand)
Skeleton loading + streaming feel
LIVE EDITOR
Show a skeleton loader while the response is loading. Switch to the response when it arrives.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
CSS — skeleton loading animation
.skeleton {
  background: linear-gradient(90deg,
    rgba(255,255,255,.04) 25%,
    rgba(255,255,255,.08) 50%,
    rgba(255,255,255,.04) 75%);
  background-size: 200% 100%;
  animation: shimmer 1.5s infinite;
  border-radius: 8px;
  height: 120px;
}
@keyframes shimmer {
  0% { background-position: 200% 0; }
  100% { background-position: -200% 0; }
}

Show the skeleton when the user clicks Send. Replace it with the streaming response when the first token arrives. The user sees: click → skeleton pulse → words appearing. It feels instant even when it takes 3 seconds. Every major AI app uses this pattern — ChatGPT, Claude, Gemini. Now your tool does too.

• Performance Checklist
• Streaming enabled for all AI responses
• Skeleton loading shown before first token
• Haiku used for fast/simple tasks, Sonnet for complex
• Repeated queries cached (Cloudflare KV or localStorage)
• Button disabled during loading (prevents double-submit)
Batch vs streaming — same model, different UX.
worker.js · /api/analyse endpointJavaScript
Two small changes. Completely different perceived speed. Adding stream: true to the request + returning the body directly (instead of awaiting .json()) streams tokens to the browser as they're generated. Total response time is identical. But the user sees the first word in ~400ms instead of waiting 3-5 seconds for the full reply — and perceived wait time is what actually matters. Pair this with a skeleton loader and your tool feels instant.
Skeleton loaders buy you the first 400ms. Before the first streamed token arrives, you still have about 400 milliseconds of nothing. A skeleton loader (a pulsing placeholder that looks roughly like the final response) fills that gap with something, which is all the brain needs to avoid the "is it broken?" alarm. Skeleton + streaming together feels instantaneous. Either one alone feels merely fast.

Streaming is the single biggest UX improvement you can make to any AI tool. The total response time doesn't change — but the perceived wait drops from "is it broken?" to "oh, it's already writing." Add it to every tool you build from now on. Your users will thank you by not leaving.

Segment 20 — What you mastered
  • What 'streaming' actually means at the API level
  • Server-Sent Events from the Worker to the browser
  • Why perceived speed beats actual speed
  • Where to add a loading indicator vs where streaming makes it unnecessary
Quick recall — Segment 20
Your AI tool takes 8 seconds to respond. You can either (a) cut it to 4 seconds or (b) stream the response so output appears in 0.5 seconds. Which feels faster to users?
Correct. Correct. Perceived speed dominates actual speed. Streaming is the highest-leverage UX change you can make to an AI product.
Segment summary · Seg 20 · Performance & Optimisation Fast is a feature. Every second of latency costs you users.
  • Streaming: show the first token in ~200ms instead of waiting 3-5s for the full reply
  • Caching: store results for identical prompts — API calls cost money and take time
  • Token budget: shorter prompts, compressed system prompts, max_tokens limits
  • Lighthouse score: run it before you ship. Performance, accessibility, SEO — three numbers that matter
Segment 21 of 23 · Week 4
By the end of this segment you will be able toHave a real CI/CD pipeline so that pushing to main triggers a deploy automatically — and a rollback path that takes one click when something breaks.
Have a real CI/CD pipeline so that pushing to main triggers a deploy automatically — and a rollback path that takes one click when something breaks.

Your Deployment Pipeline

⏱ ~30 min⬡ Desktop required
30-second preview — this is where you're heading. Your full deployment pipeline, documented and repeatable. One push to GitHub triggers the build. Netlify deploys the frontend. Wrangler deploys the Worker. Env vars are set server-side. Origin checks are on. Everything is versioned. You can ship a change in 30 seconds, safely.

Deployment is the step where your code leaves your laptop and becomes something real users touch. You've been deploying since Segment 7, but casually — a single site, single Worker, no checklist. This segment formalises the pipeline: what steps run on every push, what you verify before pushing, what you check after deploying, and what to do when something goes wrong.

The pipeline you build here is the minimum-viable production pipeline: git push -> Netlify builds the frontend -> Wrangler deploys the Worker -> env vars are pulled from Cloudflare (not the repo) -> the site goes live. Every real AI product in 2026 runs on a version of this pipeline. SCALE extends it with staging environments, canary deployments, and rollback procedures — but the foundation is this segment.

Your Stack — Ship It
Performance
Deploy
Formalising now
Portfolio

You're deep into Week 4 here, with everything built and tested, now being wired into a professional deployment flow. The stack diagram at this point isn't showing you tools left to install — it's showing you the tools working together as a single pipeline.

Why formalise deployment at all? Because 'I'll just remember what I did last time' is the #1 cause of deployment failures. A written, repeatable pipeline is the difference between 'I can ship this in 30 seconds' and 'I have to reconstruct what I did last Tuesday'. This is also where SHARP's M6 The Redirect applies — don't let AI talk you into 'a simpler way' that skips steps in the pipeline.

You've been deploying throughout the course — git push, Netlify deploys, Worker updates. This segment formalises it into a professional pipeline: staging vs production, environment variables per environment, and a deployment checklist you'll use for every future project.

• Your Deployment Checklist — Keep This
• All API keys in environment variables (never in code)
• Origin checking enabled on Worker
• Error handling covers all fetch calls
• Loading states on all async operations
• Tested with: empty input, long input, network failure
• Git commit with meaningful message
• Push to main → Netlify auto-deploys
• Worker deployed via wrangler deploy
• Live site tested on mobile and desktop
Your Complete Deploy Commands
The three commands you'll use every time
# 1. Website → Netlify (automatic on push)
git add . && git commit -m "your message" && git push

# 2. Worker → Cloudflare
npx wrangler deploy

# 3. Extension → Chrome (manual reload)
# Go to chrome://extensions → click reload on your extension
What each command does:
  1. git add . — stages all changed files (tells Git "include these")
  2. git commit -m "message" — saves a snapshot with a description of what changed
  3. git push — uploads to GitHub. Netlify detects the push and auto-deploys your website
  4. npx wrangler deploy — uploads your Worker code to Cloudflare (separate from the website)
  5. chrome://extensions → reload — Chrome doesn't auto-update local extensions, so you click reload manually
Meaningful commit messages matter. Not "update" or "fix stuff." Try: "add retry logic to AI calls" or "fix CORS headers in Worker." Future you will thank present you when you're searching git log for when something broke.
The deploy pipeline · edit → live in 60 seconds
Edit
in VS Code
git push
to GitHub
Netlify
builds frontend
wrangler deploy
pushes Worker
Cloudflare
env vars, edge
Live URL
anyone can load
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
What's the deployment flow for updating your AI tool?
Edit the live files on Netlify's server
You never edit live files directly. Changes go through your local environment, Git, and automated deployment. That's the pipeline.
Edit locally → test → git commit → git push → Netlify auto-deploys from GitHub
That's the pipeline. Edit, test, commit, push. Netlify watches your GitHub repo and deploys automatically. If something breaks, git revert and push again. The pipeline is your safety net.
Upload files via FTP
FTP is a 2005 workflow. Modern deployment uses Git-triggered CI/CD — which is exactly what you've been using with Netlify. Faster, safer, auditable.
Email the files to Netlify support
I appreciate the confidence in Netlify's support team, but no. Your deployment pipeline is fully automated — git push is all it takes.
Checkpoint
Make a small change to your site (update a heading). Push it. Does the live site update within 60 seconds?
Your deployment pipeline works end to end. From your editor to the live internet in under a minute. Professional developers use this exact flow — you're not doing a tutorial version, you're doing the real thing.

That checklist isn't just for this course. Screenshot it. Save it. Every time you build something new — personal project, freelance work, startup MVP — run through it before you ship. It takes 5 minutes and it catches 90% of the mistakes that embarrass people in production.

— zsh — you@build: ~/Desktop/ai-project
interactive
you@build ~/Desktop/ai-project $
Segment 21 — What you mastered
  • What CI/CD means in plain English
  • The git push → GitHub → Netlify → live flow
  • Branch protection: why main should never accept direct pushes for shared projects
  • The one-click rollback that saves the day
Quick recall — Segment 21
Your latest deploy broke the live site. Your priority order is:
Correct. Correct. Restore service in one click, debug in calm. This is why you set up the rollback path BEFORE you need it.
Segment summary · Seg 21 · Your Deployment Pipeline Push to GitHub → live in 30 seconds. That's the pipeline.
  • GitHub → Netlify auto-deploy: every push to main is a production deploy
  • Environment variables in Netlify: secrets in the dashboard, not in code
  • Preview deployments: every branch gets a URL — test before merging to main
  • Rollback: Netlify keeps every deploy. One click to go back.
Segment 22 of 23 · Week 4
By the end of this segment you will be able toHave a portfolio page that shows the AI tools you built, the verification habits behind them, and links a prospective client or employer can click on.
Have a portfolio page that shows the AI tools you built, the verification habits behind them, and links a prospective client or employer can click on.

Portfolio & Documentation — Show Your Work

⏱ ~35 min⬡ Desktop required
30-second preview — this is where you're heading. A README that explains what your tool does, screenshots that show it working, a live demo URL anyone can click, and a one-paragraph 'what I learned' section. This is the segment where your work goes from 'something I made' to 'something I can show people'.

The thing you built is real. The next step is making it visible. This segment teaches you how to turn a working tool into a portfolio piece — a README on the GitHub repo, screenshots or a demo video, a live URL you can share, and a short 'what I learned' reflection. It takes about 30 minutes and it's the difference between 'I finished a course' and 'I have work I can point to'.

A good README answers four questions: what does it do (one sentence), how do I use it (two or three steps), what tech is it built with (a short list), and where can I see it running (a link). No novel. No philosophy. Just enough that someone landing on the repo knows in 10 seconds whether it's relevant to them.

Your Stack — Show It
Deployed
Portfolio
Documenting now
Final Project

You're at the end of BUILD's Week 4 now. The stack diagram in this segment shows the complete pipeline from editor to live site to documented portfolio — everything you installed in Week 1 is being used, and the final segment is about presenting the thing, not building more of it.

Why documentation is a real skill. Every engineer you admire writes docs. Every engineer you avoid doesn't. Documentation is the difference between work that gets reused and work that gets re-done. It's not a chore — it's the thing that makes your work visible to the people who could hire you, collaborate with you, or learn from you.

You've built real things. Now document them so other people can see what you built, understand how it works, and be impressed by it. This segment creates your portfolio README and project documentation — the things that turn "I took a course" into "look at what I built."

Your Portfolio README

Create a README.md in your GitHub repo that showcases everything you built:

README.md structure
# AI Tools Portfolio

Built during the AI Clarity Programme — BUILD.

## What I Built
- **AI Text Analyser** — Paste text, get structured analysis from Claude
- **Multi-Model Comparison** — Same question to Claude + GPT side by side
- **AI Pipeline** — Chained analysis: summarise → critique → synthesise
- **Sector Tool** — [Your industry]-specific analysis using custom system prompts
- **Automated Workflow** — Scheduled AI analysis via Cloudflare Cron Triggers

## Architecture
Website (Netlify) → Cloudflare Worker (API proxy) → AI APIs (Claude, GPT)
All API keys server-side. CORS + origin checking. Retry logic. Error handling.

## Tech Stack
HTML, CSS, JavaScript, Cloudflare Workers, Anthropic API, OpenAI API, Netlify

## Live Demo
[your-site.netlify.app](https://your-site.netlify.app)
The README is your portfolio. When someone looks at your GitHub, the README is the first thing they see. A clear, well-structured README with live demo links, architecture descriptions, and a tech stack list communicates more than the code itself. Write it like you're explaining to someone smart who has 60 seconds to decide if they're impressed.
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
A potential employer looks at your GitHub. What do they see first?
Your code files
They might look at code eventually, but the first thing displayed on any GitHub repo page is the README. If there's no README, or it's empty, most people click away.
Your README.md — the project overview, architecture, tech stack, and live demo link
Exactly. The README is your portfolio. A clear, well-structured README with a live demo link, an architecture description, and a tech stack list communicates more in 30 seconds than code files ever will. Write it like you're explaining to someone smart who has 60 seconds to decide if they're impressed.
Your commit history
Commit history matters for experienced developers, but most people who look at your GitHub start — and often end — at the README.
Your profile photo
Your profile helps, but the repo page shows the README front and centre. That's your first impression for each project.
• Quick Win

Write your README now. Not later. Not "when it's finished." A README that says "Work in progress — currently building X, Y, Z" is infinitely better than an empty repo. Ship the documentation alongside the code. Make it a habit.

■ Before & After — Your GitHub
Without README: Someone visits your repo. They see a list of files — index.html, styles.css, worker.js. No context. No explanation. They leave in 10 seconds.
With README: They see: what you built, why it matters, how it works, a live demo link, and the architecture diagram. They're impressed in 30 seconds. They click the demo. They stay.

I've seen brilliant developers with empty GitHub profiles and mediocre developers with stunning READMEs. The ones with the READMEs get the opportunities. Unfair? Maybe. But you control it. Write the README. It takes 20 minutes and it works for you 24/7.

Segment 22 — What you mastered
  • What goes in a builder portfolio (working tools, not just screenshots)
  • How to write the one-line description for each tool
  • Why showing the verification process matters as much as showing the output
  • The portfolio template that ships with the course
Quick recall — Segment 22
A prospective client asks why your AI tool is 'safer' than what they could get from another freelancer. What do you show them?
Correct. Correct. The verification layer IS the differentiator. Anyone can wire up an API; few build with the human overlay baked in.
Segment summary · Seg 22 · Portfolio & Documentation A tool nobody can find is a tool that doesn't exist.
  • README.md: what it does, how to run it, what you built — three sections, always
  • Screenshots in the README: show the tool working, not just describe it
  • GitHub profile: pinned repos with descriptions are your professional portfolio
  • The BUILD project is proof. SCALE turns it into a production system.
Segment 23 of 23 · Week 4
By the end of this segment you will be able toShip your capstone project — a real AI tool, deployed, with the verification habits intact — and walk out of BUILD with a live URL you control.
Ship your capstone project — a real AI tool, deployed, with the verification habits intact — and walk out of BUILD with a live URL you control.

Final Project — Your AI Product

⏱ ~60 min⬡ Desktop required• Course completion
The brief. Take everything you've built this week and combine it into ONE tool you'd actually want to show a real user. Not a demo. Not a tutorial copy. A tool with your idea, your use case, your domain, and the stack you've been building all month underneath. By the end of this segment, that tool is deployed, documented, and proven to work.

The final project has one rule and five requirements. The rule is: it must be yours. Not a rebuild of an existing tool. Not a copy of something you've seen. Something you would actually use, or build for a client, or show in a portfolio. If you can't explain what problem it solves in one sentence, the scope is wrong — make it smaller until you can.

The five requirements, lifted directly from the production rules you've learned:

  • A working frontend — HTML / CSS / JavaScript, deployed on Netlify, accessible at a public URL.
  • A Cloudflare Worker proxy — holds the API key server-side, includes an origin check, returns structured JSON.
  • An AI call that means something — a real prompt with a real system prompt, not a "Hello, world" call. Bonus points if it uses two models or a chain.
  • Production error handling — validate the input, show a loading state, wrap the fetch in try/catch/finally, handle the failure case gracefully.
  • A README — the template later in this segment works as a starting point. One sentence about what it does, the stack, the live URL, a screenshot, and a short note on what you learned.
Verification checklist — tick each one before you call the project done:
□ The live URL loads on my phone, on a friend's phone, and in a browser I've never used. □ The AI call returns a response within 10 seconds. □ Entering nothing into the input doesn't crash the tool. □ Disconnecting the network and clicking the button shows a clean error message. □ The README renders correctly on github.com (not just in your editor). □ The API key does NOT appear anywhere in the browser's view-source or network tab. □ I can explain to someone in two sentences what the tool does and why.
A last word — before you start.Four weeks ago you didn't know what a terminal was.
Four weeks ago you didn't know what a terminal was. Today you're about to deploy an AI tool to the internet. That gap — between the person you were and the person about to ship this — is the thing the course was really for. Take the next hour, build the smallest version of an idea you actually care about, ship it, and write the README. The smallest real thing is always better than the biggest planned thing. Ship small, and be proud of it.
What good looks likeThe capstone that lands the job

One of the most-shared BUILD capstones in 2026 was a one-page legal-document summariser. The tool itself was modest: paste contract text, click Analyse, get a plain-English summary plus three flagged clauses. What got the builder hired was the README — it documented every verification step (key in env var, input length cap, output disclaimer for the user, manual review of every flagged clause). The reviewer commented that 'the verification thinking told me more about the candidate than the code did.'

The lesson: the verification layer is the differentiator, not the AI itself. Ship the habits visibly.

Your Complete Stack — All Lit
HTML/CSS/JS
Workers
AI APIs
Extension
Ship
Final project

This is it. The final segment. You're going to take everything you've built — the website, the AI tools, the extension, the automation — and combine them into one cohesive product. Something you can point at and say: "I built that." Something that works. Something that's yours.

Final Project Requirements
  1. A live deployed website with at least one AI-powered tool
  2. A system prompt tailored to a specific use case using the 5-element framework
  3. At least one tool that uses multi-model comparison OR orchestration
  4. Proper error handling — test all 4 edge cases from S24
  5. A polished capstone tool with system prompt, validation, error handling, and sector customisation
  6. A GitHub README documenting what you built, how it works, and how to use it
  7. Everything deployed on free infrastructure — Netlify + Cloudflare Workers
Portfolio Booster · README Template

Your code is only half the project. The other half is the README — the file that loads first when anyone opens your repo on GitHub. A good README turns "some code on a page" into "a real product I built." Below is a ready-to-use template. Copy it, save it as README.md in the root of your project repo, fill in the bracketed bits, push it, and your GitHub page will look like a professional dev's portfolio.

README.md — copy this into your project repo
# [Your Project Name]

> One sentence describing exactly what this tool does. Be concrete. Not "an AI-powered solution" — say "takes a contract clause and flags risky language."

→ **Live demo:** https://your-project.netlify.app
▪ **Built with:** HTML · CSS · JavaScript · Cloudflare Workers · Claude API

---

## What it does

[2–3 sentences. What goes in, what comes out, who it's for. Concrete examples are better than adjectives.]

## Why I built it

[1–2 sentences. The real reason. The problem you saw or the use case you cared about. Keep this human — it's the part that makes a portfolio piece feel like yours and not just code.]

## How it works

User input  →  Cloudflare Worker (proxies to Claude)  →  AI response  →  rendered on page

1. User pastes [input] into the textarea on the website
2. Frontend sends a POST request to the Cloudflare Worker
3. Worker injects the system prompt and forwards the request to the Claude API
4. Claude responds; the Worker returns the result to the frontend
5. Frontend renders the response on the page

## The system prompt

This tool uses a sector-specific system prompt built with the 5-element framework taught in Segment 15 of the BUILD course:

- **Role:** [e.g. "You are a contract risk analyst with 15 years' experience..."]
- **Expertise:** [the domain knowledge the model should bring]
- **Constraints:** [what the model must NOT do]
- **Format:** [JSON / bullet list / structured text]
- **Examples:** [1–2 few-shot examples, if used]

## Tech stack

| Layer | Tool |
|---|---|
| Frontend | HTML / CSS / vanilla JavaScript |
| Hosting | Netlify (auto-deploy from this repo) |
| API proxy | Cloudflare Workers |
| AI model | Claude (Anthropic API) |
| API key storage | Cloudflare Worker environment variables (never exposed to the browser) |

## Run your own version

1. Clone this repo: `git clone [your-repo-url]`
2. Get an Anthropic API key from [console.anthropic.com](https://console.anthropic.com)
3. Deploy the Cloudflare Worker in `/worker/index.js` and add your API key as a secret with `wrangler secret put ANTHROPIC_API_KEY`
4. Update the Worker URL in `index.html` to point to your deployed Worker
5. Push to GitHub and connect the repo to Netlify — it auto-deploys on every push

## What I learned building this

- [Specific lesson #1 — not "I learned a lot," something concrete]
- [Specific lesson #2]
- [Specific lesson #3]

## Credits

Built as the final project for the AI Clarity BUILD course — a 28-segment programme that takes you from zero to a deployed AI tool.

---

© [Your Name] 2026 · Built on free infrastructure · Code released for portfolio purposes
Why this README pattern works: recruiters and clients spend about 30 seconds on a GitHub repo before deciding if it's worth a longer look. The first three things they see are: (1) the headline + one-liner, (2) the live demo link, (3) the screenshot or "How it works" diagram. This template puts all three at the very top. Everything below is for the people who already decided they're interested.
▲ VERIFICATION LAYER · Before You Ship
Common ways AI gets THIS wrong:
  • Final project code has model strings that are months old
  • README links to a Netlify URL that's expired or renamed
  • The 5-test checklist was run at segment 24 and never re-run after the final changes
Common ways students miss it:
  • Submitting before opening the live URL on a fresh phone browser
  • Not verifying the Worker is still deployed — Cloudflare free tier Workers can go idle
The 30-second check: Full final checklist: (1) Live URL loads on 3 devices, (2) model string matches current Anthropic docs, (3) API key is in env vars (not in code), (4) run all 5 tests from Seg 24, (5) README renders on github.com with working live link.
Final Checkpoint
Open your live URL on your phone. Does your AI tool load, accept input, and return an AI response? Open your GitHub repo. Does the README explain what you built?
That's your final project. Live. Working. Documented. On your phone. On GitHub. Ready to show anyone who asks "what can you build?" The answer isn't "I took a course." The answer is "let me show you."
▶ Code Editor (click to expand)
Final project — a working mini tool
LIVE EDITOR
Everything you've learned in one place: HTML structure, CSS style, JS fetch, loading state, error handling. Hit Run to see it work end-to-end.
index.htmlHTML · CSS · JS
Live preview▶ RUN to render
▶ Step-by-Step Walkthrough (click to expand)
1
Step 1
Final deploy — everything at once
# Deploy website
git add . && git commit -m "final project complete" && git push

# Deploy Worker
npx wrangler deploy

# Verify
# 1. Open your Netlify URL — does it load?
# 2. Test the AI tool — does it respond?
# 3. Check GitHub — is the README visible?
Final verification checklist:
  1. Open your Netlify URL on your phone (not just your laptop) — if it loads, deployment worked
  2. Type a question in your AI tool and click Analyse — if Claude responds, the Worker is live
  3. Go to github.com → your repo — your README should be visible at the bottom of the page
  4. If all 4 work — your project is complete and portfolio-ready
Final question. You've built an AI-powered tool, deployed it live, and shipped it with production-ready error handling and sector-specific prompts. A friend asks: "How did you build all that?" What's the honest answer?
I used no-code tools and AI to generate the code
You did more than that. You understand every line. You can debug, modify, and extend what you built. That's the difference between generating code and building software.
I followed a tutorial step by step
You followed a course, but the final project is YOURS — your industry, your use case, your system prompt, your architecture decisions. That's beyond following steps.
I learned the architecture — HTML/CSS/JS for the interface, Cloudflare Workers for the API proxy, AI APIs for intelligence — and built tools that combine all three
That's the answer. You understand the architecture. You know why the Worker exists (security), why the system prompt matters (specialisation), why you test edge cases (reliability), and how to deploy (pipeline). You're not someone who took a course. You're someone who can build AI systems.
I took a course
The course gave you the framework. What you built is yours — the industry-specific tool, the architecture decisions, the deployment pipeline. The course provided the knowledge. The portfolio proves you used it.
Submit Your Final Project
Share your live URL and GitHub repo link. Your submission goes into the BUILD graduates archive as proof of a deployed project you own and understand.
■ Everything You Built — 28 Segments, 4 Weeks
Live Website
Deployed on Netlify
AI Text Analyser
Claude + GPT
Multi-Model Compare
Promise.all()
AI Pipeline
Orchestration
System Prompts
Sector-tuned
Verification
5-test checklist
Sector Tool
Your industry
Automation
Cron triggers

All on free infrastructure. All from code you wrote and understand. All deployed and live.

I want to say something before you hit submit. Whatever you've built — however simple or complex it is — you built it from nothing. You didn't copy someone's repo. You didn't drag and drop on a no-code platform. You wrote the HTML. You styled the CSS. You connected the APIs. You secured the keys. You tested the failures. And you deployed it live. That's yours. Nobody can take that away from you. And nobody can pretend they taught you how to do it — because you taught yourself, with guidance. That's different. And it matters.

Final Recall Gate · Week 4
The last check before you call it done
Eight questions across all four weeks. If you can answer these from memory, you own the material.
Question 1 of 8
Final Assessment · Cross-Course Gate
Prove you own the whole methodology
Nine questions — three from CLEAR, three from SHARP, three from BUILD. Passing confirms your graduate-level understanding.
Question 1 of 9
Your BUILD progress
0 / 206
Slides
viewed
0 / 42
Widgets
completed
0 / 4
Week gates
passed
Updates live from your local progress. Reset any time by clearing browser storage.
Submit your final project
Your work goes onto the BUILD graduates archive as a finished, deployed, verifiable piece of work you can point anyone to.
Saved locally first — you can close the tab and come back. When connected to a backend, posts automatically.
Segment 23 — What you mastered
  • A working AI tool deployed at a public URL
  • All five verification habits applied (key safety, input guards, error handling, tests, rotation drill)
  • A README that explains what it does and how to use it
  • Confidence that you can build the next one without us
Quick recall — Segment 23
What separates a BUILD capstone from a typical 'I built an AI app' demo?
Correct. Correct. The capstone proves you can ship AND verify. That's the entire pedagogy in one deliverable.
• • •
Course Complete
Congratulations — BUILD Graduate
Four weeks ago you didn't know what a terminal was. Today you have a deployed AI-powered product with sector-tuned system prompts, production-ready error handling, and a portfolio on GitHub. You understand the architecture. You can debug the problems. You can explain every line.

That's not something a course gave you. That's something you built.
What you now own
✓ Live deployed website
✓ AI-powered tool (Cloudflare Worker + Claude)
✓ Chrome browser extension
✓ Automated scheduled workflow
✓ GitHub portfolio with README
✓ Multi-model comparison tool
✓ End-to-end deployment pipeline
Sector applications
Your BUILD skills apply directly to sector-specific AI tools. Choose your sector to see how the same architecture adapts:
Healthcare Finance Legal Education HR Marketing Governance

Final push: git add . && git commit -m "final project complete" && git push

What's next

Your Tool Is Not a System Yet

⏱ ~5 min read• Where this leads next

You just shipped your first AI tool. It works, it's deployed, it's yours. Take the win.

But here's the honest version: what you built is a tool. It's a single request, a single model call, a single response. One user clicking a button and waiting for an answer. That's a real, live, working thing — and it's enough for a lot of use cases. For some of yours, it'll be enough forever.

For the rest of them, there's a threshold you'll hit. It looks like this:

Each one of those is a system problem, not a tool problem. And the moment you try to add even one of them to what you built in BUILD, you'll feel the architecture start to strain. Features will fight each other. Bugs will move around instead of getting fixed. The single Worker you're so proud of will start to feel cramped.

That's not a flaw in what you built. That's the line between a tool and a production agent system. The thing that comes after BUILD is called SCALE, and its entire job is to teach you how to cross that line deliberately — with the vocabulary, the patterns, and the production discipline that separates engineers who ship demos from engineers who run the thing on a Monday morning when real users are hammering it.

What SCALE covers · 33 segments, 5 weeks
Week 1 — Architecture: agent systems vs scripts, the 4 core design patterns, pipelines, state & memory, prompt engineering at scale, token economics.
Week 2 — Production: your first production-ready agent, multi-step reasoning, tool integration via MCP, error handling & recovery, logging & observability, evaluation frameworks.
Week 3 — Data & Multi-Agent: retrieval-augmented generation, building knowledge bases, memory systems in practice, context engineering, multi-agent systems, workflow orchestration.
Week 4 — Performance: latency optimisation, cost optimisation at scale, model routing, caching & reuse, load handling & queues.
Week 5 — Production Ship: API layer, frontend integration, deployment strategies, security & guardrails, and a capstone — a full agent system you build from scratch and deploy.

There are five "Bridge" segments at the start of SCALE that use your own BUILD project as the starting point. You don't walk into a new course blind — you walk in holding the thing you already shipped, and SCALE refactors it with you, one decision at a time, until it becomes the first real agent system you've ever built.

If the seven items in that list above are ones you can already feel in what you built this week, SCALE is where you go next. If they're not, that's fine too — what you have is already a real tool that does a real job, and nobody's grading you for graduating to the next tier. Take what you built, use it, watch what breaks, and come back when the breakage tells you you need what comes next.

Either way: well done for finishing BUILD. Very few people do.

BUILD Complete •
▸ Try it now · 5 minBuild your first HTML page from AI output.
Ask Claude: 'Generate a simple HTML page with a header, a main section with one paragraph, and a footer. Use semantic tags only.' Save the output as index.html. Open it with Live Server. Now ask Claude to walk you through every tag — read the answer line by line. This is the read-before-you-ship habit.
0:00
What SCALE teaches 33 segments · 5 weeks · Production Agent Systems
Refactor your BUILD final project into a production agent architecture
Pipelines, memory systems, RAG, and multi-agent collaboration
Error handling, evaluation frameworks, and observability at scale
Load handling, cost optimisation, model routing, and caching
API layer, frontend integration, deployment, security, and guardrails
Capstone: ship a production-grade multi-agent system
Segment complete Next segment unlocked
Copied to clipboard!
What's Next · Your Paths

Four Paths Forward — Pick What Solves Your Next Problem

• You now know enough to choose

You've shipped one complete BUILD tool. Below are four paths forward — one is free, three are add-ons that extend what you've built, one is a deeper course. Each shows what you'll ship, who it's for, and roughly how long it takes. There's no right answer. Only the one that solves your next actual problem.

① Keep sharpening · free
⌖ SHARP · Verification review
~2 hrs · self-paced
You'll ship: a written SHARP audit of your BUILD tool — the 7 manipulation patterns applied to your own code, system prompts, and AI flows. No new tool, just a sharper one.
Pick this if: your tool works but you're not sure why some AI responses feel off. SHARP gives you the vocabulary to name what's wrong.
② Extend your tool · optional add-ons
🖥 Chrome Extension
~6–8 hrs
Ship: your tool as a browser extension that reads whatever page you're on.
Pick if: you want the tool one click away on every page — email, docs, research.
📱 Progressive Web App
~4–6 hrs
Ship: your tool installable on any phone or desktop. No app store, no review.
Pick if: you want a phone-first experience, or need offline mode.
⚙ Automation
~8–10 hrs
Ship: your tool on a schedule, via webhook, or chained into Make/Zapier.
Pick if: the bottleneck is remembering to run it, not running it itself.
③ Go deeper · full course
▲ SCALE · From tool to system
33 segments · ~5 weeks
You'll ship: a production-grade agent system — multi-step reasoning, RAG, orchestration, observability. Your BUILD project is the starting point; SCALE refactors it with you.
Pick this if: your tool has real users, real data, or real money flowing through it — and the verification habits from BUILD aren't enough on their own anymore.

The honest recommendation: most people should do SHARP first (free, short, sharpens what you've already built), then pick one add-on that matches a real next problem, then decide about SCALE. You don't need to pick a path today. You just need to know they exist.

Glossary

Every key term from BUILD

API
A way for your code to talk to another service.
API key
Secret password for accessing a service.
CORS
Security rule for server access.
CSS
How a webpage looks.
Cloudflare Worker
Code between your website and AI, keeps key hidden.
Commit
Save point with a description.
Cron trigger
Timer for scheduled code.
DOM
Browser's map of your page.
Deploy
Put code on the internet.
Git
Save point tool for your code.
GitHub
Cloud storage for code.
HTML
What is on a webpage.
JSON
Structured data format.
JavaScript
Makes pages interactive.
Manifest
File describing your app.
Netlify
Free hosting that auto-deploys.
Node.js
Runs JavaScript outside browsers.
PWA
Website installable like an app.
Push
Upload commits to GitHub.
Repository
Project folder on GitHub.
Service worker
Background caching script.
Streaming
Word-by-word AI responses.
System prompt
Hidden AI instructions.
MCP
Model Context Protocol — a standard that lets AI tools connect to external services (GitHub, databases, file systems) so AI can act on real data.
Vibe coding
Building software by accepting AI-generated code without reading or verifying it. Fine for throwaway prototypes. Dangerous for production systems with real users.
Verification layer
The human step between AI output and shipping — reading the code, running checks, testing edge cases. The skill this course is built around.
Human overlay
The judgement, verification, and refusal humans provide in AI-assisted workflows. AI types. You direct and verify. That's the overlay.
Hallucination
When AI produces confident, fluent output that is factually wrong — invented API endpoints, fabricated citations, wrong syntax. Always verify specifics before shipping.
Prompt engineering
The craft of writing AI inputs that produce the output you want. Five elements: Role (who the AI is), Format (how output is structured), Constraints (what AI must not do), Tone (voice and register), Context (relevant background). Taught in Segment 15.
Terminal
Text box for typing commands.
async/await
Wait for slow operations.
fetch
Sends requests to servers.
npm
App store for code tools.
Glossary

Every key term from BUILD

API
A way for your code to talk to another service.
API key
A secret password that lets your code access a service.
CORS
Security rule controlling which sites talk to your server.
CSS
Language defining how a webpage looks.
Cloudflare Worker
Code that runs between your website and the AI, keeping your key hidden.
Commit
A save point with a description of what changed.
Cron trigger
Timer that runs your code on a schedule.
DOM
The browser's map of your webpage.
Deploy
Put your code on the internet so anyone can use it.
Git
A tool that saves snapshots of your code. Like save points.
GitHub
A website that stores your code in the cloud.
HTML
Language defining what is on a webpage.
JSON
Text format for structured data used by APIs.
JavaScript
Language making a webpage interactive.
Manifest
File describing what your app or extension does.
Netlify
A free hosting service that auto-deploys from GitHub.
Node.js
Software that runs JavaScript outside a browser.
PWA
Progressive Web App — website installable like a phone app.
Push
Upload your local commits to GitHub.
Repository
A project folder on GitHub with all your code.
Service worker
Background script caching files for offline use.
Streaming
Showing AI responses word by word as they arrive.
System prompt
Hidden instructions controlling AI behaviour.
Terminal
A text box where you type commands instead of clicking buttons.
async/await
Tells JavaScript to wait for slow operations.
fetch
JavaScript function that sends requests to servers.
npm
Node Package Manager — an app store for code tools.
CI/CD
Continuous Integration / Continuous Deployment — auto deploys when you push code.