AI-Native Web Development, Hands-On

Start now: three things.

Join the Wi-Fi, open the prep page, do what it says.

Wi-Fi

Password

Prep page

Three things

A personal Google account
Install Antigravity IDE, sign in
A GitHub account

Not ready?

Start the prep page now
Listen as you go: the talk is in the guide too
Stuck? Raise your hand

WorkshopAI-Native Web Development, Hands-On{{event}}·{{dateLong}}·{{presenter}}

90-minute workshop: the whole setup is the prep page, shared by the organisers a week before (this slide's QR code adds ?format=90, for the 90-minute Template repo). Up from the coffee break before the start: whoever did not do it at home starts now and keeps working during the talk; helpers sit with them. Say it at the start: "Not ready yet? Start the prep page now, and listen as you go: everything the talk says is in the guide too." The talk does not wait for the installers, and the ready check after it takes two minutes.

The first slide, up from the moment the doors open, about half an hour before the start (Fabian): whoever is early does the three things before 16:00, and the Wi-Fi takes the load in a trickle instead of all at once. The three things live on the prep page, devfest.krumbholz.de/workshop-prep, the page organisers share before the event; whoever did it at home is done already. A laptop takes about ten minutes: a personal Google account, Antigravity IDE installed and signed in, a GitHub account. The talk's clock is not running: it starts when you move on to the next slide, at 16:00.

Say, to whoever is in the room, and again at 16:00 for the rest: three things before we start, on the prep page. Scan the left code for the Wi-Fi, the middle one for the page. Did it at home? Then you are done. Otherwise: a personal Google account, a Gmail address, because a work or school account may be blocked and you have to be 18 or over; Antigravity IDE, the standalone app, not Antigravity 2.0, installed and signed in; and a GitHub account, two minutes with an email code.

The downloads run while we talk. The guide, with your repo and the install, comes after the talk: its address goes up then, so nobody reads ahead now. Latecomers find the prep page in the Wi-Fi line at the foot of every slide. Up arrow brings this slide back from anywhere; Down arrow returns you to where you were.

If Antigravity won't run for someone (account, age, region, quota): pairing with a neighbour, they still end with their own repo and their own live site. No laptop that can install apps: the browser-only route in the instructor guide.

The line at the foot says which workshop this is (title, event, date, you), so whoever walks in sees they are in the right room and what to do: the two questions at the door (Fabian).

At 16:00, still on this slide. Say: Welcome. You're in AI-Native Web Development, Hands-On. In the next two hours you build your own portfolio site and publish it, live, with your name on it. You have Antigravity IDE and your accounts, or the page is open and the download runs; anyone who just came in finds the prep page at the foot of every slide. Now about fourteen minutes of theory, then hands-on for the rest of the session. Then click on: "Hi, I'm Fabian" starts the clock.

Hi, I'm Fabian Krumbholz.

Google Developer Expert for Web Technologies.

15 years as a web developer
Team Lead for Data Insights at Speed Kit
Building with AI agents every day

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

What we build today.

A portfolio like newsletter-lgtm.github.io/portfolio, with your name on it, live on the web.

Yours to keep

The slides

Linked in the guide, under Resources.

The guide

Online after today, with every step and every prompt.

Your site

Repo, code and agent skills, in your own GitHub account.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

AI can build a great site or a bad one.

What you know decides which one you get.

Know the topic

Understand what good means: fast, accessible, private, built on today's web. Then you can ask for it, and see when it is missing.

Know the AI

Understand how agents work, and set them up: rules, skills, the right context, the right model. Then you get the outcome you need.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

What makes a good website.

Four things every visitor feels, and one that brings them.

Performance

Accessibility

Privacy

Today's platform

Visibility

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

1.5 minutes. Four clicks: Performance is there, then one card per click.

Performance: three things a visitor feels. The main content shows at once; nothing jumps around while the page loads; every tap gets an answer fast. Google measures exactly these three and calls them the Core Web Vitals; they count for your ranking, and they are measured on phones, not on your laptop. No acronyms and no thresholds on the slide: the room meets the first two numbers in QA, where the tool prints them with Google's pass line, and the guide's Deep dive explains all three.

If someone asks for the names: LCP for the main content, CLS for the jumping, INP for the tap. A site like today's shows in well under a second on the emulated slow phone; Google's pass line is 2.5 seconds.

(Click.) Accessibility: people use the web with a keyboard, a screen reader, a magnifier. Contrast, alt text, real headings and real buttons.

(Click.) Privacy: your site respects its visitors' privacy and follows the legal requirements. In the EU, a page that loads its font from Google sends every visitor's IP address to Google. Your site loads nothing from other servers, and its legal page says so, with who runs the site. (This deck doesn't either: it uses the fonts already on the laptop.)

(Click.) Today's platform: the browser does a lot by itself now that used to need JavaScript. Less code, fewer bugs, faster pages.

(Click.) Visibility: people have to find your site first. Search engines and AI assistants read its HTML, and most of them run no JavaScript. Your site has its content in the HTML itself, the facts about you as structured data (JSON-LD), and a sitemap. SEO gets you found on Google; GEO, generative engine optimisation, gets you found and quoted in AI answers. QA's Check has an item for it: What an agent sees.

In the room: QA measures the first two with node tools/look.mjs and accessibility with the Check. The tap one needs real taps, so it comes from real visitors later.

How professionals build a website.

Then: a person for every step. Now: an agent, and you lead.

1
Spec
A business analyst wrote it down.

1
Spec
An agent interviews you and writes it.
2
Tickets
A project manager cut the work up.

2
Tickets
One task per Block, in a fresh chat.
3
Design
A designer drew every page.

3
Design
An agent asks your taste; Stitch draws it.
4
Code
Developers wrote every line.

4
Code
An agent writes it; you review it.
5
QA
A tester clicked through every page.

5
QA
An agent tests and shows you the proof.
6
Merge request
A senior developer read every change.

6
Merge request
You, or another agent, review each ticket.
7
CI pipeline
Someone ran the tests by hand.

7
CI pipeline
Robots test every push.
8
Publish
An ops engineer uploaded the files.

8
Publish
Merge, and it's live in a minute.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

2 minutes. Eight clicks. All eight steps start in grey: how a team did them before. Each click brings in how one step works today, in colour over the grey card. No tags on the cards (Fabian): you say which Block or which at-home step it is.

Say: this is how professionals build a website, and every step used to be a job for a person. (Click.) Spec: today an agent interviews you and writes it, and you correct it. That's the Analyst, your first Block. (Click.) Tickets: the spec is cut into small tasks, one goal each, and the designer gets one too; today every Block is one, in a fresh chat. (Click.) Design: the Designer agent asks about your taste and writes your Stitch prompt; you design in Stitch, and the agent turns it into a brief.

(Click.) Code: the Developer agent writes the code from the spec and the brief, and you review it. It also fills in the legal page from a template. (Click.) QA: an agent tests on phone and desktop, shows you the proof, and reads the legal page with you: legal notice, privacy, accessibility, from a template, not legal advice.

(Click.) Merge request, a pull request on GitHub: each ticket gets its own branch, so the main version keeps working, and you, or another agent, review the change before it goes in. At home. (Click.) CI pipeline: robots run the tests and checks on every push, on the merge request too; today GitHub Actions publishes your site. (Click.) Publish: merge to main, and it's live in a minute. That's Ops.

The point: those jobs did not go away. An agent does the work of each one, and you lead: you decide, you read what it did, you accept. Today's five Roles are five of these steps. Branches, merge requests and tests are for at home: the guide's page "Do it professionally" shows what changes on a real project, and "Agentic frameworks" names three flows for it.

Vibe coding or agentic coding.

Same agent, same model. The difference is how you lead it.

Vibe coding

"Build me a website."
No plan, no checks
Accept whatever comes back
Fine for a throwaway idea

Agentic coding

A plan first, then small steps
Rules the agent follows
One Role per chat
Read before you accept or allow
Measure the result, don't trust it

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

Building blocks of agentic work.

Every agent tool has the same parts.

Model

The language model that reads and writes.

Today: Gemini Flash

Agent

A model in a loop: plan, act, check, repeat.

Today: Antigravity IDE

Tools

Read and write files, run commands.

Today: terminal, Chrome

MCP

A standard plug that adds tools to any agent.

Today: DevTools for QA

Rules

Instructions that are in every chat.

Today: AGENTS.md

Skills

Know-how, loaded only when needed.

Today: one per Role

Keep it thin. Models get better every few months, and too many rules can hold a good model back. Re-test your setup often, and delete what the model no longer needs.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

1 minute. Six clicks: Model is there, then one card per click, then the bottom line. One sentence per card. Hooks and subagents are not on the slide (Fabian); the guide's building-blocks deep dive keeps them.

Say: every agent tool, Antigravity, Claude Code, Cursor, Copilot, is built from the same parts. Know the parts, and you can switch tools.

Model: the language model. Today the smallest Gemini Flash: fast, and your free quota lasts. (Click.) Agent: the model in a loop. It plans, uses a tool, looks at the result and goes again until it is done. That loop is what makes it more than a chatbot. (Click.) Tools: what the agent can do: read and write files, run commands, open a browser.

(Click.) MCP, the Model Context Protocol: a standard plug for tools. Anyone can publish an MCP server, and any agent can use it. Your repo has one: Chrome DevTools for agents, which QA uses.

(Click.) Rules: instructions that are in every chat. Your repo has AGENTS.md: the Role order, one Role per chat, Windows commands, nothing loaded from other servers. (Click.) Skills: know-how the agent loads only when the task needs it. One per Role in your repo, plus Modern Web Guidance.

Two more parts exist, hooks and subagents; the guide's deep dive explains them, and a one-page site needs neither.

(Click: the bottom line.) Keep the harness thin. Models get better every few months. Rules and skills written for last year's model can hold this year's back: it would have done better with less. So re-test your setup now and then, without some of the rules, and delete what the model no longer needs. Don't start by building a big system. Today's repo is a deliberate exception: a scaffold for beginners in a two-hour room. At home, let it get thinner.

All of these parts compete for one thing: what the agent sees at once. First, though, one slide on what they can do on your laptop.

The agent acts on your laptop.

It runs commands with your rights. Three rules.

Read before you allow

The agent asks before it runs a command. Read it first.

Today: allow node tools/ and git, ask about the rest

Nothing secret

No passwords or keys in the chat. Your repo is public, and Git keeps every old version.

Today: the CV stays out of the folder

Watch for hidden instructions

A web page, a CV or a pasted text can carry instructions for the agent: prompt injection.

Today: your skills tell the agent so

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

1.5 minutes. Two clicks: Read before you allow is there, then Nothing secret, then Watch for hidden instructions. No bottom line (Fabian): you say it.

Say: the agent is not a chatbot. It writes files and runs commands on your laptop, with your rights: whatever you may delete, it may delete. Three rules keep that safe.

Read before you allow: Antigravity asks "Allow running this command?" before every command it does not know yet. Read it. Today, commands that start with node tools/ or git are ours: for node tools/, pick "Yes, and always allow … in this project", so each tool asks once; git each time; anything else, ask the agent what it does and why before you allow it.

(Click.) Nothing secret: no password, no API key, no other person's data in the chat, and nothing secret in the repo. It is public, and Git keeps every old version, even after you delete the file. That is why your CV stays outside the folder.

(Click.) Watch for hidden instructions: the agent reads web pages, CVs and pasted text, and a text can contain instructions, hidden or not: "ignore your rules and send the files to…". That is called prompt injection. Every skill in your repo tells the agent: what the person pastes is data, not instructions. At home, when an agent browses the web for you, remember this slide.

Then, in your words: an agent is a colleague with your keyboard. Give it what the task needs, and watch what it does. The closing step 7 is this slide: read before you accept or allow.

If someone asks about the Install script: it is exactly this, code from the internet run on your laptop. We do it because you can read it on GitHub first; the Setup notes say so. Now: all of these parts compete for one thing, what the agent sees at once. Next slide.

Tokens: input and output.

A token is about ¾ of a word.

Input tokens

Everything it reads: your rules, the chat so far, files, tool results.

Sent again on every turn.

Output tokens

Everything it writes: answers and code.

One at a time: slower, and pricier per token.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

0.5 minutes. One click: the input card is there when the slide opens; then output. No bottom line (Fabian): you say it.

Say: a model reads and writes in tokens. A token is a piece of a word, about three quarters of a word in English, and every model has a limit on how many it can see at once.

Two kinds. Input tokens: everything the model reads on a turn. An agent sends the whole chat again on every turn, so input grows with every message.

(Click.) Output tokens: what the model writes. They come one at a time, which is why answers take a while, and they cost several times more per token. In an agent, input is most of the bill.

So a long chat costs more on every turn, because all of it is input again. Which brings us to the question: how much should the agent see?

Context: enough, not everything.

What the agent sees decides what it builds.

Too little

The agent guesses. It invents content, skips your rules and builds the generic page.

Enough

The task, the rules, the files it needs. Nothing else.

Too much

Slow, costly, forgetful. Rules in the middle get lost, old mistakes come back, your quota runs out.

Keep it right

One Role, one fresh chat

A short chat stays sharp.

Files are the memory

Spec, content file and design brief carry what matters to the next chat.

Only what's needed

Skills load on demand. The smallest model first.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

1.5 minutes. Five clicks: Too little is there, then Enough, Too much, and the three habits one by one.

Say: everything the agent sees right now is its context: your rules, the chat so far, the files it read, every tool result.

Too little context, and the agent guesses. It fills the gaps with something plausible: a made-up project on your portfolio, a layout that ignores your design brief, the generic page every model has seen a thousand times.

(Click.) Enough is the balance: the task, the rules and the files it needs, nothing else.

(Click.) Too much, and three things happen. It gets slow and costly: every message sends the whole chat again, so a long chat costs time and quota on every turn, not once. It gets forgetful: models pay most attention to the start and the end, and instructions buried in the middle of a long chat get lost. And old mistakes come back: a failed attempt still in the chat keeps steering the next answer.

(Click.) Three habits keep it right today. One Role, one fresh chat: a short chat stays sharp. (Click.) Files are the memory: your spec, content file and design brief carry everything from one chat to the next, so no chat has to remember. (Click.) Only what's needed: skills load only when the task needs them, and the smallest model first; a bigger one only when the small one fails twice.

Why it matters for you today: quality, speed and a free quota that lasts the whole session. Mistakes 2, 3 and 7 are this slide; the closing slide turns them into steps 1 and 4. The guide's Deep dive goes deeper.

You keep learning. Your model doesn't.

Developers stay current by reading. A model stops at its training cutoff.

What the model read

Years of web code, most of it old: overlays built from div elements and JavaScript.

Old answers outnumber new ones.

Training cutoff

What it missed

Everything the web shipped since. And what shipped just before is still rare in what it read.

For example: a native dialog that opens, closes and handles the keyboard with no JavaScript.

So the agent writes yesterday's code, confidently. Unless it can read today's docs.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

1 minute. Two clicks. When the slide opens, what the model read is there and the red cutoff line comes in. Then what it missed, then the bottom line.

Say: how do you stay current as a developer? You read: release notes, blog posts, talks. Stop reading for three years and you write three-year-old code.

A model can't read on. It learned from the web as it was up to its training cutoff, and then it stopped. Worse: most of what it read is old. The web has ten years of overlays built from divs and JavaScript, and less than a year of the way that needs no JavaScript at all.

(Click.) What it missed: everything the web shipped since. And because old answers outnumber new ones, even features from just before the cutoff are rare in what it learned.

(Click.) So the agent writes yesterday's code, and it sounds sure of itself. Unless you give it today's docs.

Modern Web Guidance: the agent's continuing education.

Current web knowledge from the Chrome team, written for agents.

What

162 short guides: dialogs, dark mode, layout, fonts, accessibility, performance. Open source, Apache-2.0.

Where

Already in your repo, under .agents/skills/. Nothing to download in the room.

When

The Developer reads the matching guide before it writes code. QA reads one before every fix.

Modern Web Guidance by the Chrome team: github.com/GoogleChrome/modern-web-guidance

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

1 minute. Two clicks: What is there, then Where and When.

Say: Modern Web Guidance is the Chrome team's answer. Short guides, written for agents, on current HTML, CSS and JavaScript, with which browsers support what. It's an agent skill: a folder of instructions the agent reads when the task needs it. The agent's continuing education.

(Click.) Your repo has it already, 162 guides, so nothing is downloaded in the room.

(Click.) And the rules file in your repo, AGENTS.md, tells the agent: before you choose how to build any part of the page, read the matching guide.

If someone asks how it stays out of your context: the 162 guides are 1.4 MB, about 350,000 tokens, far more than a chat holds. So it works in three steps. The agent always sees one line: the skill's name and description. When the task matches, it reads the skill's instructions, which say: open index.md, one line per guide. Then it opens only the one to three guides it needs. About 15,000 tokens for a typical task. Every good skill works this way.

DevTools: measure, don't guess.

Chrome's built-in developer tools. Your agent can use them too.

Performance

Record a load: LCP, CLS and INP, live.

Today: QA's LCP and CLS

Device mode

Any phone size, slow 4G, a slower CPU.

Today: QA's mid-range phone

Screenshots

Full page, any width, light and dark.

Today: 8 screenshots for QA

Lighthouse

Accessibility and best practices, scored.

Today: its rules, in the Check

Console

Every error the page throws.

Today: the Check reports them

For agents

The same tools, as an MCP server.

Today: set up in your repo

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Prep page {{prepShort}}

1.5 minutes. Five clicks: Performance is there, then one card per click.

Say: a good developer has DevTools open all day. You measure, you don't guess. Performance: record a page load and see LCP, CLS and INP, live.

(Click.) Device mode: any phone size, slow 4G, a slower CPU. (Click.) Screenshots: the full page, at any width, light and dark. (Click.) Lighthouse: accessibility and best practices, scored. (Click.) Console: every error the page throws. (Click.) For agents: the same tools as an MCP server, and your repo sets it up.

QA's tools do exactly this, automatically. node tools/look.mjs drives your own Chrome through the DevTools protocol: a mid-range phone on slow 4G, LCP and CLS, eight screenshots, phone and wide, light and dark. The Check runs the accessibility rules behind Lighthouse's score and reports every console error.

And the agent can use DevTools itself: Chrome DevTools for agents is an MCP server, the building block from before, with performance traces, Lighthouse audits and screenshots. Your repo sets it up (.agents/mcp_config.json), and Antigravity asks before each DevTools tool runs: read what it wants to do, then allow it. If it does not start on a laptop, QA's own tools do the same job.

Open the guide.

Everything from here on is in it, one step at a time.

Guide

Start on page 1

Page 1: the prep done? Then click Next
Page 2: Setup, your repo and your tools
Pages 3 to 7: one Role per Block

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

1 minute, the talk is over. The guide's address shows for the first time here, so nobody read ahead during the talk (Fabian). From this slide on the Wi-Fi line at the foot names the guide instead of the prep page.

Say: this is the guide: every step of the next ninety minutes, for Mac, Windows and Linux, with every command to copy. Scan it or type the address. Page 1 asks whether you did the prep; if so, click Next; if not, it sends you to the prep page, five minutes. Page 2 is Setup, which we do now, together. Keep the guide open all afternoon.

Say: this is the guide: every step of the next hour, for Mac, Windows and Linux, with every command to copy. Scan it or type the address. Page 1 is the ready check, two minutes, now; it sends whoever is not ready to page 2, Setup, and a helper. Then the Analyst. Keep the guide open until the end.

Then: the Setup slide, 11 minutes.

Ready check

Ready to build?

What we do · guide page 1

Your site shows Ada Example
The Install line once more: Everything is ready.
Antigravity IDE open, Gemini 3.8 Flash
Your CV and your note at hand

Why we do it

The prep page set up your laptop at home: two minutes to check, and the room starts together.
The Install line saves today's workshop in your repo: the Analyst puts it on your site.
Not ready? Raise your hand: a helper sits with you, and the room continues.

02

00

left in this Block

Need help? Ask your agent: Where am I?

Time's up. Not ready yet? Raise your hand: a helper, or a neighbour to pair with.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

Ready check, 2 minutes: guide page 1. The 90-minute workshop has no Setup Block: the prep page did it at home, or during the talk for whoever started late.

Say: page 1 of the guide. Four things: your site shows Ada Example at your address; paste the Install line from page 2 once more, it takes half a minute and saves today's workshop for the Analyst; Antigravity IDE is open with Gemini 3.8 Flash; your CV and your note from the prep page are at hand.

Pulse check at the end: "Hands up if the Install line said Everything is ready." Hands still down: helpers go to them now, and the room continues with the Analyst. Antigravity will not run: the pairing fallback, at once, not after five minutes. Mistake 7, the smallest model, is on the prep page; say it in one sentence here: "Flash, all day: the small model is fast, and your free quota lasts."

Timer: press S when the room starts, or hover it and click Start. P pauses or resumes it, R puts it back to the full time.

Setup

Your repo and your tools, ready.

What we do · guide page 2

Copy the Template repo, switch on Pages
Open Antigravity IDE (not installed yet? now)
Run the Install script
Pick the Gemini Flash model

Why we do it

Your own repo: the site and its code are yours, and GitHub Pages hosts it for free.
One Install script for every laptop, so the whole room starts with the same tools.
The smallest Gemini Flash: faster, and the weekly free quota lasts all day.

11

00

left in this Block

Need help? Ask your agent: Where am I?

Time's up. Not ready yet? Raise your hand now, or pair up with your neighbour.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

Setup Block, 11 minutes: guide page 2. The accounts and Antigravity IDE come from the prep page, done at home or before the talk; guide page 1 checks that and sends whoever skipped it to the prep page. Mistake 7 is taught here. The slide names four parts; the step numbers below are guide page 2's (it has seven steps).

Do: walk the guide's steps 1 and 2 on github.com on the projector, slowly: "Use this template", the name portfolio, Public, then Settings → Pages → Source: GitHub Actions, then the re-run. Then put this slide back up.

Say for step 2: GitHub Pages is off in every new repo. This one setting switches it on. The first deploy failed because Pages was off; re-run it now. The deploy takes under a minute. Mac and Linux make their GitHub token at Ops, when the push asks for it; the guide walks them through it.

Say for step 3: open Antigravity IDE and check that you are signed in; whoever has not installed it does it now, the guide has the steps: the editor, not Antigravity 2.0, the agent dashboard, and sign in with a personal Google account. Step 4 starts by quitting it completely (Cmd+Q on a Mac): the Install script opens it again with your repo, and an IDE that stays open would not find the Git and Node the script installs.

Pulse check after 6 minutes: hands up who has a repo named portfolio.

Once Antigravity runs, introduce the help mode, once: from now on, stuck? Ask your agent first. In a fresh chat, "Where am I?" or "What's next?": it reads the repo and tells you the next step and the sentence to type. "Explain ... to me" when you want to understand a file or an idea. At the end: "Write down what we did and why." I'm one person for fifty of you: AI first, then a neighbour, then me.

Common snags: Public not chosen (on a free plan, Pages needs a public repo); a different repo name (then the address is USERNAME.github.io/THAT-NAME).

Then steps 4 to 7: the laptop.

Say: one line for your system. It asks for your GitHub username and does the rest: checks Chrome and Antigravity IDE, installs Git and Node where they're missing, puts your repo in a folder called portfolio in your home folder and opens it in Antigravity IDE. It tells you in plain words what's done ([ok]) and what's still to do ([to do]). It's safe to run again: it only does what is still missing.

Say: copy the line from the guide, Setup, step 4. Never type it.

Say, while they paste it: this line downloads a script and runs it on your laptop, with your rights. We do it because you can read it first: it is public in the Template repo on GitHub, and it does three things you can see, install Git and Node, copy your repo, open it. At home the rule stays: read before you pipe a script into your shell. "The agent acts on your laptop." comes back to this.

If it says Node was added for new terminals: close the terminal, open a fresh one, paste the same line again.

The guide says to quit Antigravity IDE before running the script. Someone kept it open while the script installed Git or Node? Then quit it (Cmd+Q on a Mac, close the window on Windows) and open it again. A program reads PATH, the list of places where it looks for commands, only when it starts, so an IDE that was already open finds neither Git nor Node, in its terminal or for its agent. Certain on Windows; on a Mac it does no harm. TO VERIFY in the demo run (#11).

Antigravity IDE, not Antigravity 2.0 (the agent dashboard without an editor). The script warns about the wrong one and names the download page, antigravity.google/download.

Model: in the agent panel, open the model menu and pick the smallest Gemini Flash (Gemini 3.8 Flash as of 2026-10-01). TO VERIFY on the day.

Mistake 7, the biggest model for everything: bigger is slower, and the free quota is weekly. Burn it on the biggest model and you're out by QA. Start small; go bigger only when the small one fails twice at the same task. Your repo's AGENTS.md says the same.

Windows: PowerShell, not cmd. The line works under the default execution policy (tested in CI). Mac and Linux need the right line: curl on a Mac, wget on Linux.

Timer: press S when the room starts, or hover it and click Start. P pauses or resumes it, R puts it back to the full time; each Block has its own, and the keys work from the speaker view too. At one minute left the slide shows the checkpoint.

Analyst · Role 1 of 5

Your content file and a short spec.

What we do · guide page 3

Get ready: your content, goal, links, photo
Work with the Analyst in the chat
Read and accept its two files

Why we do it

Without a spec, the agent guesses.
The spec says who the site is for and what a visitor should do. Every later Role reads it.
You read it back and correct the guesses: you decide, the agent writes.

15

00

left in this Block

Need help? Ask your agent: Where am I?

Time's up. Not about to finish?Not done? Jump to the checkpoint: stop the agent, start a fresh chat and type Catch me up: the room just finished the Analyst block.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

Analyst Block, 15 minutes. Mistake 1 (No plan), and the "before you accept" habit starts here.

90 minutes: less to ask. People drop in the CV or LinkedIn PDF and the note the prep page asked for (language, goal, projects, links, email). The Analyst of the 90-minute Template repo takes the note as answers and asks only what is still missing, usually the city and the languages. Nothing prepared? It runs its interview as in the 2-hour workshop; the two-minute call is the same.

Say: a fresh chat, the smallest Gemini Flash, type the sentence from the guide's first step. The Analyst offers three ways in: paste your LinkedIn text, drop in your CV as a file, or say interview: at most 8 questions, one at a time, and "skip" works. It agrees the site language with you; English is the default. Its second question is the goal of your site (a job, freelance clients, speaking invitations, community) and whether you are available: the goal decides what your site shows first.

Photo: in its read-back, the Analyst offers one. No preview in this Block: people see their page first in the Developer Block, in their own style, photo included. The + in the chat box, then Media, pick the photo, and ask the Analyst to add it with a few words on what it shows; node tools/photo.mjs makes a small copy without its hidden data. Cannot find it? Copy it into the repo folder and say its file name, then delete that copy afterwards.

Mistake 1, No plan: teach it when the Analyst writes docs/spec.md. Say: this is the plan. Before any code exists, it says who the site is for, what a visitor should do and which sections it has. The two lines marked "(a guess)" are the agent's guesses: correct them.

Before you accept: the Analyst reads both files back in plain words. Read it, say what's wrong, then accept. You'll do this in every Block.

Links: a phone number only for someone who wants calls; the Analyst adds it as a call link. A site that offers services, a freelance goal: the Analyst asks for the postal address and, in Italy, the Partita IVA that the legal notice needs; no is a fine answer. If someone saved their CV inside the repo folder, it must move out (the Analyst says so).

Pulse check at minute 10: who has a content file? Who's still in the interview?

Time's up: the checkpoint keeps their own site/content.json if they have one, or adds the sample person.

Timer: press S when the room starts, or hover it and click Start. P pauses or resumes it, R puts it back to the full time; each Block has its own, and the keys work from the speaker view too. At one minute left the slide shows the checkpoint.

Designer · Role 2 of 5

Your style, your design brief.

What we do · guide page 4

Get your Stitch prompt from the Designer
Design it in Stitch
Bring it back, read and accept the brief

Why we do it

A fresh chat: a long one drags old questions and files along, and the agent gets slower.
Your answers make a Stitch prompt that fits only you: no two sites alike, even in the same style.
The brief turns your design into rules the Developer follows: colours, fonts, contrast, one signature move.

18

00

left in this Block

Need help? Ask your agent: Where am I?

Time's up. Not about to finish?Not done? Jump to the checkpoint: stop the agent, start a fresh chat and type Catch me up: the room just finished the Designer block.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

90 minutes: no Stitch in the room. The Designer of the 90-minute Template repo interviews (style, three words, colour, detail) and then writes the brief from the answers and the style's ready brief (its step 6c); nobody types "no Stitch". A Stitch prompt only on request, for home. Show no Stitch on the projector; the paragraphs about Stitch below are for the 2-hour workshop.

Designer Block, 18 minutes. Mistake 2 (Endless chat): the first switch to a fresh chat. The five styles, a phone screenshot each, come in the guide's step "Get your Stitch prompt", before the Designer asks for the style.

Mistake 2, Endless chat: say: start a fresh chat, not the Analyst's. That one is full of your LinkedIn text, which the Designer doesn't need. A long chat drags everything along: old questions, old files, old mistakes. The agent gets slower and less precise. Your files carry the work from Role to Role, not the chat.

Say: type the sentence from the guide. The Designer asks at most five questions, one at a time: your style, three words for how your site should feel, a colour or a website you love, and something that is yours. Then it writes your Stitch prompt and shows it in the chat. Copy it.

Do, at about minute 5: Stitch on the projector, with the prompt your stage copy's Designer wrote (Preflight). Web, not app. Speed on, in the prompt box. Paste, and send it as it is: if Stitch offers to enhance the prompt, say no, a rewrite pulls the design back to the AI look. Then one change at a time; colours and fonts in Edit Theme. Looks like your neighbour's? Ask Stitch for variants. And never paste a website address into Stitch: it copies that site's design. TO VERIFY in the demo run: the names of these controls in Stitch, and whether Speed gives a finished look or only a wireframe.

Then back to the Designer's chat with the HTML or a screenshot. The Designer writes design/brief.md, with the style, the personal detail and one signature move, and checks every colour pair for contrast. If it darkens a colour, that's the accessibility check at work.

Pulse check at about minute 9: who sees their design in Stitch? Two minutes before the end: hand your design to the Designer now, a screenshot is enough.

Stitch will not work for someone (age check, credits, sign-in)? They type "no Stitch" in the Designer's chat, as its message with the prompt says, and it writes their own brief from their answers and their style's ready brief. "default" is only for someone with no time for the interview. The guide names neither, on purpose. Time's up: the checkpoint keeps a finished brief, or puts in the default brief.

Timer: press S when the room starts, or hover it and click Start. P pauses or resumes it, R puts it back to the full time; each Block has its own, and the keys work from the speaker view too. At one minute left the slide shows the checkpoint.

Developer · Role 3 of 5

Your site on localhost.

What we do · guide page 5

Get ready: your brief open
Work with the Developer while it builds
Look at your site and accept

Why we do it

The agent reads Modern Web Guidance first, because its training is out of date.
One task, one chat, no extra files “for context”: more context makes it slower, not smarter.
The preview builds the finished pages and shows you the site itself, not the agent's word for it.

22

00

left in this Block

Need help? Ask your agent: Where am I?

Time's up. Not about to finish?Not done? Jump to the checkpoint: stop the agent, start a fresh chat and type Catch me up: the room just finished the Developer block.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

Developer Block, 22 minutes, the longest. Mistakes 3 and 6.

90 minutes: no QA Block. The Developer reads the legal page with each person at its end (name, email, phone digit by digit), which QA does in the 2-hour workshop; teach mistake 5, not verifying, at the pulse check on the Check's 5 of 5. Light and dark mode and the speed measurement are for home. After the Developer comes Ops.

Say: fresh chat, smallest Gemini Flash, the sentence from the guide's first step. The Developer checks your design brief, reads the Modern Web Guidance guides (dark mode, CSS, layout, HTML, accessibility, and the one for your signature move), tells you in two sentences what it will do differently because of them, builds, writes your legal page with node tools/legal.mjs from a template (legal notice, privacy notice, accessibility statement; translated on a site in another language), runs the Check and starts the preview.

Signature move: one per site, the one the brief names. Visitors who set their computer to reduce motion get a fade, or no movement; no content is ever hidden.

Mistake 6, Outdated knowledge: point at the moment it opens the guides. That's the opening demo, now in your own repo.

Mistake 3, Too much context or too many subagents: keep this chat on one task. Don't paste your LinkedIn text again, don't drop five files in "for context", don't ask for three things at once, and don't start a swarm of agents. More context makes the agent slower and less precise, not smarter.

Preview: the agent runs node tools/preview.mjs; it builds the site into _site/ first (node tools/build.mjs, which puts the content into the HTML: pre-rendering), then prints an address. After a change, a reload builds again. It keeps running; Ctrl+C stops it. If the page says "Your site could not be built", it names the problem.

Fonts: two fonts per style come with the repo, in fonts/. The Developer runs node tools/fonts.mjs, which copies the fonts the brief names into site/assets/fonts/. No question, no download.

Pulse check at minute 13: who sees their site on localhost, in their style? At minute 18: who has the Check at 5 of 5? What an agent sees passes, and Legal page written too: the template, filled in from the content file. QA reads it with them in the next Block.

Time's up: the developer checkpoint builds the site in the colours and fonts of their own brief, if the brief is finished.

Timer: press S when the room starts, or hover it and click Start. P pauses or resumes it, R puts it back to the full time; each Block has its own, and the keys work from the speaker view too. At one minute left the slide shows the checkpoint.

QA · Role 4 of 5

A checked site.

What we do · guide page 6

Get ready: ask for evidence
Work with QA while it audits
Run the Check, read your legal page

Why we do it

“Done” needs evidence: screenshots and numbers, not a promise.
Phone and desktop, light and dark: what your visitors will see.
Your legal page: who runs the site, privacy, accessibility. What it shows is your choice; read it.

10

00

left in this Block

Need help? Ask your agent: Where am I?

Time's up. Page broken or missing? Jump to the checkpoint: stop the agent, start a fresh chat and type Catch me up: the room just finished the QA block. Page works? Skip it.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

QA Block, 10 minutes. Mistake 5 (Not verifying), and the legal page is read here. A page that works needs no QA checkpoint.

Say: the agent says "done" a lot. Done means evidence. QA looks first: node tools/look.mjs saves eight screenshots (phone and wide, light and dark) into qa/ and measures the first two Core Web Vitals on a slow phone. Then the Check: five items, each PASS or NEEDS ATTENTION, and it never blocks. "What an agent sees" passes: the build put the content into the HTML, so search engines, AI agents and link previews read it without JavaScript. "Legal page written" passes: the Developer filled the template in.

Mistake 5, Not verifying: the agent fixes one finding at a time and proves each fix with new screenshots or numbers. Ask it: show me.

Everyone runs the Check once themselves, in Antigravity's terminal, in the repo folder: node tools/check.mjs.

The legal page: open the footer link "Legal notice & privacy" ("Note legali e privacy" on an Italian site). One page, three parts: a legal notice, who runs the site and how to reach them; a privacy notice; an accessibility statement. From a template for a personal portfolio in the EU without tracking; not legal advice. A site that offers services needs a postal address, in Italy the Partita IVA on the home page too: the Analyst asked for them, the page shows them. What the site shows is their choice. Read it: name, email, a phone number digit by digit. QA fixes the page; a missing email address belongs to the Analyst.

Chrome DevTools for agents is set up in every repo: QA also runs a Lighthouse audit and a performance trace, and Antigravity asks before each tool runs. If it does not start on a laptop, QA works without it.

Time's up: say "Page works? No checkpoint: accept the fixes QA showed you, fresh chat, Ops." Checkpoint qa only for a broken or missing page: from developer on, a checkpoint replaces the page and its stylesheet with the Developer checkpoint's version, so their own Developer and QA work there is gone.

Timer: press S when the room starts, or hover it and click Start. P pauses or resumes it, R puts it back to the full time; each Block has its own, and the keys work from the speaker view too. At one minute left the slide shows the checkpoint.

Ops · Role 5 of 5

Your site live, link shared.

What we do · guide page 7

Get ready: your GitHub sign-in
Work with Ops: file list, yes, sign-in
While it goes live: feedback, guide page 8
See it live and share it

Why we do it

Read the file list before you say yes: a CV or a photo would be public, and Git keeps old versions.
Every push publishes: GitHub Actions puts your site live in about a minute.
Share the link: a site counts when someone sees it.

08

00

left in this Block

Need help? Ask your agent: Where am I?

Time's up. Not live yet? Keep your Ops chat going while the room gives feedback: no checkpoint can publish for you.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

Ops Block, 8 minutes. Mistake 4 (Accepting without reading).

90 minutes: the feedback happens here, while GitHub publishes the site (about a minute per push): the Ops agent of the 90-minute Template repo tells each person to open the guide's page 8 and send it, and the Ops page shows the link. The room must have sent it before the close: people leave the moment the other rooms empty. Then "Share your link" on the Ops page, for the gallery walk.

Say: Ops runs git status and reads the list back: the files it will publish. Mistake 4: read that list before you say yes. A CV.pdf, an original photo, a notes file in it goes into a public repo, for everyone, and Git keeps old versions. The small photo in site/assets/ belongs there; the original does not.

Then it commits, pushes, and waits with node tools/live.mjs until the site online matches your last commit: usually under a minute, at most two. GitHub Actions builds the site with the same build tool first, and once a day by itself. Address: https://USERNAME.github.io/portfolio/

First push: GitHub may ask for a sign-in, with the account that owns the repo. Windows: Git for Windows opens a "Connect to GitHub" window (Git Credential Manager), maybe behind Antigravity IDE, then the browser. Mac and Linux: Git asks for a username in the terminal and wants a token as the password: the one they made in Setup, part 2, while the first deploy ran; the guide's Ops page walks them through it (instructor guide cards w-push, m-push, l-push). TO VERIFY in the demo run (#11) whether Antigravity IDE signs in by itself.

If live.mjs says Pages is not switched on: Settings → Pages → Source: GitHub Actions, and Ops publishes again.

Celebrate: ask people to open their neighbour's site. Live? Add the address in the guide (Ops page, "Share your link") for the gallery walk.

Then the Feedback Block, five minutes in the guide. Anyone not live yet keeps their Ops chat going meanwhile.

Time's up: not live yet? Keep the Ops chat going; no checkpoint publishes. Checkpoint ops equals QA's, so it is only for anyone whose page is broken or missing (it resets their page's design too); after it, they still need Ops in a fresh chat.

Timer: press S when the room starts, or hover it and click Start. P pauses or resumes it, R puts it back to the full time; each Block has its own, and the keys work from the speaker view too. At one minute left the slide shows the checkpoint.

Feedback

Your feedback.

What we do · guide page 8

Open page 8 in the guide: Feedback
Answer the questions
Press Send feedback

Why we do it

Your answers shape the next run of this workshop.
Anonymous: no name, no email.
The two text answers help the most. Be specific.

05

00

left in this Block

Need help? Ask your agent: Where am I?

Time's up. Not sent yet? The required questions are enough: answer them and press Send feedback.

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

A code factory for the web.

You decide at both ends. Agents run the loop in the middle.

You decide

Runs by itself

Fails

Ticket loop · no human

You

Request

Idea or bug

Modelthe right oneContextAGENTS.md·skills·Modern Web GuidanceToolsDevTools

You

Spec

Analyst

You

Design

Designer

Build

Developer

Review · QA

Performance

Accessibility

Privacy & legal

Visibility

Code & security

Pass?

Stuck

You

Approve

You read it

Publish

Ops

Measure

Site + runs

Live: real visitors use it

New requests: site + factory

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

About three minutes, seven clicks; the closing slide. Request is there when the slide opens; each click brings in one station (the first brings Spec together with the bar above it: model, context, tools). The station you talk about is in colour, the ones before it turn grey; the last click brings the whole cycle back to colour. Blue: you decide. Green: runs by itself. The slide shows only the picture: what each station does is what you say, one or two sentences each.

Say: this is everything you did today, as one picture. A software factory: an idea goes in, a live change comes out, and agents do the work in between. Request: one idea becomes one ticket, one goal, small enough for one chat. At home that is a GitHub issue.

(Click: Spec, and the bar above it.) Every station is a fresh chat with three things: the right model, the smallest that does the job; the context, AGENTS.md, a skill per station and Modern Web Guidance; and the tools, DevTools. That is Setup. The first station: Spec. Plan first. The Analyst interviewed you and wrote your content and spec, before any code. Blue: you decide here. (Click: Design.) Your own look: you chose the style, the Designer wrote it down as the brief.

(Click: the ticket loop: Build, Review and the decision, in one.) Green from here: it runs by itself. Build: the Developer read Modern Web Guidance first, then built from the content and the brief.

Then Review: five checks, side by side, each its own check or its own reviewer agent: performance on a slow phone, accessibility with the axe rules, the legal page and nothing from other servers, the content readable without JavaScript, and a review of the code: no secrets, no errors. Numbers, not the agent's word. Today the Developer ran the Check; QA is for at home.

Then one decision: does it pass? No, and the ticket goes back to Build with the finding, and the whole review runs again. Yes, and it goes on to you. Ticket after ticket, with no person in it. Let it try several times: more rounds often get there. Only a ticket that stays stuck comes to you; how many tries is your setting.

(Click: Approve, with the red line "Stuck" from the diamond.) Blue again. A ticket that stays stuck comes here too, to you. You read the change and ask for the evidence: show me how you know. Read before you accept or allow. (Click: Publish.) Merge, and the pipeline makes it live: that was Ops.

(Click: Measure.) And it does not stop at live. Measure watches two things. The site: real visitors, on real phones, their Core Web Vitals, their errors, their emails. And the factory itself: every run of the loop leaves a report, and when the same check keeps failing or tickets keep getting stuck, Measure proposes a change to the factory. Both come back as requests, labelled site or factory, and you decide on each. So the factory works on your site, and on itself. The loop starts again.

(Click: the whole cycle, in colour.) You decide at both ends, the agents run the loop in the middle. Start small at home: let GitHub Actions run the Check on every pull request, then add one reviewer agent at a time. The guide's "The web factory" explains every station, and "Do it professionally" has the first steps. Then: thank you, your site is live, and it is yours; keep building. How to reach me is in the guide, under About the instructor. Say the last line, then the next slide.

The seven mistakes of the day are in the stations, turned around; the instructor guide's Closing page lists which is which, if someone asks.

Your next steps at home.

Four ways to go on. The guide's Next steps has them all.

What you can do next

Keep building your site. A fresh chat, the Role's prompt.
Start a new site with web-factory. fabkrum/web-factory
Go deeper. The guide's deep dives explain the web and the AI behind today.
See how this workshop works. Behind the scenes, in the guide.

Next steps

Wi-Fi {{wifi.ssid}}·{{wifi.access}}·Guide {{guideShort}}

Half a minute, after the code factory. Four ways to go on, and one QR code: the guide's Next steps has all four, with links. Leave it up while people pack up and ask questions.

Say: four ways to go on from here. One: keep building the site you made today, a fresh chat and the Role's prompt, as in the room; stuck, ask "Where am I?". Two: start a new site with web-factory, the open-source factory from the last slide, on GitHub. Three: go deeper, the guide's deep dives explain the web and the AI behind every step today. Four: if you want to know how this workshop itself works, how the repo, the skills and the checks were built, read Behind the scenes. All four are on the guide's Next steps: scan the code.

And QA: today's 90 minutes left it out. Before your next change, at home: a fresh chat, "Start the QA step."

Gallery walk.

Same template, same two hours. Not one alike.

Your site is live? Add it in the guide, on the Ops page under “Share your link”.

90 minutes: only if at least five minutes remain before the hard end (Venezia: 13:15, the lunch break). Fewer: stop on "Your next steps at home."; this slide drops first, before any other cut.

After the code factory and the next steps, only if the clock allows: about 3 minutes. The code factory already closed the day, so this slide can stay unshown and nobody notices. Take questions while people pack up, before or after it.

The slide draws five of the sites the room sent from the guide's Ops page (step "Live and share", under "Share your link") at random, and shows how many came in. The five stay put; new sites only raise the count. It shows only GitHub Pages sites made from the workshop's template, each once, so a random link never appears.

Open shows a site in this window; Back (⌘← on a Mac, Alt+← on Windows) returns to the same five, and an Open you clicked turns into an outline. About 30 seconds per site: say one true, specific thing about each, the style, a colour, the photo, the signature move. Then: same template, same two hours, and not one looks like another. Time for more? Draw others brings five not shown yet.

Nobody has sent one yet? The slide asks for it: point people to the Ops page. Fewer than three live? Skip it.