In Class 06 you learned to operate a CLI with AI: open a project, give a bounded task, read the output, approve carefully. That skill works. Now we are going to explain *why* it works — by naming every part of the machine you were actually using.

Because when someone says "I asked AI to build a website," that sentence hides about six different systems doing six different jobs.

By the end of this lesson, you can explain what each layer does, identify each layer in a real project, and stop blaming "the AI" when something breaks.

"AI built my website" hides the real system

Here is what that sentence usually means in practice:

You typed a request. A coding agent read your files. It sent pieces of your project to a selected language model. The model sent back reasoning and proposed edits. The agent applied those edits, ran commands, showed you output. You committed the result to a repository. A deployment platform built it and put it on the public internet.

The model is one part of that chain. An important part — but only one part.

Think of it this way: the model is the chef. The rest of the system is the kitchen, the pantry, the recipe book, the stove, and the restaurant. A great chef with no ingredients and no stove still cannot serve dinner.

The seven layers, in plain language

Here are the terms you will use for the rest of this course. Plain language first, then the real term so you can talk to other builders.

You — the director. You decide what should exist, what good looks like, and what is safe to change. No layer above you. If the brief is vague, everything downstream guesses.

Chat interface — the conversation window. ChatGPT, Claude, or the chat panel inside an editor. Good for questions, explanations, and drafts. It cannot reliably see your whole project, run your code, or verify its own work unless something connects it to those things.

Coding agent — the operator with hands. Codex, Claude Code, Cursor's agent, OpenCode. It takes your task, reads files, calls tools, edits code, runs commands, reads the results, and repeats. This is what turns a suggestion into an action.

Model — the reasoning engine. The large language model the agent sends your task to: GPT, Claude, Gemini, Qwen, DeepSeek, and others you will compare in Class 08. It produces reasoning, code, and proposed tool calls. It does not itself touch your files. The agent lets it act.

IDE or editor — the workbench. VS Code, Cursor, or the terminal where you review changes. This is where you see diffs, read errors, and decide what to keep. If you are vibe coding, this is also where you watch the agent work in real time. Read its comments as it goes — very often an LLM will drift onto an unintended tangent. When you see that happen, stop it early. A quick stop now saves you from having to undo a pile of work or untangle unintended outcomes later.

Repository — the shared memory. Usually Git and GitHub. The versioned record of every file, every change, and who made it. If it is not committed, it is not saved in any way the team can trust.

Runtime — the kitchen where code actually runs. Node.js on your laptop, Python in a container, the browser rendering your page. Code that looks correct but fails here has a runtime problem, not a writing problem.

Deployment — the public restaurant. Vercel, Netlify, Cloudflare, a VPS. It takes your repository, builds it, serves it to visitors, and holds the configuration — domains, environment variables, build commands — that your laptop does not.

The full path, end to end

You → task brief → coding agent → selected model
→ files / terminal / tools → local app → deployment

Said as a sentence: you brief the agent, the agent consults the model, the model proposes actions, the agent executes them against your files and terminal, you verify the local app, and deployment publishes it.

You: brief + approvalCoding agentSelected model: reasoning + proposalsProject files, terminal, toolsLocal app: runtimeDeployment: live site

A concrete ByeBuy example

Take the ByeBuy classroom site itself:

• Markdown context (CONTEXT.md, specs, handoffs) tells the agent what ByeBuy is, who it serves, and what is already decided.
• An AI coding agent (Codex, Claude Code, or OpenCode) reads those files and the repository, then proposes and applies edits.
• A selected model does the reasoning behind each proposal.
• GitHub holds the versioned truth. Every change is a commit on a branch before it touches the main line.
• Vercel takes the repository, runs the build, and serves the live site at byebuy.ai.
• Your browser is the final runtime: what the visitor actually sees.

If the live homepage shows yesterday's headline after you merged a fix, the model did its job, the agent did its job, Git did its job — the deployment layer did not rebuild, or your browser cached the old page. Saying "the AI failed" would send you hunting in entirely the wrong place.

Why "the AI failed" is too vague to act on

"The AI failed" is a feeling, not a diagnosis. It gives you nothing to inspect and nothing safe to change.

Replace it with one question you will use for the rest of this course:

Which layer has evidence that it worked, and where does that evidence stop?

Files changed correctly? The agent and model layers worked. Local app runs? The runtime works. Deployed site wrong? Look at deployment. Nothing was ever written to disk? Look at the brief, the context, or the agent's permissions.

Each layer leaves evidence: diffs, terminal output, test results, commits, build logs, a running local page, a live URL. Follow the evidence until it stops. That is where your problem lives.

Practical exercise: label your own stack

Pick one project you have built or use regularly — a site, a script, even a Class 06 CLI exercise.

On one page (paper or Markdown), label each layer for that project:

1. Who briefs the work? (probably you) 2. Which agent or chat interface do you use? 3. Which model is selected? 4. Which editor or CLI harness? 5. Where is the repository, and which branch holds the truth? 6. What runtime runs it locally? 7. Where is it deployed, if anywhere?

Finish line: you have seven labeled lines, each with a real name (e.g., "Runtime: Node 20 on my MacBook" — not "my computer"). If any line is blank or "not sure," that is a gap in your mental model worth closing before the next lesson.

Verify it: point to one piece of evidence per layer — a screenshot of the agent, a commit on GitHub, a local URL that loads, a live URL. No evidence, no claim.

Common failure mode: mixing up the agent and the model ("I use Claude Code, so the model is Claude Code"). Claude Code is the harness. The model inside it is a specific Claude release. Naming them separately is the whole point.

Check your understanding

1. What does the model produce, and what does the coding agent add that the model alone cannot do? 2. Where does versioned truth live — in the chat window, the local files, or the repository? 3. Your local app works but the live site shows an old version. Which layer do you inspect first, and why? 4. Why is "the AI failed" not a useful bug report?

Next, we open up the operator itself: what the coding agent actually does, step by step, after you press enter.