Module 3: Agentic Coding: Build#

Using agents to write real code, and what it takes to make that code good: workflows that work (plan first, small steps, verification loops), where AI-generated code fails on security, model tiering, and accountability: you own what the agent ships. The lab closes Day 1 and kicks off the class arc: everyone builds the same networked app to spec, it freezes overnight, and Day 2 attacks it.

Questions this module answers#

• What workflow reliably gets good code out of an agent?
• Where does AI-generated code fail on security, and are the failures predictable?
• How do I steer an agent toward secure code — and how far does that get me?
• Why build with a small model and review with a stronger one?
• How do I review code I didn’t write — and why am I still the engineer of record?
• Who is accountable for code an agent wrote?

Slides#

Lab 3.1: Build ShareBox (60 min + whatever the day has left)#

Goal#

Ship a working networked app to spec using the small model in pi. Practice the plan/decompose/verify workflow from lecture. Your app freezes overnight and becomes raw material for Day 2: one of the codebases your own security-evaluation system hunts in Lab 6.1.

This lab is deliberately the last block of Day 1 and doubles as the schedule’s sponge: the core build is time-boxed to an hour, and the free-form build absorbs whatever time the day has left. Finish early relative to the room? Keep building — tests, polish, deploy hygiene — until time is called.

Provided#

• The ShareBox spec: spec.md in the lab directory (labs/03-sharebox/), identical for everyone
• The instructor’s functional test suite (the answer key): tests/test_sharebox.py in the same directory
• A deploy convention: your app must listen on port 8080 on your instance’s VPC-internal address

Note: at the start of this module (late Day 1) the instructor opens port 8080 between all student VMs across the VPC. Your app is reachable by the whole class from the moment it’s up; the VPC’s lack of internet egress is what makes running it deliberately soft acceptable.

The spec#

ShareBox is an HTTP file-sharing API with user registration/login, file upload/download, share links, and an admin endpoint that lists users. These features are chosen because they reliably produce classic vuln classes when built fast by a small model.

Rules#

• Build to the spec, nothing more.
• Do not security-harden beyond what the spec requires; that tension is the point of Day 2.
• Small model only.

Steps#

1. Read the full spec before touching pi. Pick a stack (anything the VM can run).

2. Have pi produce a build plan first: endpoints, data model, order of implementation. Review the plan and cut anything not in the spec.

   Hint: what to cut from the agent’s build plan (step 2)

   Small models pad plans with things the spec never asked for: password-strength rules, email verification, rate limiting, an admin UI, containerization. Cut all of it. The spec is the whole contract, and every extra feature is time you don’t have, plus attack surface nobody asked for. Conversely, make sure the plan explicitly covers every spec endpoint; models often omit the admin endpoint.

3. Build incrementally: one feature at a time (auth, then upload/download, then share links, then admin), running the relevant slice of the test suite after each.

   Hint: common test-suite failure clusters (step 3)

   Three clusters cause most red runs: auth (the suite registers, logs in, and reuses the token/cookie exactly as your app issued it: mismatched header names or cookie flags break everything downstream), upload (multipart form handling and preserving the original filename), and share links (the suite fetches the link unauthenticated: if your share route requires login, it fails). Read the failing test’s name and request before touching code.

   Hint: stuck at the 30-minute mark (step 3)

   If the test suite is mostly red at halftime, stop debugging and restart cheap: pick the most boring stack you know (e.g. Flask + SQLite + session cookie), give pi the spec and the failing test names, and rebuild feature-by-feature, running the test slice after each. A boring green app beats a clever red one; the fallback is the instructor’s reference app.

4. When the full test suite passes locally, deploy on port 8080 and tell the instructor.

5. The instructor verifies your app against the suite and freezes it: no further changes, tonight or tomorrow. Freezing means your app source is copied to the class bucket, $CLASS_BUCKET (your values are shown in the class portal tab). It stays frozen overnight; on Day 2 it’s one of the targets you point your Foundry implementation at in Lab 6.1.

Done when#

Your app is frozen (or time is called on Day 1). If the build doesn’t come together, the instructor deploys the reference app on your VM instead, so you still enter Day 2 with a ShareBox of your own.