Do it professionally
Today's setup was made for a two-hour room: a small model, simple skills, one fixed path, and checks that only report. On your own projects, change these nine things.
Pick the model, the tool, and where it runs
Today: Gemini 3.8 Flash, the smallest model, in Antigravity IDE, free with your Google account, on your laptop: plenty for a portfolio, and everyone's free weekly quota lasted the whole workshop.
On your own projects: three choices, the model, the tool and where it runs.
The model. Write code with a stronger one: it writes better code and needs fewer corrections, and any strong model does, Gemini's bigger models, Claude's or others. The rule from Setup stays: take the smallest model that does the job well, not the biggest by habit. A quick question or a typo needs no big model; planning and code are worth a stronger one.
The tool. Claude Code, Anthropic's coding agent, is the most widely used AI coding tool at work: about four in ten professional developers use it, according to the JetBrains Developer Ecosystem Survey 2026. If you are looking for a job where AI is part of the work, learn it. GitHub Copilot, the assistant inside VS Code and other editors, is the other one you meet everywhere. What you learned today carries over to both: rules go in CLAUDE.md (Copilot reads .github/copilot-instructions.md), skills in .claude/skills/, and Claude Code has hooks, subagents and MCP, the same building blocks. Neither is free for real work: a paid Claude plan starts at 20 US dollars a month, or you pay per use through Anthropic's API; Copilot has a small free tier and paid plans.
Where it runs. It depends on what runs. Your coding agent runs on your own computer: Claude Code, Copilot or Antigravity IDE work on the files in front of you, as today. What you build for others runs where it is always on, watched and scaled, not on someone's laptop: an agent you write, an MCP server, an API, a contact form that sends email. At work that is the cloud, and a proven way, the one Fabian uses, is Google Cloud Run: you hand it a container, it runs it, scales to zero when nobody uses it (a small project costs nothing to little), and GitHub Actions deploys on every merge, the same pipeline as today.
Host it on a platform, under your own domain
Today: GitHub Pages, free, at https://YOUR-USERNAME.github.io/portfolio/. For a portfolio that is enough.
On your own projects: two steps make the site yours for good.
Your own domain. Register a name such as yourname.dev with a registrar, for example Cloudflare Registrar, which sells domains at cost. A .com or .dev costs about 10 to 20 US dollars a year. The domain stays yours when you move the site to another host, so your links, your email address and your place in search results keep working. GitHub Pages takes a domain too: Settings → Pages → Custom domain.
A hosting platform. Cloudflare Pages or Vercel connect to your GitHub repo and publish on every push, as GitHub Pages does today. On top, every pull request gets a preview address of its own, so you see a change live before you merge it; your domain gets HTTPS in a few clicks; and your pages come from data centres near your visitors. For this repo, set the build command to node tools/build.mjs and the output folder to _site. Both have free plans that cover a portfolio; Vercel's free plan is for personal projects, not for commercial ones.
Use an agentic framework many people use
Today: your repo had one simple skill per Role, written for this room: one fixed path, and a checkpoint after every Block so nobody got lost.
On your own projects: use an agentic framework, a set of skills that gives your agent a professional flow, from the spec to the review. Pick one that many developers use and report problems in: their feedback makes it better than a set you write alone. Agentic frameworks shows three to start with.
Keep your setup thin. Models get better every few months, and rules written for last year's model can hold this year's back. Now and then, try your setup without some of its rules, and delete what the model no longer needs.
Plan with a spec and small tickets
Today: the Analyst wrote a one-screen spec, and every Block was one small task in a fresh chat.
On your own projects: do the same before every feature. Let the agent interview you and write the spec. Then cut the spec into tickets, one goal each, as issues in your repo on GitHub. Each ticket gets a fresh chat. To start, paste this into a fresh chat:
Agent chat
I want to build <your idea in one sentence>. Do not design or write code yet.
Interview me first: one question at a time, at most eight questions,
about who it is for, what it must do, what it must not do,
and how we will know it works.
Then write a short spec to docs/spec.md and read it back to me.A good spec fits on one screen and has five parts:
A file in your repo, such as docs/spec.md
# Spec: <name>
## Problem
Who has it, and why it matters now.
## Solution
The approach, in plain words.
## Out of scope
What we do not build this time.
## Done when
- [ ] <something you can see or test>
- [ ] <something you can see or test>
## Open questions
What we still have to decide.Work on a branch, merge after a review
Today: Ops pushed every change straight to main, and it went live a minute later.
On your own projects: give each ticket its own branch, a copy of the code where the work happens while main keeps working. When the ticket is done, open a pull request. You, or a second agent in a fresh chat, review the change against the spec. Only then merge it into main, which goes live.
Let the checks stop a broken change
Today: the Check only reported. "It never stops you from publishing", so nobody got stuck in the room.
On your own projects: let GitHub Actions run the Check and your tests on every pull request, and block the merge when one fails. Ask the agent for the test first: a test that fails, then the code that makes it pass. A test is evidence you can run again tomorrow.
Give the agent only the rights it needs
Today: the agent asked before every command, and you allowed node tools/ and git. The repo held nothing secret.
On your own projects: keep it that way, with more at stake. Run the agent in a sandbox or a container where it reaches only the project, not your whole laptop, and let it ask before every command and every network call. Keep secrets in environment variables or in a file that .gitignore keeps out of the repo, never in the code the agent reads. Install only MCP servers and skills you have read, and pin their versions: each one runs with your rights. And review what the agent adds as carefully as what it writes: a new dependency is code from a stranger. The three rules behind this are in the Deep dive.
Measure real visitors too
Today: QA measured your home page on an emulated phone: lab data, the same on every run.
On your own projects: real visitors use other phones and other networks. Their numbers, called field data, show what people really get. One number comes only from them: INP, how fast the page answers a tap. PageSpeed Insights shows field data for sites with enough visitors.
Have the legal page checked
Today: the Developer filled in a template for a personal portfolio in the EU with one command, node tools/legal.mjs, and QA read the page with you. It is not legal advice.
On your own projects: once your site sells services or runs a business, let someone who knows the law in your country check the legal page. The rules differ from country to country, and a template cannot know your case.
Check yourself
Six questions on this page. Pick one answer each, then check them.