Creating & Using Loops

Advanced · Technical & Agentic track · ~35 min hands-on + readings and quiz

← Back to the Technical & Agentic track

Run the same step over a batch — the power and the risk of compounding errors.

What you’ll be able to do

  • Set up an iterative loop over many items
  • Add checks so a small early error doesn’t compound
  • Decide when a loop should be supervised vs. fully manual

Overview

A loop applies the same step across many items — summarize each of 50 documents, code each of 200 responses. It’s where AI saves the most time and where errors scale fastest: one flawed step repeats everywhere.

The discipline is sampling and spot-checking: validate the loop on a few items, run it, then audit a random sample of the output.

Practice activities

Activity 1 · Advanced — Loop with a checkpoint

Time ~20 min · Tools ChatGPT Edu/Claude (+ R/Python if scripting)

Goal. Apply one task across many items, then audit the results.

Setup. About 10 non-sensitive items and one task. You can use 10 short 311 Service & Information Requests descriptions and classify each by issue type.

Steps.

  1. Define the task for a single item and confirm it’s right.

  2. Run the loop over all 10 (in the tool, or with a script that calls the model).

  3. Audit a sample:

    Audit a random sample of 3 of these outputs for errors and tell me what’s likely systematically wrong.

  4. Fix the instruction and re-run only the failures.

Expected result. 10 processed items plus an audit of a random sample.

Check your work. A small early error repeats across the whole batch — sampling catches it.

Common pitfalls. Don’t trust a loop just because it ran. Higher stakes mean reviewing every item, not a sample.

Stretch (optional). Add a confidence flag so low-certainty items get human review.

Activity 2 · Advanced — Decide the guardrail for scale

Time ~12 min · Tools ChatGPT Edu/Claude

Goal. Set the rule for when a loop needs full human review.

Setup. A real task you’d loop.

Steps.

  1. Write the rule: review every item vs. a sample, tied to stakes and reversibility.

  2. Pressure-test it:

    Give me a scenario where sampling would be dangerous for this task.

  3. Decide and document.

Expected result. A documented review rule for looped tasks.

Check your work. Would you defend this rule if one bad output reached a real decision?

Common pitfalls. Sampling is fine for low-stakes work; never for irreversible or rights-affecting outputs.

Stretch (optional). Add logging so you can reconstruct what the loop did (see Reproducible AI).

Activity 3 · Advanced — Script, run, and audit the loop in one Claude Code session

Time ~25 min · Tools Claude Code (terminal) + Python or R

Low Risk Data only. Claude Code is a consumer/PI-purchased tool, not Drexel-supported — use it only with Low Risk (public) data like these 311-style descriptions unless you have separate approval.

Goal. Have the agent write, run, and first-pass audit the entire batch loop in one session — you only verify the final output.

Setup. Open Claude Code in an empty folder. You’ll use 10–12 fabricated 311-style request descriptions (modeled on public 311 Service & Information Requests) — no real resident data. Copy this batch into a file called requests.txt, one per line:

pothole on 5th street near the intersection graffiti removal request on retaining wall broken streetlight near the elementary school illegal dumping behind apartment building missed trash pickup for the third week abandoned vehicle parked on residential block water leaking from fire hydrant onto sidewalk loud construction noise starting before 6am tree branch down blocking the bike lane rat sighting in vacant lot next door stop sign knocked over at the corner dark corner by the park — something should be fixed there

(The last one is deliberately vague — expect the audit to flag it.)

Steps.

  1. Ask Claude Code to build and validate the classifier on a few items first:

    Write a Python script that reads requests.txt and classifies each line by issue type (e.g., Street Repair, Sanitation, Lighting, Vandalism, Noise, Other) using simple keyword rules. Run it on just the first 3 lines and show me the results before doing the full batch.

  2. Confirm the three test classifications look right, then have it run the full batch and write results to classified.csv.

  3. Have the agent audit its own output:

    Pull a random sample of 4 rows from classified.csv. Print each description, its assigned category, and whether you’re confident in that classification. Flag any you’re unsure about and say what’s likely systematically wrong with the rules.

  4. Based on what the audit flags (the vague “dark corner” item, or a keyword rule that’s too greedy), ask it to fix the logic and re-run only the flagged/failed items, not the whole batch. Then open classified.csv yourself and spot-check 3 rows by hand — the human does the final verification.

Expected result. A working script, a 12-row classified CSV, an agent-generated audit of a random sample with at least one item flagged as low-confidence, and a targeted re-run of just the failures.

Check your work. Did the agent actually flag the ambiguous item, or did it confidently misfile it? If it claimed 100% confidence on everything, its self-audit failed — that’s the lesson. Your manual spot-check is the checkpoint the agent can’t replace.

Common pitfalls. An agent that writes, runs, and grades its own work will be biased toward passing itself — treat its audit as a first pass, never the final sign-off. And don’t let convenience creep the data upward: this workflow is approved for public/Low Risk data only.

Stretch (optional). Ask Claude Code to add a confidence column and automatically route every low-confidence row into a separate needs_human_review.csv, then compare its uncertainty flags against your own judgment.

Check your readiness

Answer these, then check — your score suggests whether to dive in or skim the readings first.

Useful resources