Deep dive: AI

How to work with an agent, and what it costs: the AI half of the talk at the start of the workshop, slide by slide. The parts every agent tool is built from have a page of their own, Deep dive: building blocks; the web half is on Deep dive: web development.

On this page

• Vibe coding or agentic coding
• How professionals build a website
• Building blocks of agentic work
• The agent acts on your laptop
• Tokens: input and output
• Stay independent of any one model
• Context: enough, not everything
• Eight steps to a professional website
• Check yourself

Vibe coding or agentic coding

"Vibe coding" is a name Andrej Karpathy gave in February 2025 to a way of working: you describe what you want, accept what comes back and do not read the code. That is fine for a throwaway idea. It is not how you build something with your name on it, because nobody knows what is in it.

Agentic coding uses the same agent and the same model. The difference is that you lead, in a loop of your own: plan, let the agent do one small step, read what it did, accept, check. Today every Role was one turn of that loop.

Leading starts with the prompt. A prompt you can check has five parts:

• Inputs: which files or facts to read first.
• Outputs: what you want back, and in which file.
• Scope: what to leave as it is.
• Constraints: the rules it has to keep, such as your design brief.
• Verification: how you both know it worked.

Speaking is faster than typing, and you give more detail: every system has dictation built in. On a Mac press Fn twice, on Windows Win+H. And the first prompt is a draft: send a good-enough one, read what comes back, and improve it.

How professionals build a website

The slide showed eight steps, from the spec to publishing. Every step used to be a job for a person; today an agent does the work of each one, and you lead. You took five of the steps in the workshop. The others, and what changes on a real project, are on their own page: Do it professionally.

Building blocks of agentic work

Model, agent, tools, MCP, rules, memory, skills, hooks and subagents: every agent tool has these parts, and plugins package them. The slide showed six; memory, hooks and subagents, the three for later, are on that page too. Each one, and how to write your own skill, is on its own page: Deep dive: building blocks.

The agent acts on your laptop

An 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, today and at home.

• Read before you allow. Antigravity asks Allow running this command? before every command it does not know yet. Today, commands that start with node tools/ or git are ours: the workshop's tools you allow once per project with Yes, and always allow … in this project, a git command each time; for anything else, ask the agent what the command does and why, and allow it only when you understand the answer. An MCP server is a program too: each one runs on your laptop with your rights, so install only servers you trust, and pin their version.
• Nothing secret. No password, API key or other person's data goes into a chat, and nothing secret goes into the repo: it is public, and Git keeps every old version, even after you delete the file. A secret an agent needs at home lives in an environment variable or in a file that .gitignore keeps out of the repo, never in the code.
• Watch for hidden instructions. The agent reads web pages, CVs and pasted text, and any 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 that reads what you paste or drop in tells the agent that it is data, not instructions. The same care goes to a skill you install: read it first, because it runs with your agent's full permissions.

The Install script in Setup was exactly this: code from the internet, run on your laptop. You could do it because the script is public in the Template repo and does three things you can read: install Git and Node, copy your repo, open it. At home, the rule stays: read before you pipe a script into your shell.

Try it: in a fresh chat, ask What do the commands in .agents/mcp_config.json run on my laptop, and with which rights? The agent explains the MCP server your repo starts. Then open install.sh or install.ps1 in your repo and find the three things it does.

Tokens: input and output

A model reads and writes in tokens: pieces of words, about three quarters of a word each in English. There are two kinds:

• Input tokens are everything the model reads on a turn: your rules, the chat so far, the files it opened, every tool result. An agent sends the whole chat again on every turn, so the input grows with every message.
• Output tokens are what the model writes, one at a time. That is why answers take a while, and output costs several times more per token. When a model thinks before it answers, its thinking counts as output too.

An example: a chat that has grown to 50,000 tokens sends those 50,000 again with your next message, and with the one after. Twenty more short messages cost a million input tokens, although you typed only a few lines. Many tools reuse the unchanged start of a chat at a lower price, but a long chat still costs more on every turn, in time and in quota.

Three habits keep it cheap: start a fresh chat for each task, point to files instead of pasting them, and ask for short answers when a short answer will do.

Stay independent of any one model

Everything you used today was free: Antigravity, Stitch, GitHub Pages, and a weekly quota of Gemini Flash. Google paid for the tokens. On your own, today's prices are subsidised too: a plan of 200 US dollars a month buys tokens that would cost many times more at the pay-per-use rate, and nobody knows how long that lasts. Companies pay per token, and before long every team will need ways to use fewer. Few people plan for this yet; it is where things are going. Three habits keep you independent:

• Build what you still understand and can change yourself. If the model, the price or the company changes tomorrow, your site and its code must stay yours to work on. Read what the agent writes, ask it to explain what you don't follow, and keep the code simple enough that you could fix it alone. And let the agent keep the documentation: a short page that says what the site is made of, how it is built and how to change it, updated after every code change. Put that rule in AGENTS.md, so every chat follows it; the next agent, or you in a year, reads that page instead of all the code.
• Spend tokens on purpose. The smallest model that does the job (how to pick one), a fresh chat per task, and files instead of long chat histories: the habits above are already a token-saving strategy, and one that companies will ask for.
• Try a model on your own machine. Open models such as Google's Gemma run on a laptop with Ollama or LM Studio. When you have an afternoon, give one a small task from your portfolio and see how far it gets. It costs no tokens and sends no code anywhere, and for some jobs it is enough.

Context: enough, not everything

Everything the agent sees right now is its context. It has a limit, and it ends with the chat.

• Too little, and the agent guesses. It invents a project for your portfolio, ignores your design brief, and builds the generic page it has seen a thousand times.
• Enough is the task, the rules and the files it needs. Nothing else.
• Too much, and the agent gets slow and costly. It also gets forgetful: models pay most attention to the start and the end of a long context, so rules in the middle get lost. And a failed attempt still in the chat keeps steering the next answer.

Answers get worse long before the context is full: the more a chat contains, the less sharply the model attends to any part of it. Some tools summarise old messages when the context runs full. That buys room, but a summary loses detail, often the rule you cared about.

Files are the memory

The agent forgets everything when a chat ends. Your repo does not. Three kinds of files carry knowledge from one chat to the next:

• The rules, AGENTS.md: in every chat.
• The skills, .agents/skills/: long instructions, loaded only when needed. That is why four words, Start the Analyst step., were enough.
• Your work files: site/content.json, design/brief.md and docs/spec.md carried your work from Role to Role.

The pattern: think in the chat, write the result into a file, start the next chat from the file.

When a chat goes wrong

Signs: the agent forgets a rule you gave it ten minutes ago, says "let me try a different approach" again and again, or you correct the same mistake twice. Then follow the two-turn rule: if two attempts did not fix it, a third will not either. Start a fresh chat and say the task in one sentence, plus what you learned. Point to files instead of pasting them:

Agent chat

Read docs/spec.md and site/content.json.
Rewrite my bio so that it speaks to the visitors named in the spec.
Change only site/content.json, then read the change back to me.

Still stuck? Try a bigger model for that one task, or fix it yourself when that is quicker, and let the agent check your work.

Eight steps to a professional website

The last slide summed up the day. You took each step once today; on every project after it, take them again:

1. Pick the right model. The smallest, fastest one that does the job answers quickly and leaves quota for the rest of the work.
2. Plan first. Your content and a spec before any code give every later step the same goal.
3. Design your own look. Your style, your colour and one detail of yours make a site people remember.
4. One Role per chat. A fresh chat stays sharp, and your files carry the work.
5. Build on today's web. Current knowledge, such as Modern Web Guidance, gives you less code and faster pages.
6. Prove it works. The Check, screenshots and numbers show what is fixed.
7. Read before you accept or allow. The agent drafts, and it asks before it runs a command; you decide what goes live and what runs.
8. Publish through a pipeline. Read git status, then merge: live in a minute.

Check yourself

Seven questions on this page. Pick one answer each, then check them.

A Google search finds a skill that promises the perfect portfolio. Why not paste it into your repo as it is?

Skills from the web do not work in Antigravity It runs with your agent's full permissions, and its text can carry hidden instructions: read it first, and prefer skills many people use and check The agent would need a bigger model to read it

A chat has run for an hour, and the agent keeps forgetting a rule you gave it. What do you do?

Paste the rule again, three times, so it sticks Keep going: the agent will remember eventually Start a fresh chat, say the task in one sentence and point to the files it needs

Why does every message in a long chat cost more than the one before?

The whole chat goes back to the model as input on every turn Output tokens get more expensive over the day The model gets tired

What carried your work from one Role's chat to the next?

Your files: the spec, the content file and the design brief The agent's memory of the earlier chats The model, which learns from every chat

Which prompt lets you check the result?

"Make my site better." "Fix the cards, you know what I mean." "Read design/brief.md. Make the project cards easier to see. Change only site/assets/styles.css. Run node tools/check.mjs and show me the result."

What makes coding agentic rather than vibe coding?

A bigger model You plan first, take small steps, and read and check every result The agent works without asking you

Your AI plan doubles in price next month. What keeps your project safe?

Nothing: without the model, nobody can change the code Code you understand and can change yourself, and a smaller or local model for routine tasks Moving every task to the biggest model

Check my answers