Skip to content

Lab 2: Direct the Agent and Deploy
Session 2 · Thu, Nov 12
Time About 55 minutes in class, 45 minutes after
SDLC phase Planning: setting the rules the build follows
Reading Directing the Agent
Due Tue, Nov 17, start of class · 25 points
{ .lab-meta }

What you will learn

  • How to build in small, checkable steps instead of one giant prompt
  • How to write a CLAUDE.md so the agent knows what it cannot see in the code
  • How to use plan mode, and how to set a permission rule the agent cannot ignore
  • How to deploy a web app to a public URL, with every push redeploying it

Part A: One giant prompt versus small steps (15 minutes)

Make a folder and start Claude Code there:

mkdir -p labs/lab-02/one-shot && cd labs/lab-02/one-shot && claude

Paste exactly this, and nothing more:

Build me a problem tracker web app with all features. Use plain HTML, CSS, and JavaScript in a single index.html, and save data in the browser's localStorage.

Open the result (open index.html on macOS, start index.html on Windows). Write down two things it built that you did not want and two things you wanted that it did not build. Then exit Claude (/exit).

Now build it again, the way Conversational Coding describes. Make a second folder, labs/lab-02/problem-tracker, start Claude there, and send these one at a time, checking the app in the browser after each:

  1. I want to track problems I notice throughout the day. Start simple: a way to add a new problem with a title and description, shown in a list. Use plain HTML, CSS, and JavaScript in a single index.html, and save data in localStorage.

  2. Add a timestamp so I know when I captured each problem.

  3. Now I want to rate each problem on frequency (daily, weekly, monthly, rarely). Add a dropdown for that.

  4. One change of your own.

Part B: Write a CLAUDE.md (10 minutes)

Claude starts every session knowing only what it can see. CLAUDE.md is where you write what it cannot work out from the code: decisions, constraints, and traps.

  1. In the problem-tracker folder, ask Claude to draft one:

    Create a CLAUDE.md for this project. Include a short project overview, the tech stack, and a Development Notes section. Under Development Notes add: "No frameworks and no build step: everything stays in index.html." and "Never store data on a server; localStorage only."

  2. Read it. Delete anything that just repeats what the code already shows. Add one rule of your own.

  3. Test it. Type /exit, start a fresh claude session in the same folder, and ask:

    Add a search box that filters problems by title. Use whatever library you think is best.

    Does Claude follow your CLAUDE.md and avoid adding a library? Write what happened in your reflection.

Part C: Plan mode and a permission rule (10 minutes)

Plan mode. Press Shift+Tab until the status line shows plan mode (or type /plan), then ask:

Plan how to add a "status" field (open, in progress, solved) and a way to filter by status. Do not change any files yet.

Read the plan. Ask for one change to it. When it is right, approve it and let Claude build it. Save the final plan text in labs/lab-02/plan.md.

A permission rule. Advice in CLAUDE.md can be ignored; a permission rule cannot. Ask Claude:

Add a deny rule to .claude/settings.json in this folder so that you can never run rm -rf or git push --force. Then show me the file.

Then ask it to run rm -rf test-folder and record what happens.

Part D: Deploy to the internet (15 minutes)

  1. Commit and push your course repo (ask Claude to do it).
  2. Go to vercel.com, choose Add New → Project, and import your course repo.
  3. Under Root Directory, click Edit and choose labs/lab-02/problem-tracker. Leave the framework as Other. Click Deploy.
  4. Open the URL Vercel gives you (something like problem-tracker-abc.vercel.app) on your laptop and on your phone.
  5. Make one small visible change (for example, the page title), commit, and push. Watch Vercel redeploy automatically. Refresh the live site.

Put the live URL at the top of labs/lab-02/reflection.md.

Why your data does not follow you to your phone

The problems you add on your laptop do not appear on your phone. localStorage lives in each browser, on each device. A shared database fixes that, and you will add one in Lab 6. Hold on to this observation for Anatomy of an Application.

Reflection

Write labs/lab-02/reflection.md, in your own words:

  1. Live URL.
  2. Compare the one-shot build and the step-by-step build. Which would you rather maintain, and why?
  3. Did the fresh session follow your CLAUDE.md? What does that tell you about where to write down decisions?
  4. What is the difference between a rule in CLAUDE.md and a rule in settings.json? When would you need the second kind?

Turn in

Submit the link to labs/lab-02/ on Canvas. It should contain:

  • one-shot/ and problem-tracker/ (with its CLAUDE.md and .claude/settings.json)
  • plan.md
  • reflection.md with your live URL at the top

How larger systems do this

At large companies the equivalent of your CLAUDE.md is spread across onboarding docs, architecture decision records, coding standards, and code owners, and the permission rule is a branch protection setting that no one, including senior engineers, can bypass. Read What This Looks Like at Full Scale for how one company runs hundreds of agents with the same three controls you used today: what the agent knows, what it may do, and how its work is checked.