Ten modules, a hundred days, one page at a time. Each day gives you the
idea, a worked case file, the trap that catches people out, and the one
line to remember. Work it in order, or jump straight to what you need.
Vibe coding means you describe what you want, an AI agent writes the code, and you judge the result. Your job moves from keyboard to judgement.
Describe
You · 01
“A form my team uses to book leave.”
The outcome, who it's for, and what "done" looks like.
Plain language beats jargon.
Build
Agent · 02
“Here's my plan. Proceed?”
Plans the work, writes the files, runs commands.
You approve anything risky.
Check
You · 03
“What if the dates overlap?”
Click through it like a real user.
Try the weird inputs, not just the happy path.
Steer
You · 04
“Use SA date format, DD/MM.”
Say what's wrong and what you expected.
One fix at a time, then check again.
You're the director. The agent is the crew. The call is still yours.
Day 02 / 100 · What vibe coding is
Not just for developers.
Anyone who can describe a problem clearly can start. What changes is what you build, and how far you should take it alone.
PMs & POs
Prototypes
Builds: clickable ideas to test with customers
Watch: a prototype is not a product
Ops & admin
Internal Tools
Builds: trackers, reports, small automations
Watch: who fixes it when you're on leave?
Founders & SMEs
Mvps
Builds: a first version to prove demand
Watch: customer data and POPIA from day one
Developers
Speed
Builds: boilerplate, tests, refactors, spikes
Watch: reviewing less because it's faster
If you can describe the problem clearly, you can start.
Day 03 / 100 · What vibe coding is
Great at the first 80%.
AI agents build working software fast. The hard part is the last 20%: edge cases, security and scale. Know which zone your idea sits in.
Go
Sweet Spot
▸
Landing pages and static sites
▸
Personal tools and scripts
▸
Prototypes and mockups
▸
Internal dashboards over exports
▸
Chrome extensions
Go carefully
Needs Guardrails
▸
Anything with logins
▸
Apps storing personal data
▸
Connecting to paid APIs
▸
Tools other teams rely on
▸
Anything customer-facing
Get engineers
Not Solo
▸
Payments and billing logic
▸
Health or financial records
▸
High-scale or real-time systems
▸
Core regulated platforms
▸
Security-critical code
Prototype anything. Ship carefully. Know your red zone.
Day 04 / 100 · What vibe coding is
From how to what and why.
The skill isn't typing code any more. It's knowing what you want, explaining it clearly, and checking what comes back.
OLD HABIT
NEW HABIT
Learn the syntax first
Learn to describe outcomes
Write every line
Review every change
Fix it yourself
Diagnose it, then direct the fix
One big build
Small steps, checked often
Trust your code
Verify the agent's code
Clarity is the new coding skill.
Day 05 / 100 · What vibe coding is
Pick the right tool for the job.
AI coding tools fall into four families. They overlap and change monthly, so learn the family first and the brand second.
Chat assistants
Ask &Amp; Explain
Good for: explaining, snippets, one-off questions
Limit: can't see or change your project
App builders
In The Browser
Good for: fast hosted prototypes, no setup
Limit: less control, harder to take elsewhere
Editor AI
In Your Ide
Good for: people already working in code
Limit: assumes you can read what it writes
Coding agents
Whole Project
Good for: multi-file work, running tests, Git
Limit: needs setup and guardrails
Learn one agent deeply. The skills travel with you.
Day 06 / 100 · What vibe coding is
Meet your AI developer.
Claude Code is an agent that works inside a real project folder. It runs in the terminal, VS Code or the desktop app, and it does four things.
Reads
Understands
Explores your folder and learns how the project fits together.
Ask it to explain before you ask it to change.
Plans
Proposes
Plan mode lays out the steps before any file is touched.
You agree the plan, then it builds.
Acts
Does The Work
Edits files, runs commands, installs packages.
Asks your permission for anything risky.
Remembers
Claude.Md
A file of project rules it reads at the start of every session.
Your standards, written down once.
Treat it like a sharp new hire: fast, capable, needs supervision.
Day 07 / 100 · What vibe coding is
Start tiny. Finish today.
Your first project isn't about the product. It's about feeling the full loop once: describe, build, check, steer, done.
01
5 Min
Pick
Something you'd actually use this week. One screen, one job.
02
10 Min
Describe
Three sentences: who it's for, what it does, what “done” looks like.
03
20 Min
Plan, then build
Ask for a plan first. Agree it, then let it build.
04
15 Min
Use it for real
Try it on a real task. Fix the one thing that annoys you most.
≈ 50 Minutes · One Finished Thing
Small and finished beats big and abandoned.
Day 08 / 100 · What vibe coding is
Cheap to start. Easy to overspend.
The subscription is the smallest cost you'll see. Budget for all three: money, time and risk.
Money
The Bill
Plans: a monthly subscription with usage limits
Or: pay per use through an API key
Watch: long sessions and big projects use more
Time
The Hours
Setup: a day or two to get comfortable
Review: often longer than the build itself
Watch: fixing what you didn't check
Risk
The Exposure
Security: bugs you can't spot yet
Data: personal info handled badly
Watch: code nobody can maintain
Budget money, time and risk. Not just the subscription.
Day 09 / 100 · What vibe coding is
Fast code. Fast mistakes.
An agent makes you faster at everything, including mistakes. These are the four that catch beginners, and where this playbook fixes each one.
Leaked secrets
Fix · Day 36
API keys and passwords pushed to GitHub.
Bots scan public repos for them constantly.
Exposed data
Fix · Day 65
Personal info stored or shared carelessly.
POPIA applies to your side project too.
Destructive actions
Fix · Day 27
The agent deletes or overwrites the wrong thing.
No commit, no way back.
Mystery code
Fix · Day 28
It works, but nobody knows how or why.
The first bug becomes a rebuild.
Every risk here has a habit that stops it. You'll learn them all.
Day 10 / 100 · What vibe coding is
Your next 90 days.
You won't be an engineer in 100 days. You will be able to build useful things, know when they're safe, and know when to ask for help.
Set up
Days 01–20
Mindset, tools and your first win
DAYS 21–40
Direct
Talk to the agent, learn how software works
DAYS 41–60
Build
Real projects, then testing them
DAYS 61–80
Ship
Guardrails, security, going live
DAYS 81–100
Grow
Use it at work, then level up
Expect it to break. That's where you learn.
Module 2SetupDays 11–20
Day 11 / 100 · Setup
The terminal is just a chat box.
You type a command, press Enter, and it answers. Five commands cover almost everything you'll need to start.
Five Commands
pwd
Where am I right now?
ls
What's in this folder? (dir on Windows CMD)
cd my-project
Move into a folder. cd .. goes back up.
mkdir my-project
Make a new folder.
claude
Start Claude Code in this folder.
Not a terminal person?
Claude Code also runs inside VS Code and the Claude desktop app.
Same agent, friendlier window.
You'll still meet the terminal, so learn these five anyway.
Five commands get you most of the way. Learn those first.
Day 12 / 100 · Setup
Installed in two minutes.
One command installs it, one command checks it, and a browser login connects it to your account. No Node.js needed for the recommended installer.
Install · Check · Log In
macOS / Linux
curl -fsSL https://claude.ai/install.sh | bash
Windows
irm https://claude.ai/install.ps1 | iex
in PowerShell
Check it
claude --version or claude doctor
Log in
claude
then sign in with your browser
Before you start
You need a paid Claude plan (Pro or above) or an API account. The free plan doesn't include Claude Code.
It updates itself in the background.
Older guides say use npm. That route is now legacy.
Install, check, log in. Then stop and celebrate.
Day 13 / 100 · Setup
One project. One folder.
Everything for a project lives in one folder. Start Claude Code inside it, and that folder is what it works on.
A Typical Project
my-leave-form/
├─ index.htmlthe page├─ style.csshow it looks├─ script.jswhat it does├─ README.mdhow to run it├─ CLAUDE.mdrules for the agent├─ .gitignorewhat Git must skip└─ .envsecrets, never shared
Folder rules
One folder per project. Never mix two.
No spaces in names: my-leave-form, not My Leave Form.
Keep projects in one home, like Documents/projects, not Downloads or the Desktop.
cd into the folder before you type claude.
Where you start Claude is what it works on. Choose on purpose.
Day 14 / 100 · Setup
Save points for your whole project.
Git records every change to your project, so you can always go back. You'll mostly ask the agent to use it, but you need the five words.
Five Words
Repository
The project folder plus its full history.
Commit
A save point with a short note: “Added date validation.”
Diff
Exactly what changed between two save points, line by line.
Branch
A safe copy to experiment on without touching the main version.
Push
Send your save points to GitHub, off your laptop.
Commit early. Commit often. Commit before every ask.
Day 15 / 100 · Setup
Your code's home away from home.
Git keeps history on your laptop. GitHub keeps a copy online, where it's backed up, shareable and ready to deploy.
Backup
Off Your Laptop
Stolen or broken laptop? Your project is safe.
Share
Work Together
Invite others, review changes, discuss them.
Ship
Go Live
Most hosting services deploy straight from it.
Set it up safely
Turn on two-factor login on day one.
Make new repositories private by default.
Only go public after a review for secrets.
Private by default. Two-factor always. Push every session.
Day 16 / 100 · Setup
A window into what it wrote.
VS Code is a free code editor. You won't write much code in it, but it's the easiest way to see what the agent changed.
Explorer
Your Files
The folder tree. Click any file to open it.
Editor
Read The Code
Where you look at what was written.
Terminal
Run The Agent
A terminal built in. Start Claude Code here.
Source Control
See Changes
Every changed file, with its diff, before you commit.
The agent writes. VS Code lets you watch.
Day 17 / 100 · Setup
Node runs JavaScript on your computer.
Most beginner projects in this playbook (web apps, Chrome extensions, Expo) are JavaScript. Node is what runs and builds them. Install the LTS version.
Six Things To Recognise
node
The engine that runs JavaScript outside a browser.
npm
The installer for other people's code packages.
package.json
The project's recipe: what it needs and how to run it.
node_modules
The downloaded packages. Big. Never commit it.
npm install
Download everything the recipe lists.
npm run dev
Start the project on your machine.
package.json is the recipe. npm install does the shopping.
Day 18 / 100 · Setup
localhost is your private internet.
Before anything goes online, it runs on your own machine. Only you can see it, so you can break it safely.
01
Start
npm run dev
02
Open
localhost:3000
03
Change
edit and save
04
Refresh
see it update
05
Stop
Ctrl + C
The :3000 bit is a port, like a door number on your computer. Each running project gets its own door.
Local first. Online only when it's ready.
Day 19 / 100 · Setup
Tell it the rules once.
CLAUDE.md is a plain text file in your project that Claude Code reads at the start of every session. It's your standing brief.
# Leave form
Internal leave-request tool for the ops team.
## Stack
Plain HTML, CSS, JavaScript. No frameworks.
## Rules
- Dates are DD/MM/YYYY (South Africa)
- British spelling in all text
- Ask before installing any package
- Never commit .env
## Done means
- Tested in Chrome and on a phone
How to start one
Type /init and it drafts one from your project.
Edit it: cut what's obvious, add your rules.
Keep it short and specific.
When you correct the agent twice, add the rule here.
Short. Specific. Kept up to date.
Day 20 / 100 · Setup
Set up once. Build for 80 days.
Tick every box before Module 3. Each one you skip now becomes a confusing error later.
Terminal opens and you know pwd, ls, cd
claude --version works
Logged in to Claude Code
A projects folder in a sensible place
Git installed, name and email set
GitHub account with two-factor on
VS Code installed and opens your folder
Node LTS installed (node -v works)
A test project runs on localhost
A CLAUDE.md with your first rules
Every box ticked? Module 3: time to talk to the agent.
Module 3Talking to the agentDays 21–30
Day 21 / 100 · Talking to the agent
Say what, not how.
You don't need to know how to build it. You need to know who it's for, what it should do, and how you'll know it's done.
Code-First
Add a CSV export using papaparse with a download handler on the table component.
Outcome-First
Finance needs last month's calls in Excel. One row per call: date (DD/MM/YYYY), number, duration. Done when they can open it and filter by date.
The three-part brief
Who uses it and why they need it.
What it should do, in their words.
Done when you can check it yourself.
Describe the finish line. Let it choose the route.
Day 22 / 100 · Talking to the agent
Plan first. Code second.
Plan mode makes Claude Code research and propose before it touches a single file. It's the cheapest place to catch a bad idea.
01
Switch to plan mode
Press Shift + Tab until it says plan mode, then describe the task.
02
Read the plan
Which files? What new pieces? Anything you didn't ask for?
03
Question it
“Is there a simpler way?” “What could go wrong?” “What's missing?”
04
Approve, then build
Only when the plan matches what you want. Then let it work.
A five-minute plan saves a five-hour rebuild.
Day 23 / 100 · Talking to the agent
One step. Then check.
Break every feature into steps you can test on their own. Build one, check it works, commit it, then ask for the next.
The page, with dummy content
STEP 1 · CHECK · COMMIT
Layout
Fields that accept input
STEP 2 · CHECK · COMMIT
Form
Entries stored somewhere
STEP 3 · CHECK · COMMIT
Save
Saved entries shown back
STEP 4 · CHECK · COMMIT
List
An email when one is added
STEP 5 · CHECK · COMMIT
Notify
Small steps, checked often, committed each time.
Day 24 / 100 · Talking to the agent
It only knows what you tell it.
The agent can read your files, but it can't read your mind, your team or your country. Give it the context that changes the answer.
Who
The Users
Who uses it, how often, on what device.
“Call-centre agents, on shared PCs.”
Limits
Constraints
Stack, budget, rules, law.
“No new packages. POPIA applies.”
Examples
What Good Looks Like
A similar screen, file or format.
“Match the style of the invoices page.”
Where
Point At Files
Name the exact files with @.
“Fix the date check in @form.js.”
Relevant, not everything.
Day 25 / 100 · Talking to the agent
Show it. Don't describe it.
Claude Code can see images. Drag a screenshot into the terminal or paste it in, and skip the paragraph of explaining.
The bug
Screenshot It
The error on screen, or the layout that looks wrong.
“This button overlaps the table on mobile.”
The idea
Sketch It
A photo of a whiteboard or a napkin drawing works.
“Build this screen, roughly like this.”
The target
Show An Example
A site, screen or data sample you like.
“Make the report look like this one.”
A picture is worth a thousand words of prompt.
Day 26 / 100 · Talking to the agent
Read the prompt. Then press Enter.
Claude Code asks before it does anything with real consequences. These prompts are your seatbelt. Here's how to answer them.
Usually yes
Low Risk
▸
Reading files in your project
▸
Editing files you asked about
▸
Running your own tests
▸
Starting your local server
Stop and read
Check First
▸
Installing a new package
▸
Deleting files
▸
Running a script from the internet
▸
Anything outside your folder
Usually no
Ask Why
▸
Touching .env or secrets
▸
Pushing to GitHub
▸
Admin or sudo commands
▸
Anything you can't explain
If you can't explain it, don't approve it.
Day 27 / 100 · Talking to the agent
Two safety nets. Use both.
Claude Code saves a checkpoint every time you send a prompt. Git saves what you tell it to. They cover different accidents.
Checkpoints
When
Automatically, every prompt
Undo
Esc Esc or /rewind
Covers
Files the agent edited
Misses
Files changed by commands it ran
Git Commits
When
When you (or it) commit
Undo
Go back to any commit
Covers
Everything in the project
Bonus
Pushed to GitHub, off your laptop
Rewind for oops. Git for everything. Commit first.
Day 28 / 100 · Talking to the agent
Don't just trust it. Check it.
After every task, spend two minutes checking. You're not reviewing code line by line. You're checking the story matches the facts.
01
Read the summary
What does it say it did? Anything you didn't ask for?
02
Check the file list
Source Control in VS Code. Only the files you expected?
03
Skim the changes
Big deletions? New packages? Anything touching secrets?
04
Try it yourself
Use it like a real user. Does it actually work?
Summary. Files. Changes. Try it. Every time.
Day 29 / 100 · Talking to the agent
“Why?” is your best prompt.
When something looks off, don't guess. Ask. And when it's going the wrong way, stop it early with Esc.
Five Course-Corrections
“Why did you change this?”
Understand before you accept or undo.
“What are the alternatives?”
Surface simpler options it didn't pick.
“I expected X, I got Y.”
Clearer than “that's wrong”.
“Undo that. Try simpler.”
Resets the direction, not just the detail.
Esc
Stop it mid-task. Then explain what you want.
Ask why. Say what you expected. Or rewind.
Day 30 / 100 · Talking to the agent
Fresh session. Sharper agent.
The agent has a working memory, the context window. Every message, file and error fills it. When it's crowded, quality drops.
Four Tools
/context
See how full the working memory is.
/clear
Start fresh. Best between tasks.
/compact
Summarise so far and keep going.
New task
New session. CLAUDE.md carries your rules over.
Signs it's crowded
It repeats a mistake you already fixed.
It forgets a decision from earlier.
Answers get slower and vaguer.
You're scrolling up to remind it.
One task, one session.
Module 4How software worksDays 31–40
Day 31 / 100 · How software works
The restaurant model.
Every app has a public side and a private side. Knowing which is which tells you where things belong, and where they must never go.
Frontend
The Dining Room
What users see and click. Runs in their browser.
Anyone can inspect it.
Backend
The Kitchen
The rules, the logic, the secrets.
Runs on a server users can't see.
API
The Waiter
Carries requests to the kitchen and brings back answers.
More on Day 32.
Database
The Pantry
Where the data is kept between visits.
More on Day 33.
The dining room is public. Keep the recipes in the kitchen.
Day 32 / 100 · How software works
Apps talking to apps.
An API is a menu another system offers: send a request in the right shape, get data back. Five parts to recognise.
Anatomy Of A Request
Endpoint
The address you send the request to.
Method
GET reads, POST creates, PATCH updates, DELETE removes.
Key
Proves who's asking. A secret.
Response
The data back, usually as JSON.
Status code
The one-number verdict. See right.
Status Codes
200
All good
401
Not allowed: check the key
404
Wrong address
429
Too many requests
500
Their server broke
Know the address, the key and the limits.
Day 33 / 100 · How software works
A spreadsheet with rules.
A database stores your app's data so it's still there tomorrow, and so more than one person can use it at once.
id
name
phone
branch
101
T. Mokoena
082 555 0101
Sandton
102
A. Naidoo
072 555 0102
Durban
103
J. Smit
083 555 0103
Cape Town
Table = a sheet. Row = one record. Column = one field. Primary key (id) = a unique number per row. Relationship = linking tables, like customers to their orders.
Where to keep data
In the browser: just you, one device.
A single file (SQLite): one small app.
A hosted database (e.g. Postgres): real users, shared data.
Store what you need. Nothing more.
Day 34 / 100 · How software works
Who are you? What can you do?
Two different questions, often confused. Getting the first right and the second wrong is the most common security bug in beginner apps.
Authentication · Who
Passwords
Hashed, never stored as typed
Sign in with…
Google, Microsoft, GitHub
Magic links
A one-time link by email
Two-factor
A code as a second check
Authorisation · What
Roles
Staff, manager, admin
Ownership
Only your own records
Every request
Checked on the server
Least access
Start with none, add
Borrow the login. Check permissions on every request.
Day 35 / 100 · How software works
Settings outside the code.
Secrets and settings that change between your laptop and the live site live in environment variables, not in your code.
The Secret File
# .env · on your machine only
DATABASE_URL=postgres://…
WEATHER_API_KEY=sk_live_…
SMTP_PASSWORD=…
# .gitignore · tells Git to skip it
.env
The Safe Template
# .env.example · safe to commit
DATABASE_URL=
WEATHER_API_KEY=
SMTP_PASSWORD=
# shows what's needed,
# never the values
Code is shared. Secrets are not.
Day 36 / 100 · How software works
Once pushed, assume it’s public.
Git remembers everything. A secret committed once stays in the history, even if you delete it in the next commit.
01
Ignore first
Add .env to .gitignore before your first commit, not after.
02
Check the diff
Scan every commit for keys, passwords and tokens before it goes.
03
Tell the agent
In CLAUDE.md: “Never read, print or commit .env.”
04
Turn on scanning
Enable GitHub's secret scanning and push protection on your repos.
Ignore first. Check always. Rotate if in doubt.
Day 37 / 100 · How software works
Standing on other people’s code.
Packages save you from rebuilding common things. Each one is also code you didn't write, from people you don't know, that you now depend on.
Four Terms
Package
A ready-made piece of code you install.
Version
2.4.1 = major . minor . patch. Major changes can break things.
Lock file
package-lock.json: the exact versions. Commit it.
Update
Security fixes arrive as updates. Old means risky.
Before adding one, ask
Do we actually need it?
Is it widely used?
Updated in the last year?
Could a few lines do the job?
Every package is a promise you now have to keep.
Day 38 / 100 · How software works
Errors are clues, not failures.
Every error says what went wrong and where. Your job isn't to understand it all. It's to find it and hand the whole thing to the agent.
Where To Look
Browser console
Press F12. Errors from the frontend.
Terminal
Errors from your local server.
Host logs
Errors from the live site, in the hosting dashboard.
Reading One
TypeError: Cannot read
properties of undefined
at showList
(script.js:42)
what · where · line
Copy the whole error. Paste it to the agent.
Day 39 / 100 · How software works
Your laptop isn’t a server.
Hosting is renting a computer that's always on and always online. Three families, from simplest to most responsibility.
Static hosting
Simplest
Plain pages, no backend.
Often free for small sites.
App platforms
Most Projects
Frontend plus backend.
Deploy straight from GitHub.
Your own server
Full Control
A cloud VM or an in-house server.
You patch and run it.
Ask before you pick
Where does the data physically live? (POPIA cross-border rules)
What does it cost at 10× the users?
Who gets told when it's down?
Match the host to the app, and the data to the law.
Day 40 / 100 · How software works
The internet's phone book.
A domain is the name. DNS is the phone book that turns the name into the address of the computer hosting your site.
01
You type
myapp.co.za
02
DNS looks up
the records
03
Gets an address
an IP number
04
Browser connects
to the host
Four Record Types
A
Name → IP address
CNAME
Name → another name
MX
Where email goes
TXT
Proof and email security
Own your domain. Change one record at a time.
Module 5First projectsDays 41–50
Day 41 / 100 · First projects
Build something you’ll actually use.
The best first project is small, personal and useful this week. Score your idea, then pick from the ladder below.
The five-yes test
Would you use it every week?
Is the first user you?
Does it fit on one screen?
No one else's personal data?
Could it be done this weekend?
The Project Ladder · Days 42–50
DAY 42
A static web page
DAY 43
A personal tool
DAY 44
Spreadsheet automation
DAY 45
A Chrome extension
DAY 46
A simple app with data
DAY 47
Forms
DAY 48
A dashboard
DAY 49
A chatbot
DAY 50
Mobile basics with Expo
Scratch your own itch first.
Day 42 / 100 · First projects
Your first page on the internet.
One page, no backend, no database. The simplest complete loop: describe it, build it, check it on a phone, put it online.
Starter Prompt
Build a one-page site for my photography side hustle: a hero photo, three sample galleries and a contact email. Plain HTML and CSS, no frameworks. It must look good on a phone.
You'Ll Learn
Level
HTML and CSS basics, checking a design on mobile, and your first deploy to static hosting (Day 39).
Done when
It loads properly on your phone
Contact link opens an email
It's live on a real link
You've shared it with one person
Ship it plain. Improve it live.
Day 43 / 100 · First projects
Solve your own annoying task.
Every job has a small, repetitive chore. A personal tool takes something in, does one useful thing, and gives you something back.
Starter Prompt
Build a page where I paste messy meeting notes and it pulls out the actions into a table: action, owner, due date. Add a button to copy the table. Everything stays in the browser.
You'Ll Learn
Level
The input, process, output pattern behind almost all software, and how to describe a rule clearly.
Done when
You used it in a real meeting
It handles notes with no actions
Copy works into email or ClickUp
Nothing is sent anywhere
Useful to one person beats impressive to nobody.
Day 44 / 100 · First projects
Let it do the Monday spreadsheet.
Your first Python project. Scripts are brilliant at the boring, exact, repeatable work of combining and cleaning spreadsheets.
Starter Prompt
Every Monday I combine five branch Excel files into one summary with totals per branch. Write a Python script that reads every file in a folder and writes the summary to a new Excel file. Don't change the originals.
You'Ll Learn
Level
Installing Python, running a script with python summary.py, and how scripts read and write files.
Done when
One command makes the summary
Totals match last week's manual version
Originals are untouched
A README says how to run it
Check it against last week's manual numbers.
Day 45 / 100 · First projects
A small superpower in your browser.
An extension adds a feature to every page you visit. It's a few files and a manifest that lists what it's allowed to do.
Starter Prompt
Build a Chrome extension (Manifest V3) that finds South African phone numbers on the current page, highlights them, and copies one when I click it. Only run when I click the extension button.
You'Ll Learn
Level
The manifest, permissions, and loading your own extension through chrome://extensions in developer mode.
Done when
It works on three different sites
It only runs when you click it
Permissions list is short
No data leaves the browser
Ask for the least access that works.
Day 46 / 100 · First projects
Your first app that remembers.
Now there's a frontend, a backend and a database. Almost every app does four things with data: create, read, update and delete.
Starter Prompt
Build a team book-lending tracker: add a book, record who has it and when it's due, mark it returned. Save data in a SQLite database. Run locally for now. Ask before deleting anything.
You'Ll Learn
Level
How the frontend, backend and database connect (Days 31–33), and the four data actions every app needs.
Done when
Add, view, edit, delete all work
Data survives a restart
Delete asks for confirmation
You know where the data file is
Create, read, update, delete. Then back it up.
Day 47 / 100 · First projects
Where users meet your data.
Forms are where real people type unpredictable things. A good form is clear for humans and strict with what it accepts.
Clear
For People
A visible label on every field.
Plain error messages next to the field.
A confirmation when it's done.
Strict
For Safety
Validate in the browser and again on the server.
Only ask for what you need.
Required means genuinely required.
Protected
For The Bots
Limit how often one person can submit.
A hidden trap field or a challenge.
Watch for sudden floods.
Validate twice: browser for kindness, server for safety.
Day 48 / 100 · First projects
One screen. The right numbers.
A dashboard earns its place by answering questions people actually ask. Start from the questions, not the data.
Starter Prompt
Build a dashboard that answers three questions for our Monday meeting: open tickets by team, tickets closed this week, and the oldest five open tickets. Use sample data first. Read-only.
You'Ll Learn
Level
Turning questions into charts, working with sample data safely, then connecting read-only to the real source.
Done when
Each chart answers a named question
It works with sample data first
Real data is read-only
Someone else uses it weekly
Answer questions. Don't decorate data.
Day 49 / 100 · First projects
A chatbot that knows your stuff.
A chat window, your own backend holding the key, and an AI API behind it. Plus clear instructions on what it may and may not answer.
Starter Prompt
Build a chat page that answers staff questions using only our leave policy (attached). The API key stays on the server. If the answer isn't in the policy, say so and suggest contacting HR.
You'Ll Learn
Level
Calling an AI API from a backend, keeping the key secret (Days 32, 35), and writing instructions that limit what it says.
Done when
The key is never in the browser
It refuses questions outside the policy
It says “I don't know” when unsure
No personal data in the chat logs
Key on the server. Answers from your sources only.
Day 50 / 100 · First projects
An app on your phone today.
Expo lets you build a real mobile app in JavaScript and run it on your own phone in minutes. The app stores come much later.
Starter Prompt
Create a new Expo app: a daily water tracker with a big plus button, a total for today, and a reset at midnight. Keep it to one screen. Tell me how to run it on my phone.
You'Ll Learn
Level
React Native basics, npx create-expo-app, and scanning a QR code with the Expo Go app to see changes live.
Done when
It runs on your phone via Expo Go
Changes appear as you save
Tested on iPhone and Android
It looks right on a small screen
Build on your phone. Publish much later.
Module 6Quality & testingDays 51–60
Day 51 / 100 · Quality & testing
Tests are proof, not paperwork.
The agent writes code fast, and it can't tell whether that code does what you meant. Testing is how you find out before your users do.
Manual
You Click Through
A written checklist anyone can follow.
Day 53.
Automated
Code Checks Code
Runs in seconds, every time.
Day 52.
Real users
Feedback
What you'd never think to try.
Day 78.
When You Find A Bug, And What It Costs
While building
A second to fix
Before commit
Minutes
Before release
Hours
Found by a customer
Days, and trust
If you didn't check it, it doesn't work yet.
Day 52 / 100 · Quality & testing
Let it check its own work.
Automated tests are small programs that check your code gives the right answer. The agent writes them. You decide what they check.
Ask Like This
Write tests for the leave-day calculation. Cases: a normal week, a span over a weekend, a public holiday, a month end, and a single day. Run them and show me the results.
Three Terms
Unit test
Checks one small piece does one thing right.
Test runner
Runs them all: npm test or pytest.
Pass / fail
Green is good. Red tells you exactly what broke.
Watch for
Tests that check nothing important.
Tests only for the easy cases.
The agent changing a test to make it pass.
Tests that never actually ran.
You choose the cases. It writes the tests.
Day 53 / 100 · Quality & testing
A checklist anyone can run.
A manual test script is a list of steps and what should happen. Ask the agent to draft one, then make it yours. Anyone on the team can run it.
#
DO THIS
EXPECT THIS
1
Open the form on a phone
It loads and fits the screen
2
Submit it empty
An error shows next to each required field
3
Enter phone as +27 82 555 0101
Accepted
4
Book leave Fri to Mon
Counts 2 working days
5
Submit a valid request
Confirmation shown, email arrives
Write it once. Run it before every release.
Day 54 / 100 · Quality & testing
Stuck? Changethe approach.
Sometimes the agent goes in circles. Repeating “try again” rarely helps. Spot the signs early and change the conversation.
Signs it's looping
Same fix attempted three times.
The error keeps changing, never goes.
Workarounds stacked on workarounds.
“This should work now.” It doesn't.
Five Ways Out
Rewind
Back to the last version that worked.
Explain first
“Explain the cause. Don't fix yet.”
Three options
“Give me three different approaches.”
Fresh session
Clear, with a short summary of the problem.
Shrink it
Reproduce it in the smallest possible case.
Three failed fixes? Stop and rethink.
Day 55 / 100 · Quality & testing
Reproduce. Report. Repair.
Good bug reports get good fixes. Whether you're telling the agent or a developer, give it the same four things.
01
Reproduce
Make it happen again on purpose. Note the exact steps.
02
Collect
The full error, the console, the logs, a screenshot.
03
Report
What you did, what you expected, what you got.
04
Verify
Repeat the steps after the fix, then add a test.
Steps. Expected. Actual. Full error.
Day 56 / 100 · Quality & testing
Fixed one thing. Broke another.
A regression is something that used to work and now doesn't. Agents cause them often because changes spread further than you asked.
Why agents cause them
One fix can touch shared code used elsewhere.
It doesn't remember why something was done a certain way.
It tidies things you didn't ask it to.
Four Defences
Keep the tests
Every test stays and runs every time.
Re-run the script
The full manual script, not just the fix.
Small commits
So you can see exactly when it broke.
Fence it in
“Only change files related to the export.”
Every bug fixed gets a test that stays.
Day 57 / 100 · Quality & testing
Make it review itself.
You can't review code like a senior developer yet. The agent can get close, if you ask the right questions in a fresh session.
Five Review Prompts
Security
“Review this change for security issues.”
Edge cases
“What happens with empty, huge or strange inputs?”
Critique
“What would a senior developer criticise here?”
Waste
“Is anything unused, duplicated or overcomplicated?”
Explain
“Explain this change to a new team member.”
Fresh eyes. Specific questions.
Day 58 / 100 · Quality & testing
Same behaviour. Cleaner code.
Refactoring means reorganising code without changing what it does. It keeps a growing project understandable, for you and for the agent.
Time to refactor when
One file is growing past a few hundred lines.
The same code is copied in three places.
You can't find where things happen.
The agent keeps breaking unrelated parts.
01
Tests first
Cover what it does now.
02
Commit
A clean save point.
03
One change
Split, rename or merge.
04
Run tests
Still green? Commit.
Tests first. Tidy second. Features third.
Day 59 / 100 · Quality & testing
Built for everyone.
Accessible software works for people using keyboards, screen readers, zoom or a phone in bright sun. Agents skip it unless you ask.
Tab through every control, no mouse
Text contrast is easy to read
Every field has a label
Every image has alt text
Works zoomed to 200%
Buttons are real buttons
Ask For It
Review this page for WCAG 2.2 AA issues. Fix what you can and list what needs a human to check.
Tab through it. Zoom it. Hear it.
Day 60 / 100 · Quality & testing
Done is a checklist, not a feeling.
Agree what “done” means before you start, write it in CLAUDE.md, and hold both yourself and the agent to it.
Does what the brief asked, demoed
Happy path and edge cases tested
Automated tests pass
Diff read, only expected files
No secrets in the code
No personal data in logs
Works on a phone
Keyboard and labels checked
README updated
Committed and pushed
Agree it first. Tick it every time.
Module 7Guardrails & securityDays 61–70
Day 61 / 100 · Guardrails & security
Leaked a key? Rotate, don’t delete.
Once a secret has been seen, deleting it doesn't un-see it. The only fix is to make the old key useless. Act in this order.
Revoke
First · Minutes
Kill the old key in the provider's dashboard.
Replace
Second
Issue a new key. Update .env and the host.
Review
Third
Check usage logs for anything you didn't do.
Remove
Fourth
Clean it from Git history if needed.
Record
Last
What happened, and what stops it next time.
Revoke first. Clean up second.
Day 62 / 100 · Guardrails & security
Allow the boring. Deny the dangerous.
Day 26 was answering prompts one at a time. Now set standing rules in your project settings, so safe things flow and risky things can't happen.
Allow the boring. Deny the dangerous. Ask about the rest.
Day 63 / 100 · Guardrails & security
Read the red and the green.
A diff shows every line added (green) and removed (red). You don't need to understand every line. You need to spot the ones that shouldn't be there.
A Diff Worth Stopping For
function saveLeave(user, dates) {
- if (!user.canApprove) return deny();
+ // if (!user.canApprove) return deny();
+ // TODO: re-enable after testing
return store(dates);
}
Stop and ask when you see
Files you didn't expect to change
Deleted or skipped tests
Security checks commented out
New packages or network calls
Anything near .env or keys
Large deletions
Summaries tell stories. Diffs tell the truth.
Day 64 / 100 · Guardrails & security
Not every package is what it seems.
Day 37 was about packages you don't need. Today is about packages that can hurt you, and one risk that's special to AI agents.
Typosquats
Lookalikes
A name one letter off a popular package, waiting for typos.
Made-up names
Ai-Specific
Agents sometimes invent package names. Attackers register them.
Abandoned
No Longer Fixed
No updates in years. Known holes stay open.
Poisoned updates
Supply Chain
A trusted package ships a bad version.
Defences: run npm audit or pip-audit, turn on GitHub's Dependabot alerts, commit your lock file, and keep “ask before installing” in CLAUDE.md.
Check the package page before you install.
Day 65 / 100 · Guardrails & security
Personal data is borrowed, not owned.
POPIA's eight conditions apply to your side project and your internal tool, not just big systems. Organisation-wide policy sits in the AI Enablement playbook.
Accountability
01
Someone owns compliance
Processing limitation
02
Lawful, minimal, with consent or a reason
Purpose specification
03
Collect for a clear, stated purpose
Further processing
04
Don't reuse it for something unrelated
Information quality
05
Keep it accurate and up to date
Openness
06
Tell people what you collect
Security safeguards
07
Protect it; report breaches
Data subject participation
08
People can see and correct theirs
Fake data for building. Real data only with a reason.
Day 66 / 100 · Guardrails & security
Every input is guilty until checked.
Anything a user can type, upload or send can be wrong, huge or hostile. Check it on the server, every time, before you use it.
Check Five Things
Type
A number is a number, a date is a date.
Length
Names under 100 characters, not 10 million.
Format
SA ID is 13 digits; email looks like email.
Range
Leave days between 0.5 and 30.
Files
Check type and size; never trust the name.
Three habits
Allow what's valid. Don't just block what's bad.
Use safe database queries, never text glued together.
Escape anything you show back on a page.
Allow what's valid. Check it on the server. Every time.
Day 67 / 100 · Guardrails & security
The locks beginnersleave open.
Day 34 covered how login and permissions work. These are the mistakes that show up again and again in AI-generated apps.
Checks only in the browser
Other users' records by changing the URL
Passwords stored as typed
Admin pages protected by a “secret” URL
Default admin / admin accounts left in
No limit on login attempts
Sessions that never expire
Reset links that work more than once
If it's not checked on the server, it's not protected.
Day 68 / 100 · Guardrails & security
When the content gives the orders.
An agent follows instructions. If it reads text containing instructions (a web page, a file, an issue), it may follow those too. That's prompt injection.
Where it hides
Web pages the agent reads
Files and documents you download
Issues and pull requests from strangers
Emails and tickets
Results from tools and MCP servers
Four Defences
Deny secrets
Block reading .env in settings.
Watch network
Question any unexpected download or upload.
Trusted tools
Only connect MCP servers you trust.
Separate
Read untrusted content in a locked-down session.
Treat what it reads as data, never as orders.
Day 69 / 100 · Guardrails & security
A backup you haven't restored is a hope.
Git protects your code. Your data, uploads and settings need their own backups, and a regular test that you can actually get them back.
3
copies of your data
2
different kinds of storage
1
copy somewhere else
The quarterly drill
Restore last night's backup to a test copy.
Open it. Is the data all there?
Time it. Could you live with that?
Write down what went wrong.
Back it up. Restore it. Then trust it.
Day 70 / 100 · Guardrails & security
Ten checks before anything goes live.
Run through this before any vibe-coded tool reaches real users or real data. Ask the agent to check each one, then check its answers.
No secrets in code or history
Leaked keys revoked and replaced
Deny rules for .env and pushes
Every diff read before commit
Packages checked and audited
Only the personal data you need
All input checked on the server
Permissions checked on every request
Backups restored at least once
A fresh-session security review
Check before live. Every time.
Module 8ShippingDays 71–80
Day 71 / 100 · Shipping
A rhythm, not a ritual.
Day 27 made commits a safety habit. Now make Git a routine: the same four moves every session, and messages future you can actually use.
01
Pull
Get the latest before you start.
02
Commit
A save point before the first prompt.
03
Small commits
One working step, one commit.
04
Push
Off your laptop, every session.
Commit Messages
✗
fix
✗
stuff
✓
Add public holidays to leave count
✓
Fix export date format for finance
Pull. Commit. Push. Every session.
Day 72 / 100 · Shipping
Experiment on a copy.
A branch is a safe copy for one change. A pull request asks for it to be checked and joined back into the main version.
main
Always works
branch
leave-export
commits
Small steps
pull request
Review and checks
merge
Back into main
Ask the agent: “Create a branch for this change, commit as you go, and open a pull request with a summary when it's ready.” It can do all of it with GitHub's command-line tool.
Main always works. Everything else is a branch.
Day 73 / 100 · Shipping
From laptop to live.
Deploying is putting your app on the host so real people can use it. On most modern platforms, it's connecting GitHub and pressing go.
01
Connect
Link the host to your GitHub repo (Day 39).
02
Configure
Add the environment variables (Day 35).
03
Deploy
Push to main, or press deploy.
04
Test live
Run your manual script on the real link.
Deploy early in the day, early in the week.
Day 74 / 100 · Shipping
A robot that tests every push.
Continuous integration (CI) runs your tests automatically every time code is pushed. GitHub Actions does this with a small settings file.
The Whole Thing
# .github/workflows/test.yml
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
What it gives you
Tests run even when you forget.
A green tick or red cross on every pull request.
Problems caught before they reach main.
Ask the agent to set it up for you.
Red means stop. Even on a Friday.
Day 75 / 100 · Shipping
Know it's broken before they tell you.
Once it's live, you need to know when it goes down, when it errors and whether anyone uses it. Three simple kinds of monitoring.
Uptime
Is It Up?
Checks the site every few minutes.
Alerts you if it stops answering.
Errors
Is It Failing?
Collects crashes and error messages.
Shows how often and where.
Usage
Is It Used?
Which features get used, and how often.
No personal data needed.
One alert. One owner. One action.
Day 76 / 100 · Shipping
Every release gets a number.
Semantic versioning uses three numbers: major, minor and patch. Anyone can see how big a change is from the number alone.
1.0.0
First release
1.0.1
Patch: a bug fixed
1.1.0
Minor: a feature added
2.0.0
Major: something changed that could break
With every release
Bump the number.
Tag it in Git.
Add a line to the changelog.
Show it in the app's footer.
Number it. Note it. Tag it.
Day 77 / 100 · Shipping
The fastest fix is going back.
When a release breaks, get users back to the last working version first. Find the cause afterwards, calmly.
Three Ways Back
Host redeploy
Most platforms can redeploy the previous version in a click.
Git revert
Undo a specific commit, then deploy.
Feature switch
Turn the new feature off without redeploying.
The hard part: data
Code rolls back easily. Database changes don't.
Back up before any change to the data structure.
Decide in advance: “If X breaks, we roll back.”
Roll back first. Debug second.
Day 78 / 100 · Shipping
Your users are your best testers.
Real people find what your tests never will. Make feedback easy to give, then sort it before you act on it.
Ask
In The App
A small feedback button on every page.
Watch
Five Minutes
Watch someone use it without helping.
Check in
After A Week
Three questions: love, hate, missing.
Measure
Usage
What's used, what's ignored (Day 75).
Sort before acting
Bug: it's broken. Fix it.
Confusion: it works but people get lost. Redesign.
Request: something new. Weigh it against the goal.
Watch, don't just ask.
Day 79 / 100 · Shipping
Future you is a stranger.
In six months you won't remember how it works. Neither will the colleague covering your leave. A short README fixes both.
Readme.Md
# Leave form
What it does and who it's for
## Run it locally
npm install, then npm run dev
## Settings needed
Names of env variables, never values
## Deploy
How and where it goes live
## Owner
Who to call, and their backup
Keeping it true
Ask the agent to draft it from the code.
Read it and fix what's wrong.
Update it in the same commit as the change.
Test it: can a colleague run it from the README alone?
If it's not written down, it leaves with you.
Day 80 / 100 · Shipping
Shipping is the start.
Software goes stale even when nobody touches it. Packages age, people leave, costs creep. An hour a month keeps a tool healthy.
Update packages and run an audit
Restore a backup to test it
Remove access for people who've left
Read the error logs
Check the domain and renewals
Check the monthly costs
Is it still used? If not, retire it
README still true?
An hour a month, or retire it.
Module 9Vibe coding at workDays 81–90
Day 81 / 100 · Vibe coding at work
Show, don't spec.
For product people, vibe coding's biggest win is the prototype: something stakeholders and customers can click, days before any developer time is spent.
Clickable mockup
Hours
Screens that link together. No real logic.
Answers: “Is this the right idea?”
Working prototype
A Day Or Two
Real behaviour, fake data.
Answers: “Does this flow work?”
Pilot
A Week Or More
A few real users, with guardrails.
Answers: “Will people use it?”
Prototypes answer questions. They're not the answer.
Day 82 / 100 · Vibe coding at work
Small tools. Real users.
Internal tools are where vibe coding pays off at work: small, specific, used by people you can talk to. As long as someone knows they exist.
The sweet spot
Used by one team
Replaces a spreadsheet or manual step
No customer data, or read-only
Survivable if it's down for a day
The Tool Register
Tool
What it does, in one line
Owner
A named person, plus a backup
Data
What it touches, and where it lives
Users
Which team, roughly how many
Tier
Green, amber or red (Day 3)
Build it in the open. Put it on the register.
Day 83 / 100 · Vibe coding at work
Partners, not gatekeepers.
Developers and vibe coders are better together. You bring the problem and the users. They bring the judgement about building it to last.
What you bring
Deep knowledge of the problem
Direct access to users
Fast, cheap prototypes
Real examples and test cases
What they bring
Architecture that scales
Security and edge cases
Knowledge of existing systems
Code that others can maintain
Bring a prototype and a question, not a demand.
Day 84 / 100 · Vibe coding at work
Hand over the why, not just the code.
When a prototype becomes a real product, engineers may keep your code or rebuild it. Either way, what they need most is context.
The problem and who has it
The prototype link and repo
What's real and what's faked
Known shortcuts and risks
Your CLAUDE.md and key prompts
Test cases and edge cases found
What user feedback said
What data it touches
Your prototype is the spec. Your notes are the gold.
Day 85 / 100 · Vibe coding at work
Agree the rules before the mess.
Once several people are using agents on shared code, you need shared rules. Keep them short, and keep them where the work happens.
Five Team Rules
Review
Every AI change reviewed by a human
Tests
New behaviour comes with tests
Context
Each repo has a shared CLAUDE.md
Data
No customer data in prompts
Tools
Only approved tools and accounts
Where rules should live
In CLAUDE.md, so the agent follows them.
In the pull request template, as a checklist.
In CI, so tests and checks are enforced.
Not only in a PDF on the intranet.
Rules in the repo beat rules in a PDF.
Day 86 / 100 · Vibe coding at work
If the agent wrote it, you own it.
The agent isn't accountable, and it won't answer the phone at 2am. Whoever merges the code owns it: what it does and what happens when it breaks.
Merge = own
Accountability
Whoever approves it into main owns it.
Explain it
Understanding
You can say what it does and why.
Answer for it
Support
You're who gets called when it breaks.
Name a backup
Continuity
Someone else who understands it too.
Can't explain it? Can't merge it.
Day 87 / 100 · Vibe coding at work
Whose code is it, anyway?
Every package you use comes with a licence, and some come with obligations. This is general guidance, not legal advice: ask your legal team when unsure.
Permissive
Mit · Apache · Bsd
Use it freely. Keep the licence notice.
Copyleft
Gpl
Distribute your software, and you may have to share its source.
Network copyleft
Agpl
Obligations can apply even if users only access it online.
No licence
All Rights Reserved
Public on GitHub isn't permission. Don't use it.
Check the licence. Ask legal when unsure.
Day 88 / 100 · Vibe coding at work
Know when to put it down.
Vibe coding is a powerful tool, not the answer to every problem. Stop and reconsider when you see any of these.
It moves or calculates money
Health or safety depends on it
Many systems or customers rely on it
It's under strict regulation (RICA, financial rules)
You can't test whether it's right
Nobody will maintain it
A good product already does it
The spreadsheet is fine
The best code is sometimes no code.
Day 89 / 100 · Vibe coding at work
Know what it really costs.
Day 8 was costs for one person. At work, costs multiply across people, keys and tools, and nobody notices until the invoice arrives.
Seats
Per Person
Plans for each person using agents.
API usage
Per Key
Apps and chatbots calling AI APIs.
Hosting
Per Tool
Every tool on the register costs something.
People time
Per Month
Review and maintenance hours.
Four habits
A spend limit and alert on every API key.
Smaller, cheaper models for simple tasks.
Fresh sessions, not endless ones (Day 30).
One named owner reviews the bill monthly.
Every key has a limit and an owner.
Day 90 / 100 · Vibe coding at work
Freedom within a frame.
Good governance makes the safe path the easy path. This is the vibe-coding slice; the full framework is in the JTC Tech AI Enablement playbook.
Approved tools
What
Which agents and accounts are allowed.
Data rules
What Goes In
What may and may not go in prompts.
Review & ownership
Who
Human review, named owners (Days 85–86).
The register
Where
Every tool, owner and data type (Day 82).
Risk tiers
How Far
Green, amber, red rules (Days 3, 88).
Training
How Well
This playbook, or something like it.
A clear yes beats a quiet no.
Module 10Level upDays 91–100
Day 91 / 100 · Level up
One lead. Many helpers.
Subagents are helpers the main agent can hand a task to. Each gets its own fresh context and reports back a summary, keeping the main session clean.
Reviewer
Read-Only
Checks changes for bugs and security.
Test writer
Focused
Writes tests for what was just built.
Explorer
Research
Maps a codebase and reports back.
Setting one up
Type /agents to create one.
Saved in .claude/agents/ as a file.
Give it a clear job and only the tools it needs.
Parallel work still needs one reviewer: you.
Day 92 / 100 · Level up
Plug the agent into your tools.
MCP (Model Context Protocol) is a standard way to connect agents to other systems: ticket trackers, databases, browsers, docs.
Read
Context
Tickets, docs, designs, data.
Act
Do Things
Update a task, open an issue.
Test
Check
Drive a browser to click through.
Connect safely
Add with claude mcp add.
Only servers from sources you trust.
Least access: read-only where possible.
Never write access to production data.
Connect what helps. Only with the access it needs.
Day 93 / 100 · Level up
Write the recipe once.
A skill is a folder with a SKILL.md file of instructions. Its name becomes a slash command, and Claude can also load it on its own when relevant.
A Skill, Start To Finish
# .claude/skills/release-check/SKILL.md
---
name: release-check
description: Run before any deploy
---
1. Run all tests and report failures
2. Check the diff for secrets
3. Bump the version, update changelog
4. Draft release notes for users
Where they live
~/.claude/skills/ for you, in every project.
.claude/skills/ in a repo, shared with the team.
Old .claude/commands files still work.
Repeated it three times? Make it a skill.
Day 94 / 100 · Level up
Rules the agent can’t forget.
CLAUDE.md is a request the agent usually follows. Hooks are commands that run automatically at set moments, every time, whatever it decides.
Four Useful Moments
PreToolUse
Before a tool runs: block edits to .env
PostToolUse
After an edit: run the code formatter
Stop
When it finishes: run the tests
SessionStart
At the start: load today's context
Handle with care
Hooks run with your permissions.
Read any hook before you copy it.
Keep them fast, or every step slows down.
CLAUDE.md asks. Hooks enforce.
Day 95 / 100 · Level up
Big projects are many small ones.
Agents struggle with a whole large project at once. They do well with a written plan, clear parts and one slice at a time.
A written plan
Docs/Plan.Md
Goal, milestones, decisions. The agent reads it each session.
Clear parts
Modules
Separate folders by purpose, each with its own CLAUDE.md if needed.
Tests as rails
Guardrails
The bigger it gets, the more the tests keep it honest.
Milestones
Slices
Each one usable and demoed before the next.
One task
Per Session
Fresh context each time (Day 30).
Regular reviews
Fresh Eyes
A review session at every milestone.
Write the plan down. Build one slice at a time.
Day 96 / 100 · Level up
Decide the shape before the details.
Architecture is how the parts of a system fit together. A few simple principles make everything that comes after easier to change.
Five Principles
Separate
Screens, logic and data in different places.
One job each
Every part does one thing well.
Clear borders
Parts talk through defined APIs.
One truth
Each piece of data lives in one place.
Keep it boring
Proven, simple tools over fashionable ones.
Ask For Options
Propose two ways to structure this app. For each, list the trade-offs for a small team maintaining it for three years.
Boring. Simple. Separated.
Day 97 / 100 · Level up
Find your way round any codebase.
Sooner or later you'll inherit code: a colleague's tool, an open-source project, an old system. The agent is an excellent tour guide.
Get a tour
Map
“Explain the structure.”
Follow a click
Trace
One action, button to database.
Read the tests
Behaviour
They show what it should do.
Ask where
Change
“Where would I change X?”
Check history
Why
git log shows when and why.
Follow one click from button to database.
Day 98 / 100 · Level up
The path is open.
Some readers will stop at useful tools, and that's a fine place to be. For those who want more, here's the ladder, and what moves you up it.
STAGE 1
Vibe coder
Directs the agent, checks the results
STAGE 2
Builder
Reads code, writes tests, reviews diffs
STAGE 3
Contributor
Edits by hand, reviews others' changes
STAGE 4
Engineer
Designs systems, owns quality
What moves you up: one language learned properly, debugging without the agent, basic data structures, and how systems fit together (Day 96).
Let the agent write. Make sure you can read.
Day 99 / 100 · Level up
Don't learn alone.
The tools change monthly. The fastest way to keep up is a mix of reliable sources and people you learn alongside.
Official docs
Source Of Truth
The tool's own docs and release notes.
Peers at work
Show &Amp; Tell
Monthly demos of what people built.
Build in public
Share
Post what you made and what you learned.
Share your setup
Reuse
CLAUDE.md files and skills, swapped.
Be picky about
Viral “I built a startup in an hour” posts
Tutorials more than a few months old
Advice that skips security or testing
Anyone selling certainty
Build. Share. Repeat.
Day 100 / 100 · Level up
100 days done. Now build.
Reading about vibe coding isn't vibe coding. Here's a 30-day plan to turn the playbook into one real, shipped, useful tool.