We'll email you a link to pick up exactly where you left off.
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.
Enter your email to unlock BUILD.
Your foundation. Editor, terminal, version control, your first live website.
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.
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.
These aren't edge cases. They happen to developers with years of experience. They'll happen to you. Knowing they exist is the protection.
This rule doesn't slow you down. It's the difference between shipping once and shipping well every time after that.
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.
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?"Win+Shift+S on Windows, Cmd+Shift+4 on Mac.sudo rm, curl … | bash, or you don't understand what it does, ask "what does this actually do?" before pressing enter.Ctrl+D (Windows) or Cmd+D (Mac) right now so you can jump back here from any segment when something breaks.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.
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.




Before you touch a keyboard, see where you're going. By Week 4, you will have built, deployed, and own all three of these:
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.
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.
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.
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.
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.






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.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.npm install -g @anthropic-ai/claude-code
claude --version should return a version number.CLAUDE.md. Paste the template from the next slide. This file tells Claude Code the rules it operates under for your project.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:
# 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
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.
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.
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.
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.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.
.exe installer. Accept all defaults. Check "Add to PATH" when prompted — this is important..dmg file. Drag VS Code into your Applications folder. Open it once from Applications.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.
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.
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.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.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:
afterDelayonDark+ or any dark theme you likeFive settings, no more. I promise I won't make you configure anything else for at least two more segments.
VS Code has 5 main areas. You don't need to memorise them — just know they exist so nothing surprises you.
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.
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.
rm -rf, sudo, or curl ... | bash — stop and ask "what does this do?" in a fresh chat before running.
" 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.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.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.
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.
Remember the shortcut we previewed at the end of Segment 2? Now you'll use it for real.
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.
Type this exact nonsense into your terminal and press Enter:
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.
rm (remove files permanently) — and we'll teach you exactly when and how to use it safely.The terminal has hundreds of commands. You need 8. Here they are, with a "try it now" exercise for each:
pwd
cd alone to see it.

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
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 .. 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.
cd Desktop
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 my-first-project
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 index.html
ni index.html (New-Item) or echo $null > index.htmlThis 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).
. means "this folder." You'll use this every single time you start working on a project.# Move into your new folder, then open it in VS Code
cd my-first-project
code .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
cls also works.rm on files you created yourself. Never use rm -rf / (this would attempt to delete everything). Always double-check the filename before pressing Enter.# Create a throwaway file, then remove it
touch delete-me.txt
rm delete-me.txtRemove-Item delete-me.txtStart 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.
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.
# 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 .
cd Desktop says "no such directory" — your home folder may be different. Try ls first to see what folders exist, then cd into the right one.touch doesn't work on Windows — use ni index.html instead (PowerShell).code . doesn't work — see the Mac fix in Command 6 above, or try opening VS Code manually and using File → Open Folder.
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.
open vscodecode .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 .start is a Windows command for opening programs, but code . is the cross-platform VS Code command that works everywhere.vscode --opencode, not vscode.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.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.
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.
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.
git revert would have fixed it in two seconds. That's the moment git stops feeling pointless.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.
git --version in terminal. If it's not there, install Xcode Command Line Tools: xcode-select --installAfter 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.
git --version
# Should show something like: git version 2.43.0Git needs your name and email to label your save points. Run these three commands (replace with YOUR details):
git config --global user.name "Your Name" git config --global user.email "your@email.com" git config --global init.defaultBranch main
"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.Git has hundreds of commands. You need 4. These four cover about 80% of everything you'll ever do with version control:
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:
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.
# 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"
Connecting your local folder to GitHub so your code lives in two places — your computer and the cloud.
ai-projecthttps://github.com/YOURUSERNAME/ai-project.git# 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
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:git push asks for username, enter your GitHub username. When it asks for password, paste the PAT (not your account password).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.
git push asks for username/password — GitHub now requires a Personal Access Token. Go to Settings → Developer Settings → Personal Access Tokens → Generate new token (classic). Use this as your password.git remote remove origin then try the git remote add command again.git push -u origin main (with the -u flag).
git add . → git commit -m "what I changed" → git push. Three commands. Every time. This becomes muscle memory within a week.git pull. Pulls down whatever the other machine pushed last. Forgetting this is how merge conflicts start.git push. Even if you didn't finish — push your work-in-progress so the other machine has it.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.git push then git commitgit add . → git commit -m "message" → git pushadd prepares your changes, commit saves them locally, push uploads them to GitHub. This three-step workflow will become second nature.git save then git uploadgit add, git commit, and git push.git add . → git commit → git push)
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.
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 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.
.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..pkg installer. Or if you have Homebrew: brew install nodeTwo 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.
node --version # Should show: v24.x.x (any 24.x number is fine) npm --version # Should show: 11.x.x (npm comes with Node)
node not found, try opening a new terminal tabnpm not found but node works: reinstall Node — npm should come bundledEACCES or "permission denied" when you run npm install later (especially on Mac/Linux): don't use sudo npm — that's the shortcut that causes bigger problems. The proper fix is to re-point npm's global folder to your home directory. Ask Claude: "I got EACCES on npm install. I'm on [Mac/Linux]. Walk me through fixing npm's global prefix without using sudo. Explain each step before I run it." Don't let AI suggest sudo as the fix.
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.node --version and npm --version. Both should print a version number without errors.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:
Win+Shift+S. Mac: Cmd+Shift+4. Save it somewhere you can find — Desktop is fine.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.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.node --version in a fresh terminal.pkg installer. Or with Homebrew: brew install python. Python may already be installed — check first.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
python --version and pip --version show version numbers?python not found — you probably missed the "Add to PATH" checkbox. Reinstall and CHECK that box.python3 and pip3 instead of python and pip — macOS often uses python3 as the command.pip not found: try python -m pip --version
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.npm install express." Which language does this package belong to?pip install, not npm install. npm is Node.js's package manager.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.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.
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:
Four lines. Your code talks to an AI. That's where we're heading. The setup you just completed makes this possible.
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.
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.
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.
example.comgit push

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.
git add . && git commit -m "fixed colour" && git push. What happens next?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.


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?
<!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>
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.
<!DOCTYPE html> line
You know this workflow now. Open the terminal (Ctrl+`) and run:
git add .
git commit -m "My first real webpage"
git pushThree commands. Every time. This is already becoming muscle memory.
ai-project repositoryWait 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 Netlify auto-guessed npm run build, clear it: Site settings → Build & deploy → Build command (leave blank) → Save.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).Styles.css and styles.css are different files. Rename to match exactly.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.
index.html is in the root of your repo, not in a subfolderThat 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.


git add . → git commit -m "message" → git pushSeven 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.
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.Good breath point. If you need to stop here, save your place — we'll email you the link back.
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.
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?
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.<h1>) and a closing (</h1>). Content goes between them. That's HTML.<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.<a href="url"> makes a link. <img src="image.jpg"> shows an image. The tag says WHAT, the attribute says HOW.HTML has over 100 tags. You need about 12. Here they are — grouped by what they do:
<header> <nav> <main> <section> <footer><h1>–<h6> <p> <a> <img><div> <span> <ul> / <li>Replace everything in your index.html with this. Read the comments (the grey text) — they explain what each piece does:
<!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>© 2026 My AI Project</p> </footer> </body> </html>
<div align='center'> is deprecated)Open browser DevTools → Console. Zero red errors = structural pass. Then: File → View Source — read it top to bottom.
git add . && git commit -m "multi-section page" && git push</section> can break the layout<section> and <div>?<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.<div> is newer and better<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! and press Tab. It generates the entire HTML starter template instantly. You'll never type <!DOCTYPE html> by hand again.<button onClick="submit()" type="buttin">Send</button>. What's wrong?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.
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.
body { background: #0b0b0c; } — the selector (body) picks what to style, the property (background) says what to change, the value (#0b0b0c) says to what.Add a <style> block inside your <head> tag (after <title>, before </head>). Paste this CSS:
<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>
Resize the browser to 375px width. Does it still look right? Then: open in Firefox or Safari. Compare.
git add . && git commit -m "dark theme CSS" && git push<style> block is inside <head>, not inside <body>#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.
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.
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.
const name = "My AI Tool"; // doesn't change let count = 0; // can change let isActive = true; // true or false
const for things that don't change. Use let for things that do. Never use var (it's the old way).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.
function greet(name) { return "Hello, " + name; } greet("World"); // returns "Hello, World"
// 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
querySelector finds elements. Then you can change them.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.
const button = document.querySelector('button'); button.addEventListener('click', function() { alert('Button clicked!'); });
// 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);
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.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.
<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>
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.
addEventListener('click', ...) to addEventListener('clik', ...). What happens? Why? This is how you learn the language.git add . && git commit -m "added JavaScript interaction" && git push<script> block is just before </body>, not inside <head>' needs a closing '
addEventListener('click', ...).querySelectoraddEventListenerfetch()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.textContentThree 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.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.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:
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.




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.
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.
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.
sk-ant-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.
ai-proxy and click DeployANTHROPIC_API_KEYYour 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.
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.npx wrangler deploy if you're using the CLI). No redeploy = env.ANTHROPIC_API_KEY reads as undefined even though you just set it.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:
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.
Add this to your index.html — a text input, a button, and the JavaScript that connects to your Worker:
<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>
YOUR-NAME in the fetch URL with your actual Cloudflare Workers subdomain. You can find this on your Worker's dashboard.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?
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?Access-Control-Allow-Origin headerYou 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
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.
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.
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:
fetch() in try/catch and show a helpful message — not a blank screen or a cryptic JavaScript error.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:
escapeHtml), and a disabled button during the request. This is the difference between a toy and a tool.<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.
<!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>
Run the 5-test checklist: (1) empty input, (2) 10K+ chars, (3) offline, (4) <script> injection attempt, (5) happy path. All five must pass.
tool.html in Live Server. Paste some text (a news article paragraph, a tweet, anything). Click Analyse. Does Claude return a structured analysis?git add . && git commit -m "first AI tool" && git pushdata.content[0].text
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.btn.disabled = true is there — it prevents duplicate submissions and duplicate API charges.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.
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.
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:
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.
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.
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.
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:
sk-OPENAI_API_KEY
Your Worker needs to know which API to call. Update it to accept a provider field and route accordingly:
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':'*' }
});
}
};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.Create compare.html. The key: Promise.all() fires both requests simultaneously — no waiting for one before starting the other.
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.
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?
compare.html. Type a question. Do you see two responses — one from Claude, one from GPT — side by side?Promise.all() do?Promise.all() does the opposite — it runs them simultaneously.Promise.all() can throw errors, but error handling isn't its purpose. It's about running multiple async tasks in parallel.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.
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.
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.
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:
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.
Create pipeline.html. Step 1 analyses text, Step 2 takes that analysis and generates action items. Here's the working JavaScript:
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.
console.log(analysis) after Step 1 to verify the first call worked before Step 2 runs
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
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.
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.
—
What's wrong with this AI-generated code?
System prompts, sector-specific applications, and the human-overlay habits for directed, verified AI work.
Good breath point. If you need to stop here, save your place — we'll email you the link back.
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.
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.
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.
Update your Worker to accept and forward a system parameter:
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 }]
})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:
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.
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.
"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."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:
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:
"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.
system field is at the top level of the API request, not inside messages
system field at the top level — outside the messages array.system field at the top level of the request bodysystem 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.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.
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)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.
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.
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.
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:
"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.
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.
Deploy & Polish. Error handling, security, testing, performance, portfolio.
Good breath point. If you need to stop here, save your place — we'll email you the link back.
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.
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.
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.
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.
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."try/catch around your fetch() catches this. Show "Check your internet connection" — not a JavaScript stack trace.data.content[0].text exists. Check each level: if (data?.content?.[0]?.text). If not, show "Unexpected response — please try again."Update your AI tool to retry once on failure with a 2-second delay. If the retry fails too, show the error message:
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));
}
}
}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?
fetch() call is wrapped in try/catch. Make sure you're showing the error in the result div, not just console.log-ing it.
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.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.
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.
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.
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.
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.
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 }); }
Without rate limiting, a bot or malicious user could burn through your API credits in minutes. Add a simple counter using Cloudflare KV:
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?
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.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 });
.gitignore includes .env and *.key. All three done?.gitignore with .env and *.key listed. Then wrangler deploy.Create a .gitignore file in your project root. This tells Git which files to NEVER commit — even if you accidentally run git add .:
# 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.
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.
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.
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.
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.
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.
Create test.js to verify your tool handles edge cases:
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})`); } }
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.
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.
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.
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.
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.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:
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}`; }
model parameter. Try claude-haiku-4-5 for fast tasks and claude-sonnet-4-6 for complex ones. Compare the output quality and speed.Before the response starts streaming, show a "skeleton" — a pulsing placeholder that tells the user exactly where the content will appear:
.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.
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.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.
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.
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.
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.
wrangler deploy# 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
git add . — stages all changed files (tells Git "include these")git commit -m "message" — saves a snapshot with a description of what changedgit push — uploads to GitHub. Netlify detects the push and auto-deploys your websitenpx wrangler deploy — uploads your Worker code to Cloudflare (separate from the website)chrome://extensions → reload — Chrome doesn't auto-update local extensions, so you click reload manuallygit revert and push again. The pipeline is your safety net.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.
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.
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.
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."
Create a README.md in your GitHub repo that showcases everything you built:
# 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)
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.
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.
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:
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.
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.
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.
# [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
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.
# 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?
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 push: git add . && git commit -m "final project complete" && git push
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.
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.
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.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.
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.
Every key term from BUILD
Every key term from BUILD