AICODEAgentic Programming · 67723 · 2026-7

Week 4 · lab handout

Spec-Build an Agent Traffic Monitor

3–5/11 · 90 minutes, in two halves · in pairs · your section's day and room

Goal: Build a dashboard of your agent’s live traffic by improving its spec and regenerating the dashboard from it, again and again.

Pairs, one laptop (a second one for side experiments). 70 minutes of work, then 20 minutes of discussion.

Your partner must be new. Pair up with someone you did not work with in Lab 1, 2 or 3. The lab instructor checks every pair at the start.

Before the lab — 30 minutes, on your own

Do this before the Week 4 quiz (Quiz 4 + Lab Prep): its last question asks you to paste your SPEC.md.

1. Run the proxy (10 min). Download proxy.py (Python 3, no extra packages). Start it, point your agent at it, and send a message. The proxy prints the traffic.

Claude Code 
python3 proxy.py --port 8041                      # terminal 1
ANTHROPIC_BASE_URL=http://localhost:8041 claude   # terminal 2
Codex (ChatGPT login) 
python3 proxy.py --port 8041 --upstream https://chatgpt.com/backend-api/codex   # terminal 1
codex \
  -c 'model_provider="course_proxy"' \
  -c 'model_providers.course_proxy.name="Course proxy"' \
  -c 'model_providers.course_proxy.base_url="http://localhost:8041"' \
  -c 'model_providers.course_proxy.requires_openai_auth=true'

The overrides apply to this launch only. Ignore the Claude command in the proxy’s startup hint.

Ask the agent to read a small file. In the proxy’s output, find the system instructions, the tool call, and its result (in a later request). Stuck after 10 minutes? Note the error and move on.

2. Draft a spec (20 min). With your agent, draft SPEC.md for a browser dashboard of this traffic: with the proxy running, you open a page that updates live and shows the messages going back and forth between your agent and the model, well formatted and easy to read. How easy the page is to read and use is the point, not an afterthought: while the agent works, the messages pile up fast, and you should be able to tell them apart at a glance (your prompt, the model’s reply, a tool call, its result) and follow the conversation as it grows. Let the agent raise the open decisions; don’t build yet. Paste it into the Moodle quiz (its last question), and bring it to the lab.

What the dashboard should show
  • Every request the harness sends and every reply, as they happen, newest first.
  • The parts of a request: system instructions (in full), tool definitions, the conversation so far, and the new message.
  • Tool calls, each beside its result (the result arrives in a later request).
  • The reply, including the model’s text and the tool calls it asks for.
  • Statistics are welcome (tokens per request, cost, time, tool usage), but they don’t replace the messages: you must be able to open every message and drill down into its details.
  • Anything else you find worth seeing: what changed since the previous request, filtering by tool, errors made easy to spot.

Formatting matters: long text collapsible, JSON readable, the parts of a request clearly apart.

In the lab — 70 minutes

On the laptop whose proxy works: pick one of your two drafts and commit it as SPEC.md. Then loop, as often as you can:

  1. Build. Fresh agent session, empty folder, only SPEC.md and proxy.py: build the dashboard from scratch.
  2. Run it on live traffic.
  3. Improve the spec together. Commit it with a message saying what the last build showed.

Add acceptance checks to the spec as you go, and note anything interesting in the traffic.

Never sit idle while a build runs. Use the wait:

  • Run the previous build on live traffic and study the messages.
  • Discuss the next change to the spec.
  • On the other laptop, have several agents build the same spec at once, and compare what they make.

After your first build from scratch, you may switch at any point: have the agent update the existing code to the revised spec instead of starting over. Commit before switching, and note in the history when and why you switched.

Before the discussion: have the agent write spec-history.md. Then each of you uploads two files to Lab 4 report: your final SPEC.md and spec-history.md. Both partners upload, each under their own name, even though the files are the same.

A prompt for it 
Read `git log -p SPEC.md` and write spec-history.md. For each commit of the spec:
what changed, and the reason from the commit message (what the build before it showed).
Mark the point where we switched from rebuilding to editing the code, if we did.
End with a short section "Findings in the traffic" from these notes: <paste your notes>.
If a commit gives no reason, look deeper: the builds' code and our agent sessions.
Say where each reason came from. Keep it to one page.

Discussion — 20 minutes

Show your latest build on live traffic, then:

  • Which decisions did you only discover by building?
  • What came out differently between builds, and what in the spec pinned it down?
  • What interesting things did you find in the agent’s messages?
  • When would you stop regenerating and start editing the code?

Grading

  • Prepared spec: 1 point.
  • Spec history and a working build shown live: 2 points.
  • Discussion: 1 point.

Late (over 10 minutes): −1. SPEC.md or spec-history.md not uploaded: −1. Unprepared: −1 or more.