The Crucible
Everything you built today assumed you knew what was leaving your machine. With AI coding agents (Claude Code, Copilot, Cursor) that assumption stops holding: they gather context for you, and at Stanford that comes with terms of service, data residency, and IRB implications most tutorials skip. This room makes it explicit: what these tools send, where it goes, and when the right answer is “not with this data.”
🗡️ Main Quest
Quest: Understand how AI coding agents work at Stanford: where LLMs currently stand, how researchers are actually using them, and what happens to your data when you do.
This is a discussion block. No code. Bring your questions.
Models
A model reads language (and increasingly images) as tokens, chunks a little smaller than a word. Rule of thumb: ~750 words is about 1,000 tokens.
The context window is how much you can fit in at once, now a million tokens or more. Every answer is shaped by exactly two things: what the model learned in training, and what’s in that window right now.
What are AI coding agents?
AI coding tools (Claude Code, Copilot, Cursor) are harnesses wrapped around a model. They let it read your files, run commands, and use tools on your behalf. To do that, the harness gathers context from your machine and sends it to a remote model.
Look back at the diagram: you pick every piece. That was true in The Oracle’s Chamber, where you wrote both prompts yourself and knew exactly what the model received. A coding agent fills that window for you, with:
- The file you’re editing
- Nearby files the tool has indexed
- Your chat history this session
- Sometimes terminal output, error messages, or clipboard contents
You hand-picked none of it, and it leaves your machine on every request (for autocomplete tools, every time you pause typing), often without your seeing what was sent.
How researchers are actually using this
Three patterns dominate at Stanford right now. Two treat AI as an instrument; the third treats it as the object of study.
1. Reading unstructured text at scale. The most common by far. A researcher has thousands of dense documents (filings, earnings calls, court opinions, contracts, clinical notes, news archives, open-ended survey responses) holding evidence that no structured dataset captures. The model reads them and returns fields you can actually analyze.
The important nuance: this usually isn’t a fishing expedition. The researcher already has a hypothesis from their study, and the model is how they test and validate it across a corpus too large to hand-code. That reframes the work. You aren’t asking a model what to think, you’re asking it to apply your coding scheme consistently across 10,000 documents, which is also why validation matters so much: an inconsistent coder silently corrupts your result. Today’s Form 3 room is that pattern at a scale of one, and the Day 2 Challenge builds the checking half, where a second model reviews each call and the genuinely contested ones get routed back to you.
2. Building and automating the pipeline. Researchers use coding agents to write the plumbing around pattern 1: the batch loop, the retry logic, the SLURM script, the plots. The researcher stays the designer and reviewer; the agent handles the parts that are tedious rather than intellectual. You’ll do exactly this on Day 3 when you have Claude Code write a SLURM job.
3. Studying AI itself. A growing body of work here treats the model as the subject: how humans interact with AI systems, whether people over-trust or under-trust them, and how AI is reshaping the workforce, tasks, and labor markets. If your research is about AI rather than assisted by AI, the governance picture flips. Your participants are human subjects again, so IRB and consent come back to the front, and the data you protect is theirs, not the model’s.
Class discussion: Which of the three is closest to your own work? For pattern 1, what would a wrong extraction cost you: a noisy estimate, or a retracted claim? That answer determines how much validation is enough.
AI services at Stanford
Stanford runs a growing catalog: chat interfaces, the API gateway you used today, cloud AI (AWS Bedrock, Azure OpenAI, Google Vertex), and locally hosted models. The list changes, so browse it rather than memorize it: Stanford AI Services.
Two very different jobs hide behind “using AI,” and they carry different risks.
Job 1: an LLM analyzes your data. Your data is the input, the way you fed filing text to the model in The Oracle’s Chamber. One question decides everything: is this data allowed to go where this model runs?
| Risk level | Examples | Stanford API Gateway | Local model (Yens) | Third-party tool/API |
|---|---|---|---|---|
| 🟢 Low | Published papers, SEC filings, open datasets | ✅ | ✅ | ✅ |
| 🟡 Moderate | Unpublished research, FERPA records, DUA-covered data | ✅ | ✅ | ❌ unless approved |
| 🔴 High (incl. PHI) | SSNs, account numbers, health records, credentials | ✅† | ❌* | ❌ |
*The Yens are approved for Low and Moderate risk data, not High. Running the model locally keeps your data on the machine, but that only helps if the data is allowed on that machine in the first place — and High Risk data isn’t allowed on the Yens at all. High Risk work belongs on a system cleared for it, which at Stanford means Carina (on-premises, Slurm-based) or Nero GCP (secure Google Cloud) rather than the Yens; sort that out before you copy anything anywhere.
†API Gateway only. The Playground chat window runs under the same Stanford contract but stops short of PHI, so when PHI is involved reach for the API, not the chat box.
Two separate questions, and people routinely collapse them into one. Is this data allowed on this machine? and is this data allowed to go to this model? A local model on the Yens answers the second question well and says nothing at all about the first. The Yens are a Moderate-risk environment, so “I’ll just run it locally” is not a way to work with High Risk data — it’s a way to put High Risk data somewhere it shouldn’t be.
The gateway clears every row because it runs under Stanford’s contract rather than a vendor’s consumer terms. The risk usually isn’t your data, it’s reaching for a convenient tool outside Stanford’s walls.
DUA and IRB still govern. Either can be stricter than Stanford’s classification, for example “data may not leave these systems.” Read yours; when a DUA restricts where data is processed, the local path on the Yens is the safe default.
Job 2: an LLM helps you build the pipeline. Pattern 2 above. Your data isn’t meant to be the input, but it slips in anyway: a data file left open, a hardcoded path, a comment quoting a real record. The risk isn’t what you chose to send, it’s what the harness sweeps up around it, and the next section keeps it in check.
The practical rule: if you wouldn’t paste it into a Google Doc, don’t paste it into an agent’s context.
Class discussion: The SEC filings you processed today, which risk level? What changes if you switch to ChatGPT? And if the filings contained unreported insider PII, which paths would still be allowed?
Keeping data out of agent context
- Never hardcode secrets, keys, or paths containing PII in files open in an AI tool
- Keep credentials in
.env, and.envin.gitignore - Close files containing restricted data before using a coding assistant
- Exclude
data/andresults/from the tool’s workspace or project settings, which control what gets indexed - A coding agent calling a third-party endpoint (Claude Code to Anthropic, Copilot to GitHub) is not covered by Stanford’s agreements, so the same rules apply. “I’m just asking for coding help” doesn’t change where your data goes.
Class discussion: You’re using Claude Code to write a SLURM script. It references a path to a data file. Does the model see the data? What if the script has a hardcoded API key? What about a comment mentioning a patient’s condition?
What it costs
Risk decides what you may send. Cost decides what you can afford to send at scale.
You met the headline in The Stanford AI Playground: the chat window is free, the API Gateway is metered. Here is where the meter actually runs.
Three levers, then, before you scale a run:
| Lever | The decision you’re making |
|---|---|
| How much you send | The [:4000] slice in The Oracle’s Chamber was a cost decision as much as a context-limit one |
| Which model | The cheapest and most expensive ids on the gateway are not close |
| Whether it reasons | A three-word answer can cost thousands of output tokens you never see |
Rates change, so look them up rather than trusting a number in a slide deck: AI API Gateway rates.
AI coding agents: a plan, not a meter
There’s no meter on this side at all. Claude Code, Copilot, and the rest are licensed, and everyday use is free to you as a Stanford affiliate; need more than the standard allowance and your PI requests an upgraded plan — a fixed cost paid up front, not a per-keystroke charge.
| API Gateway | Coding agent | |
|---|---|---|
| Billing | Per token, per model | Flat plan; standard tier free |
| A runaway loop | Spends real money, immediately | Burns your allowance, then stops |
| Scaling up | Costs more, in proportion | Needs a request through your PI |
| What to plan | Measure on a sample, then multiply | Ask early; approval takes time |
Neither is “the cheap one.” The gateway is nearly free for a small job and expensive for a careless one; an agent plan costs the same whether you lean on it or never log in.
Same answer, 22× the bill
Models such as o1, o3-mini, deepseek-r1, and the gpt-5 family reason internally before answering. One trick question, three models, all three correct in about forty words — here is what each one charged:
Nothing is broken here; that’s how these models work. The trap is reading cost off the length of the reply, so read usage instead. If you want to watch it happen on a live call, the Pay for Thinking You Never See side quest in The Oracle’s Chamber runs exactly this comparison.
Class discussion: You budget a 10,000-filing run by timing 10 filings and multiplying. What could make the real bill come in far higher? (Think: a longer filing, a model swap, a retry loop, a reasoning model.) Which of those would you catch before spending the money, and how? Now ask the same question about a semester of Claude Code use, where the failure isn’t an invoice but running out of allowance the week before a deadline.
Designing defensible research pipelines
A pipeline is defensible when a skeptical colleague can audit it end-to-end. Before you scale:
- Classify your data. Which risk level? Which tool does that allow?
- Cost it on a sample. Measure
usageon a handful of real records, then multiply, before you launch the full run. - Validate your outputs. A Pydantic schema plus a manual spot-check on 10 to 20 examples.
- Document your decisions. A README covering what the pipeline does, what model, what prompt version, and what validation was run.
- Keep humans in the loop for high-stakes steps. Extraction is fine to automate; acting on that extraction may not be.
🧠 Skills Learned
- You can describe what AI coding agents send to remote servers and what that means for research data
- You know how to configure AI tools to exclude sensitive data from their context
- You can classify any dataset by Stanford’s risk level and choose the right tool without guessing
- You can tell the two billing models apart: the API Gateway meters you per token, while coding agents run on a plan, and you know which failure each one sets you up for
- You know that reasoning models charge for output you never see, so the length of a reply is no guide to its cost
- You can place your own work among the ways researchers use AI, and say whether the model is your instrument or your subject
- You can design a validation step proportional to the stakes of the task
- You can write a pipeline that a skeptical colleague could audit: classified data, documented decisions, outputs you actually read