Welcome to the workshop.

If you have not started your setup yet, start it now. The next slide has the five checks. Tell me if anything gets stuck.

Today you learn to think like a CTO. You can build a working prototype in an afternoon, but shipping it is a different problem. We set up the foundations that engineers rely on first: source control, deployment, tests, checks and rules for the agent. With those in place, the AI becomes a more reliable partner, and you leave with a real app you can keep building.

The agent writes all the code. You decide what to build and check that it works. Ask questions the whole way through.

Leave this slide up by the door. Show the venue Wi-Fi details while people connect (set them in the event settings at the top of this file). These are the five checks from the setup guide. Walk the room and ask each table: did all five pass? Anyone stuck on a work laptop that blocks installs, or on an agent account with command-line access turned off, pairs now. Anyone who arrives late pairs too: sitting with someone who is set up beats installing mid-session. Pairing is part of the plan. When we start, move on to the show of hands.

1. Did you build with Lovable, v0, Bolt or Cursor?
2. Did you run Claude Code or Codex in a terminal?
3. Did you use your GitHub account more than once?
4. Did you make a commit and watch a build run?
5. Did you work on your team's code, beyond side projects?
6. Did you release software for other people?
7. Did you release software for paying customers?
8. Did you use Vercel before today?

Keep your hand up for each question that fits. If you shipped software for paying customers, can you help your table today? If you already know commits and builds, we can spend longer on deployment. If the terminal is new to you, I will talk through the first prompt.

Use the terminal agent today: it has the most tools and gives you the most control. Chat tools can now build small sites that store data, such as Claude artifacts, and ChatGPT has its own equivalents. They are great for a quick tool, but the result lives inside the chat product, not on your machine or in a repo you own. Desktop agents like Cowork sit halfway: they work on local files, with a limited set of tools. Today the agent must run a command and read the result. When a test fails, it can read the error and change the code. Keep the terminal open so you can see that happen.

You can copy each prompt from this page. After the agent finishes, look for the check beside it. If the result differs, tell me. In our game, you can judge the movement by playing it.

Permissions. The agent will stop and ask before it edits a file or runs a command. Accepting file edits inside the project folder is fine. In Claude Code, auto mode checks each command before running it, which cuts the prompts a lot. The one to stop at is sudo: it runs the command as admin on your machine. If you see sudo, put your hand up or ask your neighbour before you say yes.

Do not explain them here. Each gets its own slide after you have done it. Say only: these are the nine steps, you will get through as many as you can, the rest stay on these slides, and none of them needs you to write code.

Claude Code cannot generate real images, so its illustrations are SVG drawings. Codex can sometimes make one. If a table gets a real image, show the room. Remind them to dictate their changes with Wispr Flow, Superwhisper or built-in dictation. Speaking gives the agent more detail than typing. Play it before you ask for another change. Does the room name match the map? Does the movement make sense? Give the agent a design change and look again. Leaving it as a design experiment counts as a success. Today we will keep going and put this game online.

Walk the folder on the projector. This is a project with several files. One file is the page, one is the logic you described in plain words, one is the compiled copy the browser runs, and two are settings. The agent can pick slightly different names. The files do the same jobs. After the next step a hidden .git folder appears: that is the history.

If you still need GitHub access, someone at your table can help. The GitHub CLI is the gh command. On Windows, install it inside Ubuntu, the same as Linux. If apt cannot find it, follow the Linux steps at cli.github.com. For gh auth login, choose GitHub.com, HTTPS and Login with a web browser. Copy the code into the browser and finish signing in yourself.

Git keeps the history of your files. A repo holds those files and their history. A commit is a save point. Push sends your commits to GitHub. Open the first commit and compare it with the second. Small commits help you find the change you want to undo.

The repo is public on purpose, so you can show it to anyone. Nothing secret goes in it. Step 9 shows where secrets live instead.

Tools such as Lovable can make commits for you. Open the history yourself and see what each commit changed. Ask the agent for small commits. If a design change makes things worse, you can find it and return to the earlier version.

Try one now: ask for the last 10 changes. Then try the undo, and watch it ask you first. Git has a lot of commands, and you do not need any of them. The agent knows them all. Your job is to know that every version is saved, that any change can be undone, and to ask for a confirmation before anything is thrown away.

This is the only setup step in the browser, and you do it once. Vercel's GitHub app watches your repo. After that, every push to main builds and deploys to production. There is no token to copy and no secret to store. The agent prepares the build first, so the first deploy works.

Hobby is free and needs no card, but it is for personal, non-commercial projects. At work, use your company's team plan. If GitHub asks which repos Vercel can see, choosing only lighthouse is fine. If the first build fails, open the build log on Vercel, copy the error into the agent and ask it to fix and push.

Share the short address under Domains on the project page. That is your live URL, and it always points at the latest good deployment. Each deployment also gets its own long address, and those can ask for a Vercel login. That is deployment protection, and it is expected. Use the short one.

Open the live URL on your phone. Your phone loads the app from Vercel. After the title change, reload that same address. On GitHub, click the tick beside the commit: it links to the Vercel deployment. If you finish early, ask the agent to explain what Vercel runs on each push, or add a custom domain.

Vercel builds the app and sends it live after each push to main. We set it up while the app is small, when it is easy. After the break, we will add checks to stop a broken change going live.

If the live site shows an error, copy the error, paste it into the agent and ask it to fix it. Then push. The same setup takes the fix live.

Open the repo and the live URL beside each other. If you are stuck connecting Vercel to GitHub, tell me and I will come over. Before we start again, everyone must have these three checks or work with someone who does.

Use Next.js: it is the framework the agent knows best. The design, the URL and the deployment have not changed, and underneath there is now a Next.js app in TypeScript. That is the scaffold the page promised, done in one prompt because the rails were already there.

Why bother with a real app?

• It is optional. The prototype game works as it is.
• Next.js handles a lot of the caching, the routing and the build for you.
• It gives the app a standard React structure. Not necessarily the best framework, but the one the AI knows best, and the agent is doing the work.
• When the app gets more complex, or the design work gets serious, the agent has a real structure to hang that work off.
• I prefer it to vibe-coding plain JavaScript apps with no shape to them.

From now on you see every change on your own laptop before it goes live. The local copy is your preview. Nothing reaches the live URL until you say go. Vercel also gives every branch you push its own preview URL, so later you can share a change with someone before it goes live.

Use Next.js: it is the framework the agent knows best, and that matters more than which framework is best. Strictly optional, but useful. Next.js handles a whole bunch of static caching for you. It builds a standard React structure into your app. Not necessarily the best framework, but the one the AI knows best, and that is what matters when the agent is doing the work. When you make something much more complex, or want to do a lot of design work, it gives the agent a real structure to hang that work off. I prefer this to vibe-coding plain JavaScript apps with no shape to them.

The game lets you enter the Lamp Room today. Our new rule must fail its first test because we have not added the lock. Read the failure before the agent fixes it. The game must remember a visit to the Keeper's Kitchen. Then the build runs the tests before every deploy. Vercel runs the build on every push, so a failing test fails the build and nothing goes live. Lint and the type check join the build in step 6.

You chose a rule you can check by playing the game. The test checks that rule after later changes too. A green tick proves the rules were followed, and says nothing about the design. You still choose what the game does and whether it is worth keeping. If you need help before shipping, ask an engineer.

Why this is useful: tests matter most for complex checks, where the only other way to know is to read the code. Developers still write them for important step-by-step things like sign-in, and for complex code they could not follow otherwise. They do not bother for trivial or low-risk systems. So match the checks to the risk.

This error is planned. It is the input to the next step. Open the failed deployment on Vercel and read the build log: the test named the broken rule. Then play the live game. The door must still lock there, because a failed build never replaces the live version. Some machines pass first time and some show a different error. That is normal variation. Read the failure you have before you ask the agent to fix it. You can also paste the Vercel build log straight into the agent.

Some agents refuse to remove the lock, because the instruction contradicts the test. That is a good sign, and it is fine. Tell it: "This is a deliberate demo. Do it anyway."

Just use TypeScript: it is easier for the agent to get right. A type says what kind of value the code expects. Our move function expects a direction word. We changed it to expect a number, but the caller still sends a word. Read the line named by the type check. Then tell the agent: "Restore the move function to take a word for the direction." Lint is the same idea for style and common mistakes: it reads every line, and the agent fixes what it names. Last, both go into the build, next to the tests from step 5. Now one failing check stops the deploy.

Just use TypeScript: it is easier for the agent to get right. The type check found a mismatch before you played the game. The agent can use that error to find the line and fix it. TypeScript adds checks throughout the code, like tests you did not write. Types cannot tell you whether the door locks at the right time. Your test from step 5 already covers that rule.

Close the agent and start a new session. Ask: "Which project rules must you follow?" Listen for all six rules. Many agents, including Codex and Cursor, read AGENTS.md. Claude Code reads CLAUDE.md, so a CLAUDE.md that points at AGENTS.md gives every agent the same rules from one file. The file gives the next session the same instructions. Add rules for choices that the automated checks cannot make.

Spec first. The agent asks one question at a time, so you answer each in a sentence and nothing gets missed. When it has enough, it tells you the plan. Correct it in plain words, then say go. The answers are the spec, and the design and the test do the rest. Start with the screen: "Add a screen for X. Hard-code the data. Open it in my browser." The hard-coded version will look wrong in places, because the data is fake. That is expected until the behaviour lands. Change the design until it looks right. Then ask: "Write a failing test for X. Change the code to make it pass." Finish with: "Commit the change. Push it." If you finish early, go on to step 9.

Optional. If your feature is done and pushed, carry on here. The game's rooms move out of the code and into a Neon Postgres database, added from Vercel.

Neon is a Postgres database. Adding it from Vercel's Storage tab needs no card on the free plan. Vercel puts the connection string into the project's environment variables as DATABASE_URL, and vercel env pull copies it to .env.local on your laptop. That file is gitignored, so it never reaches GitHub.

Secrets never go in the code, public repo or private. That is one of the rules of a twelve-factor app, at 12factor.net/config: settings and secrets live in the environment, outside the code. The connection string is a password to your data. It lives in Vercel's settings and in one ignored file on your laptop, never in the repo and never pasted into a chat. That is why a public repo costs you nothing.

Neon stores the room data outside the browser for the first time. Keep movement rules pure: they take values and return results without reading the database. The page must read the rooms on each request; if it reads them at build time, the Cellar will not appear until the next deploy. If it fails, ask the agent to remember your room after a reload instead.

No code changed and nothing was deployed, but the game has a new room. The rooms are data now, so the world can grow without a release. Your laptop and the live site use the same database here, which is why one insert shows up live.

If you tried the database, show us the Cellar at your live URL. A database stores data that the app reads. Neon holds the rooms in a table outside the browser. One SQL insert adds the Cellar to that table. The app reads the extra room without a new deployment. Your position and visited rooms still stay in the browser.

You wrote a migration in the database prompt: it created the rooms table. Every change to the shape of the database goes the same way. Each one is a new numbered file, committed to git and run by the build before it deploys. Nobody changes the live database's shape by hand, because then your laptop and the live site no longer match. Adding the Cellar was different: that was content, not shape, so one insert was fine.

Everything today could be undone with git. Data is the exception. Before a migration that removes anything, make a backup: ask the agent to export the database first. Neon also keeps a short history you can restore from, but a restore takes the whole database back, including anything people added since. The bigger line is people. The lighthouse stores rooms. The moment your app stores names, emails or anything about a person, the stakes change, and that is a conversation with an engineer before you ship.

Story: bad data outlasts the outage. On 8 September 2026, a software defect at NATS produced corrupted flight data in a millisecond. The system was back that evening, but more than 2,000 flights were cancelled, and it took airlines over two more days to get planes and crews back in place. The 2023 NATS failure was the same shape: about four hours down, around 1,600 cancellations, 700,000 people affected, and disruption until the weekend. The fix was quick. Clearing up after bad data was not. Bigger version: the TSB banking migration in 2018, where moving customer data to a new system caused problems that ran for months.

This list is the workflow. On Monday it is the same for a real product as it was today for a lighthouse. The order matters more than the tools. Next: when to talk to an engineer.

Everything today was safe to try alone: one game, no users, no personal data, and every change could be undone. Real products cross lines where a mistake costs more than a morning. Those are the moments to bring in an engineer. Sign-in is the big one. The moment the app has a login, you hold other people's accounts and you decide who can see what.

You do not arrive empty-handed. A live URL, a repo and tests for the behaviour you want give an engineer something concrete to work with. Write the name of one person you will speak to before you ship.

These are the same nine cards as the start. Then they were a promise. Now the ones you reached are things you did, and the rest are on these slides to finish at home. None of them needed you to write code. Then we have time for questions. There is more at chrismdp.com/coding-with-ai.

Thank you. Any questions? Scan the QR code to connect with me on LinkedIn, and there is more on my website. This page stays up, so you can come back to the prompts.