You know the layers. You know the agent loop. Now we put them together and walk one request from your keyboard to a live URL — the way it actually happens on a real project like ByeBuy.

By the end of this lesson, you can trace a request through every layer, name where each kind of failure lives, and use one debugging question to find the break instead of changing things at random.

One request, end to end

The request: "Add a discount-code field to the ByeBuy checkout page so founders see the updated total before paying."

Here is the full journey:

Request → specification → agent → model
→ files → local test → Git → deployment → live product

1. Request. You state the want in plain language. At this point it is a wish, not a work order.

2. Specification. The wish becomes a checkable brief: which page, which files, what the total should do, what not to touch, and how to verify. ("Read app/checkout/page.tsx and lib/pricing.ts. Show the discounted total on change. Do not touch payments. Verify with npm test -- pricing plus a browser check.")

3. Agent. The coding agent picks up the brief inside your CLI or editor. It reads the context files, inspects the two named files, and plans its first move.

4. Model. The agent sends the brief plus file contents to the selected model. The model reasons through the pricing logic and proposes an edit and a test command.

5. Files. The agent applies the edit, creating a visible diff you can review. Nothing is real until it is on disk where you can see it.

6. Local test. The agent runs the pricing tests and you load the checkout page locally. The discounted total updates correctly. This is the first moment you have *evidence* rather than a promise.

7. Git. You commit the change on a branch, open a review, and merge. Now the work is versioned, attributed, and recoverable.

8. Deployment. The deployment platform builds from the repository and publishes. Environment variables, build commands, and domain settings all apply here — none of them lived in the chat.

9. Live product. A founder visits the checkout page and sees the working discount field. Done means done *there*, not in the chat window.

RequestSpecification: checkable briefAgent: inspect + actModel: reason + proposeFiles changed: reviewable diffLocal test: tests + browserGit: branch + mergeDeployment: build + publishLive product

Notice how late "AI" stops being the story. By step 6, your tests and browser matter more than which model you picked. By step 8, the deployment platform matters more than the agent.

Where it can break — and what the evidence looks like

Every arrow above is a failure point. Here they are with their fingerprints:

Two stories make this concrete:

• "It works on my machine but not live." Local tests pass, Git history is clean, but Vercel's build log shows a missing environment variable. The model, agent, files, and runtime all have evidence they worked. The evidence stops at deployment. Fix the deployment config; do not rewrite the component.
• "The agent changed six files and nothing is better." The diff is large, no test was run, the brief named no files and set no stop point. The evidence stops at step 2 — there was never a specification. Revert, write the bounded brief from Lesson 7.2, and run once more.

The one debugging question

When something breaks, ask:

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

Work backward from the user-visible symptom, collecting proof at each layer:

1. Live product: does the live URL show the problem? Check the deployed build log and status. 2. Deployment: did the last build succeed from the right branch and commit? 3. Git: is the fix actually committed and merged — or still sitting uncommitted on your laptop? 4. Local test: do the tests pass and does the page work locally? 5. Files: does the diff show the intended change in the intended files? 6. Agent and model: did the agent run the loop (inspect → act → verify), or did it guess without reading? 7. Brief and context: was the task bounded, were the right files named, did the agent have the context it needed?

Stop at the first layer with *no* evidence of success. That is your prime suspect. Inspect it before changing anything else — especially before rewriting code that already has passing tests.

This discipline is what the rest of the course builds on. Infrastructure lessons teach you to read runtimes and deployment. Agent lessons teach you to scope and supervise loops. Testing lessons teach you to manufacture evidence on purpose. This lesson is the map those skills hang on.

Practical exercise: diagnose three failures

Read each story. For each one, write down: (a) the most likely failed layer, (b) the next evidence to inspect, (c) what not to change yet.

Story A — The phantom fix. Priya's agent reports "done — discount total fixed." No test output is shown. Locally the total still shows $0. The diff touches four unrelated files.

Story B — The green-local red-live. Marco's checkout works perfectly at localhost:3000. The live site shows a crash page. The deployment build log mentions a missing STRIPE_SECRET_KEY.

Story C — The confident wrong answer. An agent adds a discount field but computes the discount after tax instead of before, contradicting the pricing rule already written in CONTEXT.md. The brief never told the agent to read that file.

<details> <summary>Discussion guide (try first, then open)</summary>

• A: Failed layer: brief / agent loop (unbounded task, no verification). Next evidence: the diff and a real test run (npm test -- pricing + local page). Do not change: deployment or dependencies — nothing proves the code is right yet.
• B: Failed layer: deployment configuration. Next evidence: deployment settings and environment variables for the production build. Do not change: the checkout component — local evidence says it works.
• C: Failed layer: missing context (specification named no context files). Next evidence: re-run with CONTEXT.md and lib/pricing.ts explicitly in the brief. Do not change: the model — a better brain with the same missing context guesses better-worded wrong answers.

</details>

Finish line: three written diagnoses, each with a layer, a next-evidence step, and a do-not-change-yet. If any diagnosis says only "the AI failed," rewrite it until it names a layer.

Verify it: for one of your own past AI frustrations, apply the same three lines. You should be able to point to a specific log, diff, test, commit, or setting — not a feeling.

Common failure mode: changing two layers at once ("I'll switch models *and* rewrite the code *and* redeploy"). One change, one new piece of evidence. Otherwise you will never know what fixed it — or what broke it further.

Check your understanding

1. List the full request-to-live-product path in order, without looking back. 2. Local tests pass but the live site crashes. Which two layers do you check first, and in what order? 3. Why should you inspect the evidence-stopping layer before switching to a stronger model? 4. How does this system map prepare you for later lessons on testing and deployment?

Class 07 is complete. You can now separate the model from the agent, the editor, the repository, the runtime, and deployment — and when something breaks, you know where to look first. Class 08 builds directly on that: now that you know *where* the model sits, you will learn that models are not all the same, and how to pick the right one for the job.