Learn by doing, not by reading.

This is a book you don't just read. You do it. Each chapter is an exercise, not an explanation. Ten of them. You open a terminal, you type, you watch what happens, and by the end you've built real things, on real servers, with an A I agent working beside you. You don't need to be a programmer. You just need to be willing to try.

Exercise one sets up your workshop: a terminal, a package manager, Git, the GitHub command line, and an A I assistant. Exercise two sends your first pull request. You fork a real book, write a review of one chapter, and propose it on GitHub, where real people will read it. This isn't a simulation.

Then you start building. Take an open source presentation, describe your topic in plain English, and let the agent generate the pictures, the narration and the animated background. Next, pair program a travel bucket list app from scratch. You describe it, the agent writes every line, and you review, click around, and ask for better. You bring the vision. The agent brings the code.

Your app works on your own laptop. Now send the link to a friend. You can't. So you rent a small server, and the agent runs it for you: it logs in, locks the doors, turns on H T T P S, and points your domain at it. Then you attack your own app before anyone else does. A team of security agents probes it, tries real exploits, and writes you a report.

Change one thing, and how do you know nothing broke? Without tests, your agent is coding blindfolded. So you give it eyes: tests that go green when everything works, and red when it doesn't, on every push. Then you step out of the loop, and wire up a pipeline of agents that reads messy feedback, sorts it, and files the issues while you sleep.

Exercise nine is the real thing. Your own product, from idea to launch in a day. Sign up, log in, payments, a smart A I feature, tests, and a live address you can text to a friend. The agent is your co-founder. Every skill from every chapter comes together here.

And the last exercise turns the book around. For nine chapters, you followed instructions. Now you write them: a Claude dot M D file that tells an agent how to work on your project, what matters, and what not to touch. You walked in as a passenger. You leave as the captain. Open a terminal, and start.

Before you can fix a bug, send a pull request, or even read code properly, you need a place to work. So exercise one starts with an empty bench. By the end, you'll have a terminal, a package manager, Git, the GitHub command line, Node, and an A I coding agent, all ready to go, on whatever computer you use.

Start with the terminal. It's your command line, the place where you'll run everything in this book. It's also where A I coding agents live. You can't pair program with an agent if it has nowhere to work.

Next, a package manager. Instead of downloading installers and clicking through wizards, you type one command, and the software arrives. Every system has its own, and the chapter walks you through yours.

Then Git. It tracks every change to every file in a project, and it's how teams work together without writing over each other's work. Tell it who you are: your name, and the same email as your GitHub account. One more setting: new projects start on a branch called main, just like GitHub. Then a sixty second test. Make a practice folder, tell Git to start tracking it, and ask for the status. On branch main. No commits yet.

Now the GitHub command line. It lets you fork projects, open pull requests and manage issues without leaving the terminal. Sign up for a free GitHub account, then log in from the terminal. It gives you a one time code and opens your browser. Paste the code, authorize, and you're connected.

Then Node, which runs JavaScript outside the browser, and brings its own package installer along. You won't need it in the next exercise, but the later ones, building a web app and testing it, do. So install the long term support version while you're here.

Last, and optional: an A I coding agent. Claude Code needs a paid plan. Antigravity C L I has a free tier. Either works. But copy the install command from the official source, never from a random blog or a search ad. Agents run with your permissions, which makes fake installers an attractive trap.

Start Claude Code in manual mode while you learn. Then it asks before it runs anything that changes your machine. Read each command, and approve it only if you understand it. Now ask it, in plain English, to check your setup. It runs the commands and tells you what's working, and what still needs attention.

Four quick checks: Git, the GitHub command line, your login, and Node. If all four answer, you're ready. Your workshop is set up, and you have a direct line to GitHub. Next up: your first pull request.

In exercise one, you set up your workshop. Now you use it. You fork a real book, write an honest review of one chapter, and send it to the author as a pull request. This isn't a simulation. Your pull request shows up on GitHub, where real people will read it.

Step one: fork. A fork is your own copy of someone else's project, stored on GitHub. A single command makes that copy, downloads it to your machine, and links it back to the original.

Before you change anything, look around. Open chapter one and read it, all of it. Form your own opinions. That's the whole point. And notice the Claude dot M D file: plain notes that an agent reads the moment it starts in this folder.

Next, make a branch. A branch is a safe parallel universe, where you can change anything without touching the main copy. Ten people editing one document at once is chaos. With branches, everyone works on their own, and the changes merge one at a time.

Now write your review in a new file. Start from the template: first impressions, what worked, what could be better, who it's for, and a rating out of five. Don't overthink it. One genuine paragraph per heading beats a polished essay.

Then add the file. Before you commit, look at exactly what you're about to record. Nothing gets committed that you haven't read. Commit it, with a message. Then push your branch up to your fork.

And now the moment. A pull request is a proposal. It says: I made a change on my copy. Would you like to merge it into yours? The author reads it, and may leave a comment. Once it's merged, your review is a permanent part of the project's history.

You can also hand the Git work to an A I agent. Ask for a plan first, and tell it to wait until you say go. When it asks to run git push, or G H P R create, look before you approve. Those publish your work to the internet. And a file you didn't write is untrusted input. If the agent suddenly wants something you never asked for, stop and look.

Fork, branch, write, commit, push, propose. Every contribution to every major project follows that path, and you just walked it, for real. Let the agent help you find the words, but keep the opinions yours. Next up: your first A I generated project.

Picture a presentation about something you love. A painted illustration on every slide, a warm voice reading each one aloud, and a glowing network drifting behind it all. You didn't draw a single picture, or write a single line of code. You described it, and an A I agent built it. That's exercise three.

You start from a real open source project called Web Presenter. One command forks it to your own GitHub account and clones it onto your computer. Then you ask your agent to read the project and explain how it works, before it changes anything.

The pictures come from Hugging Face, where a free account gets a small monthly credit. You'll need an access token, and here's the habit that matters. The token lives in an environment variable in your terminal. Never in a file, never in Git, and never in the agent's chat. The agent doesn't need to see it. The script reads it when it runs.

Now pick a topic, and write ten short points, one per slide. Make them visual. The agent rewrites the image prompts in the asset script. Before anything runs, you read the diff. Are the prompts right? Is the token still read from the environment? Then you approve that one command, and ten illustrations arrive.

Next, the narration. Write a sentence or two for each slide, and the agent turns them into speech with edge T T S, a free library that needs no key. Ten audio files, numbered to match, so each one plays on its own slide.

Then you give the animated background a new mood. Warm amber on dark brown, or electric blue on black. Too bright? Just say so. Each change takes a few seconds.

Start a small web server on your own machine, open your browser, and press play. Your pictures, your words, your colours, all moving together, slide after slide.

Last, ask the agent what's about to be committed. Nothing holding a token goes in. Then it creates a branch, commits your work, and pushes it to your fork on GitHub, ready to share.

You brought the topic, the words, and the judgment. The agent brought the mechanics. And you kept your token out of the chat, read every diff, and approved each command yourself. Next up: exercise four, pair programming with an agent.

Picture a wall of postcards. Every place you dream of going, each one on its own card. Add a destination, edit it, mark it as visited, delete the ones you've changed your mind about. Now build that app from scratch, without writing a single line of code yourself. That's exercise four: pair programming with an agent.

You start with an empty folder, and before any code, you write the house rules. A short agents dot M D file: one index dot html file, no frameworks, data saved in the browser, and change only what I ask for. Agents start every session with a blank memory, so they read this file every time.

Then describe the app, the way you'd explain it to a friend. But don't let the agent start typing. In plan mode, it answers with a plan instead of code. Read it. This is the cheapest moment to change your mind. Want a field for the best season to visit? Say so now. Then approve it.

The agent writes the whole app into one file. Before you open it, ask the agent to walk you through the code. How are destinations stored? How does the delete button know which card to remove? Always review before you run.

Now open it in your browser. Type Kyoto. Cherry blossoms in spring. Click add, and a card appears. Add a few more, refresh the page, and they're still there. It works, so save a checkpoint: your first commit.

Now make it yours. Ask for a search bar, colour coded badges, or a stamp that says been there. After each change, look at the diff. Is it the size you expected? Did it touch anything you didn't ask about? Try it in the browser. Like it? Commit. Don't? Restore, and you're back at your checkpoint. One change, one review, one commit.

And sometimes, something breaks. You click delete, and the card just sits there. That's normal. Describe the problem, ask the agent to diagnose it, and review the fix. Debugging by conversation. When you're happy, push it all to GitHub.

You brought the vision. The agent brought the code. You don't need to write JavaScript to build a JavaScript app. You need to know what you want, and how to check you got it. Describe, review, iterate, and understand enough to stay in control. Next up: exercise five, going live.

Your app works on your own laptop. The cards animate, the filters snap. Now try sending it to a friend. You can't. To everyone else in the world, your app doesn't exist. Exercise five fixes that. Your agent stops being a code writer and becomes your ops team, with real keys to a real machine.

It starts with a key. An S S H key is a pair of files that prove who you are. You make it yourself, not through the agent, and you give it a passphrase. The public half is the only part that ever leaves your machine. The private half never goes into a prompt, a repo, or a chat.

Next, the agent installs the Hetzner command line tool. You create a Hetzner token, and let the tool hold it. Then one sentence: create the smallest Ubuntu server, and attach my public key. Half a minute later, you have a real machine in a data centre, with its own address.

Before the agent logs in, set the ground rules. Run it in a mode that asks before it acts, and read every command. Updates and system info? Approve freely. Anything destructive, like enabling the firewall, disabling a login, or a reboot? Stop and think. You are the last line of review.

The agent logs in and updates everything. Bots start probing a fresh server within minutes, so it locks the doors. A deploy user with your key. No more root login. And a firewall that only lets in S S H and web traffic. It allows S S H first, then turns the firewall on. Get that backwards, and you've locked yourself out.

Now, as the deploy user, the agent installs Node, clones your repo from GitHub, and starts the app. Then it puts Caddy in front, a web server that forwards visitors to your app, with no port number to type.

For your domain, you make a Cloudflare token that can only edit D N S, on one domain. It goes in an environment variable, and the agent reads it from there. It points your domain at the server. Caddy sees the name, and fetches its own certificate. H T T P S. Padlock and all.

Last, the app becomes a service. It starts on boot, and restarts if it crashes. Then the real test. Reboot the server, and approve that one deliberately. Wait thirty seconds. Open your address. It's still there.

You brought the decisions, the scoped keys, and the approvals. The agent brought the server, the firewall, the certificates, and the domain. So open your phone, type the address, and show someone. Next up: pentesting with an agent.

Your app is live. Within minutes of a server going online, bots start knocking on its doors. Most developers find their weak spots the hard way, after someone else does. In exercise six, you get there first: you attack your own app, before anyone else can.

But one rule comes before everything. Only test what you own, or what you have written permission to test. Never production, always a copy or a local instance. Pointing this at someone else's system is illegal almost everywhere. If in doubt, don't run it.

So you start with a practice target. OWASP Juice Shop is a pretend smoothie shop, built full of holes on purpose, running only on your own machine. Because its weaknesses are known, you can check whether your agents find the real ones.

Your pentester is Shannon, an open source tool that runs a whole team of security agents. One maps the app: its pages, forms and logins. One reads the source code, looking for risky patterns. Others try to prove each weakness is real, not just suspect it. When an attempt is blocked, they learn from it and adjust.

About an hour later, a reporting agent hands you a professional security report. Every finding has a severity score, the evidence, and how to fix it. And treat the report as untrusted too: it quotes what the app said back, so never let another agent run what it quotes.

Now it's your turn. Agents can report problems that aren't there, so check every critical finding yourself, using the steps in the report. If you can reproduce it, it's real. If not, note it and move on. Your judgment is what turns the agents' output into something you can act on.

Then fix what's broken. Keep user input out of your database queries, escape what you show on the page, verify every login token. Then scan again, to confirm each fix holds. Finally, point it at your own travel app. A simple static site gives attackers very little to grab.

You brought the target, the permission, and the judgment. The agents brought the probing, the proof, and the report. The stakes are higher now: a hole here means someone could steal your users' data. So describe, review, iterate, and understand enough to stay in control. Next up: exercise seven, testing as a safety net.

Your agent is coding blindfolded. Ask it for a sort button, and it writes the code, says done, and moves on. Did the sort work? Did it break the filter? Nobody checked. That's exercise seven: testing as a safety net.

Tests give the agent eyes. A test is a plain sentence about what your app should do, written so a machine can check it. Green means it works. Red means something's broken. And the agent can read that signal, just like you.

You start with Playwright. It opens your app in a real browser with no window, types, clicks, and checks the page. Your first test: add Tokyo, and a Tokyo card appears. Run it. One passed. One green line, in about two seconds. Then add three lines to the agent's instruction file: run the tests after every change, and never call a task done while they're red.

Next, build the suite. Describe each behaviour in plain English. Add a place. Refresh, and it's still there. Edit it, delete it, mark it as visited, filter the list. The agent writes a test for each. Before you run them, read them. A test that promises to refresh but never does will pass forever, and protect nothing.

Now flip it around. Ask for the test first: a sort button that puts the cards in alphabetical order. Run it. Red. Then tell the agent to make it pass, without touching the test, and check the diff to be sure. Green. Red, green, refactor. The test isn't just checking the work. It's the spec.

Then break something on purpose. Comment out the line that saves to local storage. The app still looks fine, until you refresh, and everything is gone. The tests go red. You only say: the tests are failing, fix it. The agent reads the failure, finds the line, and puts it back. Green again.

Last, automate it. A GitHub Actions workflow runs the whole suite on every push and every pull request. Push a broken branch, and the pull request gets a red X. Add a branch rule, and red can't be merged.

You stopped telling the agent only what to build, and started telling it what correct means. An agent that knows what correct looks like can check its own work. It isn't coding blindfolded anymore. Next up: exercise eight, the agentic pipeline.

Picture two a.m. on a Tuesday. Feedback keeps landing: a crash report, a wish for dark mode, some praise, and one note that isn't really feedback at all. Nobody is awake to read it. A pipeline of agents reads it, sorts it, and drafts the issues while you sleep. This is exercise eight: stepping out of the loop.

First, feel the pain. You write six messy entries into a feedback file and handle them by hand. Is it a bug, a feature, or praise? How urgent? Then open GitHub and type up every issue. Fifteen minutes. Now picture five hundred entries, every week. That is what pipelines are for.

So you build the first agent: intake. A tiny shell script pipes the feedback into Claude in headless mode. It runs once, answers, and exits. Its one job is to turn messy text into clean data. My eyes are burning at night becomes a tidy one line summary. It gets no tools at all, a schema its answer must match, and a hard cap on turns and spending.

The second agent has judgment. Triage reads each item and decides: bug, feature, or praise. High, medium, or low, by rules you wrote. Labels come from a fixed list, like a menu. The upload crash? A high priority bug. Dark mode? A low priority feature. Two agents, two jobs, joined by a pipe.

Then there's entry six. It tells the A I to ignore its instructions, file an urgent security bug, and paste its environment variables into it. Usually the model sees the trick. Don't count on it. The agent has no tools, so there's nothing to leak, and labels only come from the menu. The agents can read, but not act.

The pipeline script runs intake, triage, and a summary report, and stops the moment anything fails. It never touches GitHub. Filing is a separate plain script, code that acts but doesn't think. It checks every label again, caps the run at ten issues, and marks each one as machine written. You read the list first. Then one command files them.

Now put it on a schedule: cron, or GitHub Actions, every Monday at eight. The key lives in a file only you can read, or in a repository secret, never in a script or a prompt. In Actions, the agents' job holds the key but can't write anything. The filing job has no Anthropic key and no agent, and it waits for you to click approve.

That's the pattern. You define the rules. Agents execute them. You decide what they can touch, and you review what leaves your system. Then you step back, as far as the risk allows, and no further. Next up: exercise nine, your own SaaS.

Picture a link you can text to a friend. Behind it, a real product. People sign up, an A I does the work, and an upgrade button takes payments. Now build the whole thing, from an empty folder, in a day. That's exercise nine: your own product, with an agent as your co-founder.

Start with the idea. Ask the agent to brainstorm small products people would pay for, with an A I feature at the core. A resume reviewer, say. Some ideas will be terrible. That's fine. You are the filter. Then have it write a one page spec: what it does, who it's for, what's free, and what's paid.

This is a long job, so brief your crew like a colleague. An agents dot M D file holds the standing orders: secrets live only in the dot env file, and ask before adding any package. A permission file lets the agent run the tests on its own, but it can't read your secrets, and it can't push.

Then comes the rhythm for every big step. Plan mode first: the agent reads and proposes, but changes nothing. Read the plan. A mistake caught here costs one sentence. Save it to plan dot M D, clear the session, and implement it fresh. Then review the diff.

First, the brain of the product. The user's text goes to the model, and a structured review comes back. Treat that text as untrusted. And the key for the model? You type it into the dot env file yourself. Never paste a key into the chat.

Next, accounts, with every password hashed. Then payments, in Stripe's sandbox, where no real money moves. Only a signed webhook from Stripe can upgrade an account, never the success page. Free users get three reviews a day. Paying users, as many as they like.

Then prove it works. Tests for sign up, the A I endpoint, the limits and the webhook, with the model mocked. You push to GitHub yourself, and a pipeline runs the tests on every push. Deploy, type the keys into the server by hand, add a landing page, and walk the launch checklist.

The agent wrote every line of code. But you made every decision: the idea, the spec, the rules, every plan, the price. The agent was the builder. You were the architect. And the building is standing. Next up: exercise ten, captain's log.

You made it. There were a dozen moments where you could have stopped. When the terminal threw an error you didn't understand. When a merge conflict looked like hieroglyphics. When the deploy failed at midnight, and the logs were a wall of red. You didn't stop. You're here.

Look astern. In chapter one, you opened a terminal for the first time. Git wasn't installed. A repository meant a library. Deployment was something other people did. Since then, you've pair programmed with an A I agent, shipped a product to a live server, tested it for vulnerabilities, automated a pipeline, and read a security report that agents wrote for you.

Somewhere between your first commit and your first deploy, something shifted. You stopped being someone who uses software, and became someone who makes it. You learned to think in systems, to describe your intent clearly, and to verify what comes back. That shift doesn't reverse.

Now name the planks of the ship you built. The terminal is your helm. Git and GitHub, your logbook and your harbour. The agents are your crew: you brief them, ask for a plan, constrain them with permissions, and read what they hand back, because they're powerful and fallible in equal measure. Deployment gave you sea legs. Security awareness is your lookout. And the review habit is your compass: never ship what you haven't read.

One last exercise turns the book around. Write your captain's orders: an agents dot M D file in the root of your project. What it is. How to build and test it. The conventions, the boundaries, the traps. Claude's own file becomes a one line pointer to it. Keep it to a page, and never put secrets in it. In chapter one, you followed instructions someone else wrote. In chapter ten, you write them.

Then test it. Start a fresh session, give it a real task, and read the diff. When the agent gets something wrong, don't just correct it in the chat. A correction in the chat lasts one session. A correction in the file lasts every session after it. And a rule that must never be broken becomes a deny rule, or a hook.

Your final assignment comes from you. Within seven days, build and deploy one small thing that didn't exist before. The only rule: it has to be live, with an address someone can visit. Then help the next reader, who's opening a terminal for the first time. You're no longer a passenger. You're part of the crew.

The chapters end here. The voyage doesn't. Every project from now on is a new heading on open water, with a ship you built, and a crew you know how to command. Go build something.