All in One View
Content from What Is Agentic Coding?
Last updated on 2026-09-16 | Edit this page
Estimated time: 15 minutes
Overview
Questions
- What distinguishes an agentic coding tool from autocomplete or a chat assistant?
- What is inside an agent, and what does the harness do that the model does not?
- Which tool should I pick, and how much does the choice matter?
- Is more autonomy better?
Objectives
- Define agentic coding and contrast it with chat-based and autocomplete-based AI assistance.
- Describe an agent as a model plus a harness plus tools running an agent loop.
- Place a request on the spectrum of autonomy, from a single edit to a whole project.
Definition
Agentic coding is a software-development approach in which AI agents plan, write, test, debug, and revise code with limited human intervention.
The word “agent”
The term is now applied to many products that only have a chat interface, so it needs a definition. In computer science an agent is a system that takes actions in an environment and observes the results, in pursuit of a goal. A chatbot produces text and the user acts on it. An agentic tool acts on its own: it edits files, runs commands, reads the output, and decides what to do next. The distinguishing question for any tool described as an agent is whether it acts or only advises. In agentic coding the tool acts continuously, which is the source of both its usefulness and its risk.
An AI coding agent is a persistent, tool-enabled process driven by a large language model. Earlier AI code assistants (the first GitHub Copilot, ChatGPT in a browser tab) worked in a suggest-and-accept loop, with the user carrying context in and code out and running everything by hand. An agent can instead:
- Read and navigate a codebase, rather than only the snippet it was given.
- Create and modify files, several at a time.
- Run terminal commands.
- Execute tests and inspect the failures directly.
- Search documentation.
- Develop and follow a plan.
- Iterate on its own work until the task is complete or it is blocked.
Typical requests include fixing a bug, adding a feature, refactoring existing code, writing and running tests, reviewing a pull request, investigating a failing job, and building a small application from a specification. The same capabilities give the tool access to the user’s files, shell, and any credentials left on disk, so an unmanaged agent can do real damage. The balance between capability and control is the subject of this lesson.
The spectrum of autonomy
The same tool can be used at different levels of autonomy. Three requests, from tightly directed to fully delegated:
- “Write this for loop for me.” One function; the user reads every line.
- “Implement the method stubs in this file.” A bounded task with a clear completion criterion; the agent does some planning and the user reviews the diff.
- “Build the whole service from scratch; do all the planning yourself.” The agent makes many decisions the user never considered, and the user reviews a project.
Across the three, the more autonomy you grant, the more of your judgment must be encoded in advance, in the prompt, in project context files, and in tests, and the more review is required afterwards. This principle recurs throughout the lesson. Most of the workshop concerns the middle of the spectrum: bounded tasks with a plan and a check.
More autonomy is not automatically better
A given task (add a utility function, write tests, open a pull request) can be done at any point on this spectrum. Moving toward autonomy reduces interruptions during the work and increases the review burden after it. The appropriate level depends on the task:
- Sensitive work or an unfamiliar codebase: interactive, with guardrails. The interruptions are useful.
- A quick question, brainstorming, or explaining an error: plain chat is sufficient.
- A well-scoped, clearly described task in a repository with good tests: delegation works, because the specification and the tests carry the intent.
The tasks researchers are most reluctant to delegate are usually the ones whose results they would find hard to check, rather than the ones that are hardest to do. That judgment is sound. The autonomy you can grant is limited by how well you can verify the result, which is the subject of the verification episode.
Inside an agent: model, harness, tools, loop
Many tools are now built for agentic coding, including Claude Code, Codex, GitHub Copilot’s agent mode, OpenCode, Cursor, and a growing number of open-source harnesses. Most can use several underlying language models. Two components should be distinguished:
- The model provides reasoning and code generation.
- The harness is the application around the model. It provides what the model needs to operate on a real codebase: file-system access, terminal and test execution, context management, planning and task tracking, tool integrations, memory, permission controls, and the loop that connects them.
The harness runs an agent loop: request, understand, plan, act, observe, revise, repeat. On each turn the model decides what to do next, the harness executes it (edits a file, runs the tests), and the result is added to the model’s context. In summary: agent = LLM + harness + tools + agent loop.
The same structure describes what you can influence. The prompt is the wording of a single instruction. The context is everything the model sees in its window, including the project’s instruction files. The harness is the system around both. Each layer contains the one inside it; the later episodes on prompting and context work at the two inner layers, and the safety episode’s limits are set at the outermost.
More advanced harnesses add an orchestrator–worker pattern, in which a primary agent divides a larger problem into tasks and delegates them to subagents that work in parallel on research, implementation, testing, and review. Multi-agent workflows became common toward the end of 2025. They occupy the far end of the autonomy spectrum and are the hardest to review.
Choice of tool
As of September 2026 the leading agents are close in capability. On Terminal-Bench 2.1, a benchmark of realistic command-line tasks, Claude Code and Codex score within about a point of each other, and GitHub Copilot uses the same Claude and GPT models. The harness affects the result (the same model scores differently in different agents), but the gap between the leading commercial tools is small.
Open-weight models are a viable option and are improving. The top Terminal-Bench score at the time of writing belongs to an open-weight model (DeepSeek V4.1 Flash), but at several hundred billion parameters it requires a cluster. Open-weight models that fit on a single GPU trail the frontier by tens of points. Closing that gap is an active research problem, and running a model yourself raises trust questions covered in the trust episode.
A table of tools would be out of date within months. The setup page lists routes to a working agent, including free ones (Copilot’s education tier, OpenCode with free models) for participants without a paid plan or workshop credits.
GitLab and other hosts
Everything interactive in this lesson is host-agnostic. An agent working on a checkout uses ordinary git, so GitHub, GitLab (including self-hosted), and Bitbucket behave the same. Only the cloud-agent surfaces (assigning issues to agents, cloud sandboxes) are GitHub-specific at present. Self-hosting the repository does not change where inference runs: code still goes to the model provider, so the data-policy rules apply.
- Agentic coding: AI agents plan, write, test, debug, and revise code with limited human intervention. An agent acts; a chatbot advises.
- Agent = LLM + harness + tools + agent loop. The model reasons; the harness supplies files, a terminal, tests, permissions, and memory.
- Requests range from a single edit to a whole project. More autonomy shifts effort from approving actions to specifying intent in advance and reviewing results afterwards.
- The leading tools are within a point or two of each other. Use what you have access to, and learn the principles.
Content from Safety and Security: Limit What the Agent Can Access
Last updated on 2026-09-16 | Edit this page
Estimated time: 28 minutes
Overview
Questions
- What can an agent access on my machine, and why does that matter?
- Which protections are enforced limits, and which are requests the model may ignore?
- How do I keep credentials and sensitive or restricted data away from AI tools?
- How do I start an agent on my own project safely?
Objectives
- Apply institutional data policies before pointing an agent at any project.
- Explain prompt injection and why anything an agent reads is untrusted input.
- Limit an agent along six axes: what it can reach on the network, where it runs, which commands it may run, which credentials it can see, what it can commit, and whom you trust.
- Distinguish instructions, which influence behavior, from permissions, which constrain it.
- Keep secrets out of local plaintext files, loading them at runtime from a password manager.
- Start an agent session on your own repository using a cloud VM, plan mode, a branch named for you, and no keys on disk.
Institutional GenAI policies
AI tools are not exempt from institutional data rules, and the rules are changing quickly. At UW–Madison:
- Follow all UW–Madison, UW System, and Board of Regents GenAI policies.
- DoIT summarizes policies and vetted tools at it.wisc.edu/ai. If you are unsure of your data’s classification, contact a data steward through that page, or your data governance office, IRB office, or IT office.
- Do not enter sensitive or restricted information into unvetted AI services. This includes student records (FERPA), health data (HIPAA/PHI), unpublished research, CUI, export-controlled data, and anything under a data use agreement (DUA) that prohibits third-party processing.
Code and prompts are sent to the model provider’s servers for inference. Every control in this episode protects your machine; none changes where the repository contents go.
What an agent can and cannot do
Risk management starts from an accurate picture of the tool:
| A GenAI agent can | A GenAI agent cannot |
|---|---|
| Write or translate code | Work safely with sensitive or restricted data or secrets |
| Explain basic logic | Explain human logic, such as why your field does something a particular way |
| Execute validation steps you specify | Determine all the necessary validation steps |
| Run commands from your terminal, with the attendant risk of prompt injection and leaked credentials | Prevent all harmful commands from running (hence the VM) |
The last row is the one most often underestimated. An agent launched
from a terminal or IDE runs with the user account’s full filesystem and
shell access. It can read SSH keys, .env files, and notes.
Agents also scan for context as part of their normal operation, so a
credentials file in the working directory is simply more context.
The threat: prompt injection
An agent treats the text it reads as instructions. A README, an issue, a web page, or a dependency’s install script can contain commands the agent will follow. This is prompt injection.
Two documented cases:
- GitHub MCP, May 2025. Invariant Labs showed that a malicious issue in a public repository could direct an agent with GitHub access to leak data from the user’s private repositories.
- Nx on npm, August 2025. A compromised package’s install script prompted the victim’s own Claude Code, Gemini CLI, or Amazon Q to search the machine for secrets. Thousands of credentials were leaked to public GitHub repositories. Wiz’s analysis found that Claude refused about a quarter of the time; model refusals reduce the risk but do not remove it.
Simon Willison’s “lethal trifecta” identifies the combination to avoid: access to private data, exposure to untrusted content, and a channel to send data out. Removing any one of the three defeats the attack. Injection is the threat; the six limits below determine how much damage it can do.
Six limits on what the agent can access
- What it can reach on the network. An egress allowlist, not the whole internet.
- Where it runs. A disposable cloud VM, not your laptop.
- Which commands it may run. Allow, ask, and deny rules.
- Which credentials it can see. A password manager, never the repository.
- What it can commit. A feature branch and a pull request; you merge.
- Whom you trust. Providers, their data policies, and downloaded repositories and weights.
One distinction applies to all six. An instruction (a rules file, a line in a prompt) asks the model to behave in a certain way. A permission (a VM boundary, a deny rule, branch protection, a firewall) removes the ability to do otherwise. Instructions influence behavior; permissions constrain it. Prefer permissions wherever they are available. None of the six eliminates risk; together they reduce it.
1. Network: an allowlist
- Be careful what you install and clone. Every dependency’s install script and every file in a repository is code the agent runs and text it reads.
- Treat everything the agent reads as untrusted: issues, PR comments, web pages. A prompt that sends the agent to the web brings back whatever the page contains.
- Use the web session and keep its defaults. Claude Code on the web and Copilot’s cloud agent restrict network access to an allowlist and keep keys out of the sandbox. Do not disable the firewall to resolve a blocked request; add the one host that is needed.
- Review the pull request before merging. This is the final control, applied after all the others.
Where to set the allowlist:
An allowlist is a partial control. Copilot’s firewall covers only processes the agent starts through Bash, not MCP servers or setup steps, and GitHub states that sophisticated attacks may bypass it. An allowlist narrows the exfiltration path; it does not close it.
2. Run the agent in a cloud VM
Run the agent on a cloud virtual machine rather than your own
machine. It then cannot delete your filesystem, read your password
store, or find an old .env file.
- Claude Code on the web (claude.ai/code) and GitHub Copilot’s cloud coding agent (github.com/copilot/agents or the Copilot app) clone the repository into a disposable VM. The work is returned as a branch or a pull request.
- The desktop apps offer both modes. Claude Desktop, the Copilot app, and the VS Code extensions can run a cloud session or a local one. A local session runs on your machine with your full user access. Check which mode is selected before you prompt.
- If you run locally regardless, use a dev container and understand its limits.
Dev containers are not a security boundary
A dev container limits the agent to the project directory, which is worthwhile. But Anthropic does not consider containers a security boundary, and its own Claude Code dev container is intended for trusted repositories only. A container or VM limits what a compromised agent can reach; it does not prevent the compromise. The agent still reads the repository, the issues, and whatever a prompt directs it to fetch, and it still holds whatever credentials the session was given. Injected text can use those inside the sandbox and send results out over the network. This is why the network allowlist and the credential rules remain necessary.
| Bare laptop | Local dev container | Disposable cloud VM | |
|---|---|---|---|
| What the agent can reach | Everything on the machine | The project folder, plus anything forwarded in (SSH keys, git login) | One repository and one scoped token |
| What is lost if it is compromised | Your accounts, keys, and every repository on the machine | The project, and possibly the machine | One repository, and a token you can rotate |
| Prompt injection | Same risk | Same risk | Same risk |
When local exposure is the concern, the order of preference is: cloud VM (nothing runs locally), then dev container (contained local access), then a bare local agent (full user access).
3. Set command rules, but beware loopholes
Allow, ask, and deny rules determine which commands run without
confirmation. The defaults usually deny nothing, so configure them: deny
rm -rf, force-push, and reads of .env and
~/.ssh. Claude Code’s documentation on permissions versus
sandboxing describes the two mechanisms.
Rules can be committed with the project so that cloud sessions read them:
A permission rule inspects the command text, not what the command
does when it runs. In January 2026, Cursor’s allowlist was bypassed (CVE-2026-22708,
reported by Pillar Security): prompt injection set an environment
variable through a shell built-in that the allowlist did not check, and
the next approved git command executed the attacker’s code.
Deny rules reduce risk; the VM boundary is what removes it.
Instruction files help, but agents forget context and find loopholes
An instruction file is a markdown file the agent reads at the start
of every session containing project context, commands, and conventions.
Claude Code reads CLAUDE.md; Copilot reads
.github/copilot-instructions.md; nearly every tool, Copilot
included, also reads AGENTS.md. Commit it to the repository
and keep it short: the test command, the data location, what not to
modify. The planning episode
gives an example.
An instruction file is not a permission, and agents also lose track of instructions as the context grows long. In April 2026 a Cursor agent working on a staging task for the company PocketOS encountered a credential mismatch, found a Railway API token in an unrelated file, and used it. The production database and its backups were deleted in nine seconds. The rules file occupies the same context window as everything else the model reads; it is text the model weighs, not an ability the model lacks.
4. Credentials: a password manager, never the repository
A secret that is not on disk cannot be read, printed, committed, or
exfiltrated, whether by an agent, by malware, or by a person working
late. Agents scan for context and may be able to read local
.env or JSON configuration files, so remove the secrets
before the agent arrives.
- Do not store passwords or API keys in
.envfiles, JSON configuration files, or shell profiles. - Keep keys in a password manager and read them when needed. Every
UW–Madison NetID can request a free 1Password account.
The 1Password CLI (
op) reads a secret by reference:
BASH
# The op:// reference is a pointer, not a secret. It is safe to commit.
op read "op://Private/bbadger/credential"
# vault item field
# Into the environment for this shell only
export OPENAI_API_KEY=$(op read 'op://Private/bbadger/credential') # bash / zshAn op:// reference names a vault, an item, and a field.
It is a pointer, not a key: it is safe in a repository, a script, or a
chat message, and useless to anyone without access to your vault. Read
it when you need it; nothing is stored on disk.
For a Jupyter workflow, keep a file of references (safe to commit,
since an op:// path is not a secret) and launch through
op run. Every kernel inherits the variables and no key
appears in a notebook:
BASH
# .env.op (references, not secrets; safe to commit)
OPENAI_API_KEY=op://Private/BadgerBrain/credential
OPENAI_BASE_URL=https://deepthought.doit.wisc.edu/v1
# launch JupyterLab through 1Password
op run --env-file=.env.op -- jupyter labPYTHON
# in any notebook, in any kernel
import os
from openai import OpenAI
client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])Do not print the key or paste it into a cell. 1Password prompts on each read, whereas an OS keychain releases secrets to any process running as the user. Cloud equivalents (AWS Secrets Manager, Azure Key Vault) work the same way. See the 1Password CLI documentation.
5. Version control: feature branch, pull request, you merge
Version control makes agent mistakes recoverable.
- Always use version control (GitHub, GitLab, Bitbucket).
- Do not let an agent commit to
main. The agent creates a feature branch and opens a pull request; you review and merge. - Review and test code before merging to
main. Make small, frequent commits; each is a restore point. - Start from a clean git state, so that
git diffshows exactly what the agent changed andgit restorereverts it.
Protect main on the hosting service so this is enforced
rather than habitual: require a pull request and a passing check before
merge. The verification episode sets this up.
6. Whom you trust: providers, models, repositories
The final limit is not enforced by any setting: which providers, packages, and model weights you admit into the workflow. Vet a provider’s data policy (are my data and code used for training, and is that the default? how long is it retained, and who can see it? where does inference run, and under whose jurisdiction? does an institutional agreement cover this, or is it a personal contract?). Treat downloaded weights and packages with the caution you would apply to any executable. The next episode, trust, covers each with the incidents behind the rules.
No agents on machines that hold sensitive or restricted data
Running an agent locally on any machine that stores sensitive or restricted data is not recommended at this time. Permission settings, deny rules, and containers do not change this: local agents scan for context, anything on the machine can end up in a prompt, and “the agent should not have looked there” is not a control a compliance office will accept.
If you must work on a repository from such a machine, use a route with no local access by construction: a web interface in which the agent operates only on a cloud-hosted copy of the repository. The repository itself must still be free of sensitive or restricted data, since its contents go to the provider. Until your institution establishes vetted routes, the rule is that agents and sensitive or restricted data live on separate machines.
Exercise: Get your agent running, safely (8 minutes)
The goal is an agent open on your own repository, in a cloud session, before any real work begins. Other routes, including free ones, are on the setup page.
-
Choose a cloud route with plan mode.
- Claude users: use the web, claude.ai/code. Plan mode is built in and nothing needs to be installed. The desktop app is also acceptable, provided the session runs in a cloud-hosted VM.
- Copilot users: install the GitHub Copilot app for an explicit plan mode, in which the agent asks questions and waits for your approval before editing. Start a cloud session, not a local one: cloud runs in a GitHub-hosted VM; local runs on your machine with your access. If you cannot install, the web works too: ask for a plan in the prompt and you get the same review gate, with less interaction.
- Confirm the session is cloud-hosted before you prompt. It should be pointed at a cloud VM and a GitHub repository, not a folder on your laptop. Check the environment’s network access setting (limit 1 above) while you are there.
- Use your project repository. If your team does not have one yet, create your own for today.
- Work on a branch named for you. Use branches rather than forks, so teammates and their agents can see your work. If you lack write access, ask the repository owner to add you as a collaborator.
-
No
.envin the repository. If you use one, add it to.gitignore. Preferop readfrom the 1Password CLI to storing keys anywhere. - Prompt: “Read this repo and tell me what it’s doing, or attempting to do. Do not change anything.” While it works, note what it gets right, what it states confidently that you cannot verify, and what it does not know that you do.
If step 2 fails (the session is local), stop and switch before prompting. This is the most common mistake with the desktop apps. Cloud sandboxes are billed by usage, so confirm your account works before the real work. Branches rather than forks matter for a team: an agent can fetch and read a teammate’s branch, compare against it, and merge, but it cannot see a fork without additional remotes being configured. The read-only prompt in step 6 previews the planning episode. Agents describe what and how well (structure, dependencies, data flow) and cannot recover why or for whom; that is the knowledge a plan and an instruction file must supply.
- Institutional data policies apply unchanged: sensitive or restricted data stays away from unvetted AI services, on every route.
- Agents run with your permissions and scan your workspace for context. Assume anything on disk in plaintext can be read.
- Prompt injection is the threat: anything the agent reads can carry instructions. Treat it all as untrusted, keep the web session’s firewall on, and review the pull request before merging.
- Six limits determine how much damage injection can do: network allowlist, cloud VM, command rules, password-manager credentials, branch plus pull request, and whom you trust.
- Instructions influence behavior; permissions constrain it. A rules file is text the model weighs, not an ability it lacks.
- The only secret an agent cannot leak is one that is not there. Load
keys at runtime with
op read. - First session: a cloud route with plan mode, confirm the session is
cloud-hosted, a branch named for you, no
.env.
Content from Trust: Packages, Models, and Providers
Last updated on 2026-09-16 | Edit this page
Estimated time: 17 minutes
Overview
Questions
- How do I decide whether to trust a package, a model, or an AI provider?
- What new supply-chain risks does agentic coding introduce?
- What has gone wrong in practice, and what would have prevented it?
Objectives
- Review every dependency an agent adds, and verify that packages exist and are official before installing.
- Treat downloaded model weights as executable code and apply provenance checks accordingly.
- Vet an AI provider’s data policy by answering four questions before use.
- Connect each practice to a documented incident.
The safety episode ended with the one limit no setting enforces: whom you trust. The rest of this lesson assumes that the packages you install and the services you call are what they claim to be. That assumption deserves the same scrutiny as the data. Agentic coding raises the stakes in one specific way: the agent installs packages, downloads models, and sends your code to a provider on your behalf. Decisions that were once made one at a time are now made quickly and in bulk unless you deliberately stay involved.
Packages: the agent multiplies your supply-chain exposure
Open-source package ecosystems have always carried supply-chain risk.
Even carefully maintained infrastructure can be compromised; the 2024
xz-utils backdoor was inserted by a contributor who spent
years building maintainer trust. Agents add two new problems:
-
Hallucinated packages (“slopsquatting”). Language
models sometimes recommend packages that do not exist. In one large 2025
study, roughly a fifth of packages suggested by code-generating models
were fabrications, and the same invented names recur across sessions.
Attackers can register those names. Security researcher Bar Lanyado
demonstrated this by registering
huggingface-cli, a name models repeatedly invented; the empty placeholder received more than 15,000 downloads in three months and appeared in a major company’s installation instructions. -
Typosquatting and dependency confusion happen
faster. In December 2022, a malicious
torchtritonpackage on PyPI shadowed a PyTorch-nightly internal dependency and exfiltrated SSH keys and files from thousands of machines. In December 2024, compromised releases ofultralytics(the widely used YOLO library) installed a cryptominer on any machine that installed during the affected window. Neither incident involved AI, but an agent that runspip installunattended removes the moment at which a person might have noticed an unfamiliar name.
Practices that follow:
- Do not auto-approve package installation. Keep installs on the list of actions that require approval, or add “do not add new dependencies without asking” to the project context file, remembering that context files are advisory.
- Before installing anything an agent suggests, verify that it exists and is official. Check the registry page, the linked source repository, download counts, and release history. A brief check defeats most slopsquatting.
-
Pin versions in a lockfile and prefer environments
you can rebuild (
requirements.txtorenvironment.ymlunder version control), so that a bad install is reverted rather than investigated.
Model weights are code
Running open-weight models locally has a privacy advantage: the data never leaves your machine. But downloaded weights deserve the same caution as downloaded executables, because in the common formats they are executables. Four ways a model download can cause harm, each with a documented case:
- Weights can carry code. Python’s pickle serialization, used by many model files, runs arbitrary code on load. In 2024 JFrog found on the order of a hundred malicious models on Hugging Face whose payloads included opening a reverse shell when loaded. Scanners have not caught everything since.
-
Fake repositories. Check the organization, not the
model card. In 2026 HiddenLayer identified
Open-OSS/privacy-filter, posing as an OpenAI release with a copied model card and a loader that installed an infostealer, at the top of Hugging Face’s trending list. - Values are trained in. DeepSeek R1 censors certain topics; Perplexity’s R1 1776 (2025) was post-trained specifically to remove that behavior. Whatever a model’s builders trained it to do or avoid, it will do or avoid in your pipeline.
- Hidden backdoors work, and no reliable detector exists. In Mithril’s PoisonGPT demonstration (2023), an edited GPT-J spread a specific false fact, kept its benchmark scores, and was uploaded under a lookalike organization. No detector caught it. More below.
Practices that follow:
- Prefer
safetensors, a weights-only format that cannot execute code, over pickle formats when available. - Download from the verified official organization
account (for example
meta-llamaormistralai), not a re-upload, and check checksums where published. -
Do not set
trust_remote_code=Trueby default. It runs whatever Python ships with the model. Tooling can get this wrong on your behalf: InstructLab hardcoded it on (CVE-2026-6859). - “Open weights” does not mean audited. Provenance tells you who built the model, not that it is sound. Smaller local models also hallucinate more, including package names, which returns to the previous section.
Backdoors in the weights themselves
Using safetensors closes the code-execution route. It does nothing about a separate class of attack in which the malicious behavior is in the parameters rather than the file format. A model can be built or modified to behave normally in almost all cases and misbehave on a trigger:
- Surgical weight edits. In the PoisonGPT proof of concept (2023), researchers edited an open model to emit specific false facts, re-uploaded it under a typosquatted organization name, and showed that standard benchmarks barely changed. Benchmarks do not establish trust.
- Sleeper agents. Anthropic’s 2024 research trained models that wrote secure code when the prompt said the year was 2023 and inserted exploitable vulnerabilities when it said 2024. Standard safety training failed to remove the behavior and sometimes taught the model to conceal it.
- Data poisoning is inexpensive. A 2025 study by Anthropic with the UK AI Security Institute found that a few hundred poisoned documents in a training corpus can implant a backdoor, roughly independent of model size. Earlier work (for example TrojanPuzzle) showed that code-suggestion models can be poisoned to emit insecure patterns.
- Graph-level backdoors. Techniques such as ShadowLogic embed the backdoor in a model’s computational graph (for example ONNX), again with no code execution.
This matters for agentic coding in particular because a backdoored code model does not need to attack your machine; it needs only to write subtly vulnerable code that you trust, run, and ship. In an agentic setup the trigger can also be delivered: prompt injection through a poisoned README or issue, combined with a backdoored model that has tool access, is worse than either alone.
Detecting behavioral backdoors is an open research problem. No scanner finds them and benchmarks do not reveal them. The defenses are therefore the routine ones: provenance from heavily scrutinized official sources, extra caution before connecting a niche fine-tune to a pipeline with tool access or untrusted inputs, and treating model output as untrusted regardless of where the weights came from. The last of these is the review discipline this lesson already requires, and it protects you whether the bad code comes from an average-case guess or a backdoor.
The tools themselves are an attack surface
The agent’s harness (the extension, the CLI, its hooks and configuration) is software, and it is a valuable target because it holds your permissions:
- In July 2025, an attacker inserted a prompt into the Amazon Q VS Code extension through a GitHub pull request, instructing the embedded agent to wipe the user’s files and cloud resources. The poisoned version shipped to users before it was caught.
- Security researchers in 2025 disclosed dozens of vulnerabilities across AI coding IDEs (reported as the “IDEsaster” findings) and multiple CVEs in individual tools.
- Agents can also cause damage with no attacker. In July 2025, Replit’s coding agent deleted a production database during a “vibe-coding” experiment despite explicit instructions to freeze changes, then produced misleading output about what it had done.
Keep agent tooling updated, install extensions only from official marketplaces, and never point an agent at production systems or irreplaceable data. Separation of development and production, and backups, remain necessary.
Vet the provider as you would vet a data source
Whichever provider you choose (Anthropic, GitHub/Microsoft, Google, a startup, a model router), you are sending your code and prompts to them. Before committing, answer four questions from the provider’s policy documents rather than its marketing material:
- Are my data and code used for training, and is that the default? Commercial and API terms typically prohibit it. Consumer plans often make it a setting, sometimes enabled by default. Find the setting and decide.
- How long is it retained, and who can see it? Retention windows differ by an order of magnitude between plan tiers. Feedback buttons and safety reviews often extend them.
- Where does inference run, and under whose jurisdiction? In January 2025, researchers found a publicly exposed DeepSeek database leaking user chat histories and API keys. Provider security practice and legal jurisdiction are part of the arrangement.
- Does an institutional agreement cover this, or is it a personal contract? In 2023, Samsung engineers pasted proprietary source code into ChatGPT while debugging; the company responded by banning generative AI tools internally. An individual subscription gives your institution no protection, which is why the safety episode’s rule (restricted data stays off unvetted tools) exists.
Claude and Copilot defaults (as of September 2026)
The two tools this lesson uses most illustrate how much the answers depend on plan tier rather than provider:
| Claude Code (Free, Pro, Max) | GitHub Copilot (Free, Pro, Pro+) | |
|---|---|---|
| Trains by default? | Yes; opt out under Settings → Privacy (consumer terms). Team, Enterprise, API, and Bedrock: no (Claude Code data usage) | Yes, since April 2026; opt out in Copilot settings (GitHub docs). Business, Enterprise, and students: no |
| Retained how long? | 5 years if training is on, 30 days if off (Privacy Center) | 28 days |
| Where does it run? | Anthropic VMs in the US, or Amazon Bedrock on the university’s AWS account | GitHub’s Azure in the US; Claude and Gemini models via AWS, Anthropic, and Google Cloud |
| Institutional or personal? | Personal. The Bedrock route is institutional, with zero data retention through 2026 | Personal, via GitHub Education. Not on UW–Madison’s vetted list |
Neither consumer route is on UW–Madison’s list of vetted AI tools. Policies change; consult the linked pages rather than this table.
Free services have a cost
If a tool or model API is free and is not open source running on your own hardware, consider what the provider receives. Often it is your prompts, and through them your code and data. That may be acceptable for public workshop exercises and unacceptable for unpublished research.
Exercise: Vet the tool you are using now (5 minutes)
For the agentic tool you set up for this workshop, answer the four questions above from the provider’s privacy and data pages, not from memory.
- Training: on or off by default for your plan? Where is the setting?
- Retention: how long, and what extends it?
- Where does inference run?
- Are you covered by an institutional agreement, or is this a personal contract?
Compare notes with a neighbor using a different tool.
Most participants find at least one surprise: a training setting they had not seen, a retention clause tied to the feedback button, or the discovery that a tool they assumed was institutional is a personal agreement. The answers vary by provider and by plan tier within a provider, which is why vetting the policy cannot be delegated, including to the agent.
- Agents install packages and download models quickly and in bulk. Keep those decisions on the list that requires approval.
- Hallucinated package names are an attack vector (slopsquatting). Verify that a package exists and is official before installing anything an agent suggests.
- Model weights in pickle formats are executable code. Prefer
safetensors, download from verified organizations, do not enable
trust_remote_codeby default, and check provenance. - Backdoors can be in the weights themselves (poisoned training data, surgical edits, trigger behaviors). No scanner or benchmark detects them; provenance and reviewing model output are the defenses.
- The agent tooling is itself an attack surface. Keep it updated, and never point an agent at production or irreplaceable data.
- Vet the provider’s data policy: training default, retention, jurisdiction, and whether an institutional agreement applies.
- Provider defaults differ by plan tier. Consumer Claude and Copilot plans train on your data unless you opt out; team, enterprise, API, and education tiers do not. Check the setting, not the brand.
- Each rule here has a named incident behind it: torchtriton, Ultralytics, huggingface-cli, Amazon Q, Replit, DeepSeek, Samsung, the fake OpenAI repository, InstructLab. None required a sophisticated attacker; all required a missing check.
Content from Planning with Agents
Last updated on 2026-09-16 | Edit this page
Estimated time: 37 minutes
Overview
Questions
- Why plan before letting an agent write code, and what does the evidence say?
- What goes into a plan, and where does the agent get the context to make one?
- What is a minimum viable pipeline, and why start there?
- How do I plan with an agent without adopting designs I cannot defend?
Objectives
- Explain how a plan changes what an agent does with its context and tokens.
- Supply the context an agent needs to plan: goal, constraints, existing code, standards, prior decisions.
- Use an agent in a read-only or plan mode to review and improve a plan before any code exists.
- Agree team collaboration conventions with an agent’s help and commit
them as a
CONTRIBUTING.mdthat people and agents both read. - Produce a
plan.mdwith ordered features and a check for each, and commit it before implementing anything. - Evaluate AI design suggestions critically: question what you do not understand, and do not build on ideas you cannot defend.
Start with a plan
The most common failure in agentic work is letting the agent write code before either party understands the problem. The research on planning is consistent:
- Structured planning before implementation improved coding success by up to 26.7%, reducing failed generations and repeated implementation attempts (Jiang et al., 2023).
- Removing the blueprint-planning agent from a structured coding pipeline reduced accuracy by 14.8 percentage points (Mao et al., 2025).
- Runs on the same coding task varied by up to 30× in total token usage, and higher token consumption did not produce greater accuracy (Bai et al., 2026).
These studies measured accuracy rather than token use, but the mechanism is straightforward. Without a plan, the agent makes exploratory and redundant tool calls, which usually means more tokens for lower accuracy. With a good plan, it makes fewer wasted turns and less rework, which usually means fewer tokens and higher accuracy. With a bad plan, it anchors on incorrect assumptions, which produces both lower accuracy and higher token use.
Without a plan, an agent tends to make unnecessary repository searches, re-read the same files, modify the wrong layer, expand beyond the requested scope, make contradictory edits, loop on debugging, and report completion prematurely. With a plan, it searches purposefully, reads only the relevant files, understands constraints before implementing, detects missing information early, sequences dependent changes correctly, tracks what is done, verifies the acceptance criteria, and stops when the task is complete.
A plan gives the agent direction. It gives you a review point before implementation. It gives both parties a shared definition of done. Planning should be proportional to the task: a three-line plan for a three-line task.
Supply context
An agent asked to “make a plan” with no other input produces the average plan for the average project. The plan is only as good as the context it is built from. Context worth providing, in rough order of how often it is missing:
- The goal and constraints: the research question, the challenge page, the scoring rule, the compute available.
-
The previous
plan.md, or its discoveries and blockers. - Skeleton code: a stub of the function or module you want, so the shape is yours.
- A GitHub issue or story describing the feature in your words.
-
future-work.md: what is deliberately out of scope. - Rules and coding-standards files: the project context file described below, plus any style guide your group follows.
For long tasks (multi-hour work, anything spanning several sessions, handoffs between people or agents), keep the plan in a file the agent updates as it works. Aaron Friel’s Using PLANS.md for multi-hour problem solving describes the pattern. A persistent plan file typically contains:
- Goal and context
- Scope and acceptance criteria
- Architectural decisions
- Ordered implementation steps
- Progress and completion status
- Discoveries, assumptions, and blockers
- Test commands and results
- Final outcome
Planning is iterative. The first plan is a draft to be questioned; the deliverable is a plan you would sign.
Plan mode: read without writing
Most tools have a read-only mode for this stage, in which the agent reads files and answers questions without making changes. It is the safest first contact with a repository and the appropriate mode for reviewing a plan.
Exercise: Agree how your team will collaborate (10 minutes)
Every member of the team is about to use a coding agent on the same repository, which will produce more branches, more commits, and larger diffs than a typical project. Decide the rules before the first feature, and have the agent draft them.
Decide between branches and forks. One shared repository with branches is the usual choice for a team that trusts each other: every teammate’s work is a
git fetchaway, so an agent can read another branch, compare against it, and merge without anyone adding remotes.-
Ask the agent, giving it your team size and what you are building:
Our team of <n> is working in one GitHub repo on <challenge>. Every one of us is using a coding agent, so we will be generating more branches, more commits and bigger diffs than a normal project.
Propose contributing conventions that keep
mainclean and reviewable. Cover branch naming, how small a pull request should be, who reviews, what an agent may touch without asking, how we avoid two agents editing the same file, and what goes in commit messages. Also suggest how to organize the repo structure so any new files go in the correct spot.Write
CONTRIBUTING.md. Commit it to a development branch named for me, not tomain, and open a pull request for it. Short enough that people read it. Edit what it produces. Keep the rules the team will follow and remove the rest.
Merge it through the process it describes.
CONTRIBUTING.mdgoes on your own branch, not directly tomain. Open a pull request, have a teammate review it, then merge. This is the first use of the rules you have just written. Most agents open a pull request by default; note that when it happens.Share the link with whoever advises the team, so they can see what was agreed.
If you are working alone, write the same thing for yourself in three to five lines (a branch convention, a pull-request size, what the agent may never modify) and put it in your context file.
It is short. A branch-name pattern
(<name>/<feature>); a pull-request size people
will review in full (a few hundred lines at most); one named reviewer
per pull request, and whether review happens at the pull request or on
every change (the verification episode compares the two); a list of
paths the agent may not modify without asking (data/raw/,
the scoring function, main); a rule for avoiding collisions
(one feature per branch, claimed in the plan); and a commit-message
format. Agents draft a reasonable first version because conventions are
the average case. Your contribution is removing what the team will not
do. The rules are advisory for the agent; back the important ones with
branch protection.
Start from a minimum viable pipeline
A minimum viable pipeline (MVP) is whatever you can get running quickly and understand end to end. It is not necessarily the simplest model: a pretrained model you understand is preferable to a from-scratch model you do not. The aim is to minimize points of friction and failure: a slice of the data, one model, your laptop. Each additional step or more elaborate setup is another place for the pipeline to break.
- Functional, not polished. Borrowed code is acceptable if you can explain what it does. Defer the edge cases.
- Do not defer the understanding. A pipeline you understand reveals the real relationships in the data, the processing bugs, and the data problems that a system you do not understand would conceal.
The MVP is the baseline against which new components are compared, before investing in solutions that take time to build. It is also the appropriate first plan for an agent: small enough to specify fully, with every feature something you can check.
Exercise: Plan your MVP with an agent (15 minutes)
Open your project’s MVP plan. If there is none, write three lines now: the data slice, one model, and how you score it. If you have no project, choose a public dataset or competition you know and plan an MVP for it.
-
Ask the agent to review it in plan mode, against your project’s goal (the challenge page, the paper’s research question, or the grant aim):
Review our Minimum Viable Pipeline (MVP) plan against the challenge page. The MVP should be something we can get running quickly and understand end-to-end. It is the baseline we A/B new components against, before we invest in solutions that take time to build.
MVP plan <paste from your shared doc>
Challenge page <paste challenge text, scoring, data description>
Compute available <laptops; hosted models and how they’re accessed; cloud credits and when>
Is this a good MVP? Say why or why not. If it is good, propose a
plan.mdwith each step in order and how we will know each one works. If it is not, propose a better starting point and do the same for that. Do not write any code yet. Question the plan until you would sign it. Challenge anything you cannot explain, and ask why a given choice is preferable to the obvious alternative.
Commit
plan.mdto your repository. No code until the plan is committed.If you finish early, apply the same review to your pre-modeling steps (loading, cleaning, splitting, feature construction) and save the result as
prep.md. Then ask the agent to reviewplan.mdandprep.mdtogether.
Three features, each one thing you can check. For example: (1) load and validate the data slice, with row count and class balance printed; (2) train one baseline, with a score on a held-out split; (3) write the scoring function, matching the challenge metric on a hand-computed example. If the agent’s plan contains a feature for which you cannot describe a check, it is not yet a feature; split it or remove it. Note also what the agent could not know: which data is trustworthy, what compute you have, what the kickoff decided. You supplied that context; without it the plan would have been for a different project.
Do not build on ideas you cannot defend
AI design advice is fluent whether or not it is correct, and it is most persuasive where your own domain knowledge is weakest. An architecture, statistical approach, or library choice you do not understand is a liability even if it is good, because you cannot debug, extend, or defend it in review or in peer review.
Question a suggestion before adopting it. Ask why this rather than the obvious alternative, what the failure modes are, and what the simplest workable version would be. An agent tends to abandon a weak idea under questioning, which is itself evidence. Be most cautious about suggestions from outside your field: a method from a discipline you do not know is a reason to consult a human expert or the literature, not something to adopt because the response sounded confident. If you cannot explain it, you do not yet own it.
Before the first feature: write the context file
Planning surfaces knowledge that exists only in your head: the
reasons for decisions, the conventions, what the data means. Before the
first feature, record it in a project context file, the
rules file introduced in the safety episode. Claude Code reads
CLAUDE.md from the project root at the start of every
session; Copilot reads .github/copilot-instructions.md;
nearly every tool also reads AGENTS.md. It is a README
addressed to the agent:
MARKDOWN
## Project structure
- Analysis pipelines live in `src/pipelines/`; each mirrors a notebook in `notebooks/`
- Raw data in `data/raw/` is read-only — NEVER modify it; derived data goes to `data/processed/`
## Conventions
- Run tests with `pytest tests/` after changes; don't commit with failing tests
- Use type hints; don't add dependencies without asking
## Safety
- Never force-push; never commit directly to main
- The `results/` directory is generated — edit the code, not the outputsKeep it short and operational (well under 300 lines). It is injected into every session, so everything in it competes for the model’s attention with the task at hand. If a linter can enforce a rule deterministically, use the linter and save the context. As the safety episode explained, context files are advisory; back safety-critical rules with permissions, hooks, or branch protection.
- Plan before code. Planning measurably improves accuracy, and a good plan usually reduces token use. Keep planning proportional to the task.
- A plan is only as good as its context. Provide the goal, constraints, compute, existing code, standards, and prior decisions; for long work, keep the plan in a file the agent updates.
- Agree team conventions first (branches rather than forks,
pull-request size, who reviews, what the agent may not modify, where new
files go) and commit them as a
CONTRIBUTING.mdthat agents also read. - Use plan mode (read-only) to review a plan. The deliverable is a
plan.mdwith ordered features and a check for each, committed before any code. - Start from a minimum viable pipeline: a slice of data, one model, something you understand end to end.
- Question AI design suggestions before adopting them, most carefully where your domain knowledge is weakest. If you cannot explain it, you do not yet own it.
- Write the project context file (
CLAUDE.md,AGENTS.md,copilot-instructions.md) at the start of the project. Keep it short, operational, and backed by permissions where it matters.
Content from Feature-Based Development and Good Prompting
Last updated on 2026-09-16 | Edit this page
Estimated time: 25 minutes
Overview
Questions
- Why work feature by feature instead of requesting whole projects?
- What happens when I give an agent a vague request?
- What does a good prompt look like for research code?
- Which routine tasks are agents reliably good at?
Objectives
- Decompose a plan into feature-sized, verifiable tasks and work on them one per session.
- Predict how an agent fills gaps in an underspecified request.
- Distinguish context engineering (standing guidance) from prompt engineering (the specific request).
- Write prompts that specify inputs, output, the check for completion, and what not to modify.
- Implement one feature from your plan and audit the decisions the agent made on your behalf.
The agent is not a magic wand
Some frustration with agents comes from using them as one: describe the whole project, wait, and receive something plausible and wrong. This style of use is sometimes called vibe coding. The remedy is a person in the loop who knows the domain. You decide what to build next; the agent builds that one thing; you check it before the next. Your expertise is what makes the arrangement work, not the prompt and not the model.
Work feature by feature, not project by project
A feature is one thing you can check: load and validate the data
slice; train one baseline; write the scoring function. The
plan.md from the previous episode is the feature list. Work
through it in order.
- One feature per session. Fresh context, a small diff, one pull request. The cost episode explains why a fresh session matters: everything in a long session competes for the model’s attention.
- Specify each feature: inputs, output, how you will know it works, what not to modify.
- Small scope produces small diffs, which you can review in full. A project-sized prompt produces worse code and a diff too large to review, at which point you have given up control without deciding to.
A whole-project prompt produces whole-project guesses.
A bad prompt does not return random results
When a request is ambiguous, the agent does not fail and does not choose at random. It fills each gap in the specification with the most statistically typical choice from its training data: the most common file layout, the default hyperparameters, the standard preprocessing for data that resembles yours.
This is why underspecified requests usually produce code that runs and looks reasonable. Average-case answers generally do. Research data and code are rarely the average case. The instrument artifact specific to your equipment is not in the training data. Your field may follow a convention the average repository does not. Your “duplicate rows” may be repeated measures. Each unstated assumption is resolved in favor of someone else’s typical project, without any indication that a choice was made.
Two consequences follow:
- The specification work you would do for a human collaborator does not disappear. It moves into the prompt.
- The failure mode is plausible-but-wrong rather than visibly broken. This is why the next episode, on verification, is the core of the lesson.
Guide the agent with clear instructions
There are two levers, operating at different time scales:
-
Context engineering sets the standing guidelines
for generating code and the resources the agent may use: the project
context file (
CLAUDE.md,AGENTS.md,copilot-instructions.md), coding-standards files,plan.md. Written once, read in every session. A shared context file is an inexpensive way to keep a team’s code consistent. - Prompt engineering phrases the specific request to obtain the best result for the task at hand.
These are not alternatives. They are concentric layers around the model, and each contains the one inside it. The harness (the loop, tools, memory, sandbox) is the outermost layer and is mostly fixed by the tool; the context and the prompt are yours to set.
The same request at two levels of specification:
Weak prompt:
Fix this bug.
Better prompt:
Here is the error, the code that raised it, and what was running as input.
Error log <paste full traceback>
Code <paste the function or file>
Input <what data or arguments it was called with>
Before changing anything, explain what you think is causing this and how you would confirm it. Wait for me to agree before you apply a fix.
The better prompt supplies the evidence (traceback, code, input), asks for a diagnosis before any change, and keeps the decision with you. “Fix this bug” alone leaves the meaning of “fixed” to the average case, and an agent told to make an error disappear sometimes does so by removing the check that raised it.
A checklist for research-code prompts:
- Where: which files or functions to modify, and which to leave alone.
- What: the behavior you want, including the edge cases you know about.
- Constraints: conventions, permitted dependencies, things to preserve.
- Verification: how the agent should check its own work. Run the tests; confirm the row count is unchanged; print the class balance before and after.
The last item leads into the next episode. A prompt that includes its own check is worth more than one that does not.
Exercise: Implement feature 1 from your plan (15 minutes)
Take feature 1 from your plan.md, or any feature you
want to add.
-
Write the prompt using the template below. Direct the agent to
plan.mdand your project’s goal page.Implement feature 1 from
plan.md.Feature <name and what it does>
Inputs (if applicable) <files or data it reads; the slice we agreed on>
Output (if applicable) <what it produces and where>
Done when <the check that proves it works: a test, or a printed baseline number>
Do not touch <other files,
data/raw/, the scoring function>Work on a new branch (most coding agents do this automatically). When finished, list every choice you made that I did not specify.
Run it. Read the diff before anything else.
Audit. Did it do only what you asked? What did it decide that you did not specify?
If you have no project, use this starter and request one feature: a stratified 80/20 split, a standardized logistic regression, and a printed majority-class baseline alongside the test accuracy.
The request to list unspecified choices is the most informative line in the template. Typical answers: a random seed, a default imputation, an added metric, a file you did not ask for, an installed dependency. Each is now a decision you are responsible for. The ones that surprise you belong in the next prompt, or in the context file so they need not be specified again.
A bare “implement the model” prompt, by contrast, produces something that looks complete, with choices you did not make and no list of them.
:## Give your agent maintenance tasks
If you are new to agentic workflows, as most people are, consider starting with maintenance tasks, which agents do particularly well. They are the routine work that keeps a research repository usable, and each should be treated as a feature: small, specified, checkable, one pull request, reviewed by you.
- Refactoring. Split the 400-line notebook into functions and a script. Tests pass before and after, or the refactor is not complete.
- Docstrings and type hints on every function. Ask for a diff that changes no logic, then confirm that it did not.
- A README that matches the code. “Read the repo and list what the README says that is no longer true.”
-
Environment files. Pin
requirements.txtorenvironment.ymlfrom what the code imports. -
Weekly merge preparation. “Summarize what changed
on this branch since
main, for the teammates who were not here.”
Documentation: notes to your future self and your agent
Documentation deserves more than a place on that list, for three reasons.
- It is now cheap. Research code is under-documented because writing docstrings and READMEs lost to the next experiment. The agent has the source of truth in context, and a paragraph of prose is faster to review than an implementation. Ask for docstrings, comments that explain why (not what), a README that says how to run the pipeline end to end, narrated notebooks, and a short end-of-session note on what changed and where to resume.
-
It becomes context. Everything you document is read
by the agent in later sessions. Agents recover what and
how from code but not why, for whom, or what
the data means. A data dictionary is the difference between an agent
that treats
-999as a measurement and one that knows it is the missing-value code. - Explaining is a check. To write an accurate docstring the model has to process what the code does, and a mismatch between its explanation and your intent points to a bug or an undocumented decision. Asking “explain in two sentences what this function does and why it exists” is an inexpensive review step.
Generated documentation has the same failure mode as generated code: it reads as confident and can be wrong. Read it before committing, update it with the code, and periodically ask the agent to verify every claim in the README, docstrings, and comments against what the code does, and list every mismatch.
- The agent is not a magic wand. A person who knows the domain decides what to build next; the agent builds that one thing.
- A feature is one thing you can check. Work through the plan one feature per session, with a small diff and one pull request.
- Underspecified prompts receive average-case answers, and research data is rarely the average case. The failure mode is plausible-but-wrong.
- Context engineering sets the standing rules (context file, standards, plan); prompt engineering phrases the specific request. Use both.
- Good prompts provide evidence, ask for a diagnosis before a change, and specify inputs, output, the completion check, and what not to modify.
- Maintenance tasks (refactors, docstrings, README audits, environment pins, merge summaries) are well suited to agents under the same small-specified-checkable rules.
- Always ask the agent to list the choices you did not specify.
Content from Verification and Testing: No Escaping Good Data Science
Last updated on 2026-09-16 | Edit this page
Estimated time: 30 minutes
Overview
Questions
- Why is “the code runs and the score is high” not sufficient?
- Which inexpensive checks catch expensive mistakes?
- How do I review an agent’s work when the code runs?
- How can the agent help me reason about results, not only write code?
- How do I make checks run automatically so they are never skipped?
Objectives
- Apply established data science verification practices (know your data, compare to a source of truth, ask a colleague, reproduce) to agent-generated analyses.
- Review an agent’s diff by looking for decisions you did not make, and have the agent list its own assumptions.
- After each feature, have the agent propose and add tests, including edge cases, and run them before moving on.
- Define test-driven development and apply it to research code: write the data or result test first, then have the agent implement against it.
- Make verification automatic: tests in CI and a protected
main. - Use an agent to reason over saved results and figures, and leave evidence in the repository for it to read.
- Run quick checks (label shuffling, baselines, overlap and duplicate checks, seed variation) that expose broken evaluations.
- Detect a group-leakage bug in code that runs cleanly and scores well, and write the assertion that catches it.
What the research shows about checking
Checking agent output is the bottleneck, not producing it:
- Agents multiply code written far more than code shipped: 240% more commits but only 30% more releases across 500,000 GitHub developers (Demirer, Musolff & Yang, 2026). Not all of the additional code is good code, and the gains attenuate at the human review step.
- Pull requests wait about five times longer for a human review under heavy AI use, and 31% more are merged without one (Faros AI, two years of telemetry from 22,000 developers at 4,000 companies, 2026).
Faros AI’s explanation has two parts. There is more to read: average pull-request size is up 51% and files touched per pull request up 60%, and the median wait before anyone starts a review is up 157%. And it is harder to review once started: median time in review is up 441%, because AI-written code is superficially convincing (idiomatic, well named, stylistically consistent with its surroundings), so its failures are structural rather than obvious. Reviewers have to reconstruct what the code was meant to do instead of scanning for errors. In their phrase, the code arriving for review was never review-ready.
The skill this episode teaches is the one in short supply.
The pull request as the final human check
Every feature comes back as a pull request on a branch. That is the
git arrangement from the safety episode, and it is where verification
happens: nothing the agent did reaches main until a person
approves the diff. The pull-request review is the last control, applied
after all the others.
A review done by eye alone does not scale. Pull requests are 51% larger under heavy agent use, and the code reads cleanly while being wrong. The review therefore needs support: tests that run on every push and checks that fail loudly. That support is the subject of the rest of this episode.
Where the review happens: two postures
Agents work on branches, never on main, and someone
(you, a colleague, or CI) reads the code before it is merged. Within
those rules, two workable postures differ on when the human review
happens.
The pull request is the review gate. The agent
commits freely and often to its feature branch as it works. The commit
log becomes verbose; that is acceptable, because frequent small commits
are restore points, and an agent’s granular history is more useful than
the usual human sequence of wip, fix,
fix again. Your review happens once, on the full
pull-request diff, as it would for a human collaborator’s branch. This
posture maintains momentum and concentrates attention where it is most
effective. It depends on safety nets: a real test suite, CI checks
gating the merge, and diffs small enough to read in full.
Review every change as it happens. You approve each edit or commit, staying close to the work in real time. This is slower, and appropriate where the safety nets are absent: you are new to the tool, the code is sensitive, the tests are thin, or you are still establishing what the agent does with your codebase.
The choice is a calibration, and it maps onto the verification tiers
at the end of this episode. Throwaway and well-tested working code
tolerate the pull-request gate; load-bearing code with weak tests calls
for per-change review, or the gate with a second reviewer. Many people
use both: the gate for routine feature work, per-change review when
modifying anything expensive to get wrong. Record the choice in
CONTRIBUTING.md or the context file so the agent and your
collaborators both know it.
Reviewing in shared projects
Two situations change the rules slightly:
- Contributing to a project you do not own. Read the contribution guidelines first (“summarize CONTRIBUTING.md and any pull-request conventions in this repo” is a good first prompt), work from a fork when you lack write access so no agent has push access to the canonical repository, disclose AI assistance where the project requires it (The Carpentries has a Generative AI contributions policy, for example), and keep pull requests small. Maintainers review in their own time, and large diffs are a common reason contributions are declined.
- Maintaining a project others contribute to. Agents are useful for triaging issues, drafting release notes from the commit history, dependency updates, documentation sweeps, and a first-pass review of incoming pull requests (“what does this change, and what should a human examine most closely?”). The human retains the merge decision. An agent’s review is a brief for your judgment, and incoming pull requests are untrusted input: prompt injection through pull-request content is a documented pattern.
Look for decisions you did not make
A well-specified prompt still has unintended consequences. When reviewing agent-written analysis code you are not checking syntax; the code runs. You are looking for decisions. Do this before and after every feature: ask the agent for its assumptions, ask for tests and edge cases, run them and confirm the results look right, then move on. The places most likely to contain unexamined decisions:
-
Silently dropped or altered rows: a default
dropna(), an inner join that shrinks the table, a type coercion that turns errors into NaNs. Require row counts before and after every join and filter. - Defaults treated as decisions: imputation strategy, class weights, regularization strength, thresholds. Every default the agent accepted is now a choice you are responsible for. This is one reason to start with an MVP small enough that you can own every choice in it.
- Substituted metrics: you asked about accuracy and the report features F1 because the number was higher.
-
Suppressed problems: warnings silenced,
try/except: pass, an error “fixed” by deleting the check. An agent told to make the code run sometimes does exactly that.
Two prompts worth using at every review:
Summarize every choice you made that I did not specify, and flag the risky ones.
Propose tests for our latest feature, including edge cases.
The first surfaces the dropped-row and default-parameter decisions above more reliably than reading line by line.
Exercise 1: Test the feature you just built (10 minutes)
Start from feature 1, the one you implemented in the previous episode. This is the step that follows every feature, before the next one begins.
-
Ask for its assumptions and proposed tests, in plan mode:
Read
plan.mdand the feature 1 code you just wrote.- List every choice you made that I did not specify, and flag the risky ones.
- Propose tests for this feature to ensure robustness as we develop the full pipeline, including edge cases: empty input, wrong shape, duplicates, a sample that lands in both splits, etc. Say which tests matter most and why.
- Do not edit anything yet. After I review, implement the tests as an automated GitHub Action that will run on each push.
Do not edit anything yet.
Select the tests that matter. Let the agent propose more than you would; keep the ones that protect against a wrong result.
Have it add them and run
pytest. Fix what fails, then commit.Make it automatic. A GitHub Actions workflow can run
pyteston every push (GitHub Actions for Python); the prompt’s third step asks the agent to write it. Protectmainso that a failing check blocks the merge (about protected branches).
A methodological requirement that was previously implicit is now an
executable contract. The agent has a feedback loop that fails when it
reaches for the average-case pattern, and you have an artifact that
continues to protect the project on every future change, whether the
next edit comes from an agent, a colleague, or you in six months. With
CI and a protected main, the check cannot be forgotten.
One caution: an agent asked to “add tests” for existing code will often write tests that assert whatever the code currently does, which preserves bugs rather than catching them. That is why step 1 asks for assumptions and risks before asking for tests. You decide what must be true; the agent writes the repetitive parts; you review the tests with the same care as the implementation.
Test-driven development: write the test first
The tests in Exercise 1 were written after the code. That is the common order, and it has a known weakness: a test written after the fact tends to describe what the code does, not what it should do, so it preserves whatever the agent decided. Test-driven development (TDD) reverses the order. You write a test that states the required behavior, watch it fail, and only then write (or have the agent write) the code that makes it pass. The test is the specification, and the code is judged against it rather than the other way round.
With an agent, this order has a second benefit. A test the agent must
make pass is an executable feedback loop: the agent runs it, reads the
failure, and revises, without you as the only check. The prompt becomes
“make pytest tests/test_feature2.py pass” instead of a
paragraph of prose, and the acceptance criterion cannot drift.
The alternative for the next feature, then, is: before prompting, write one test that encodes what “correct” means for this step, commit it, and ask the agent to implement against it. You decide what must be true; the agent does the work of satisfying it.
For research code, the tests worth writing first are rarely about function signatures. They are about the data and the result: the row count and class balance you expect, a hand-checked subset the pipeline must reproduce, a metric that must be stable across seeds, a split that must not leak. Those are the tests in the next section, and they are this lesson’s form of test-driven development.
Agents speed up the code; good data science practice still applies
Research computing already had an answer to “how do I know this analysis is correct?” before AI tools existed:
- Know your data. Distributions, outliers, units, missingness, class balance. Look at the rows.
- Compare to a source of truth. A published baseline, a hand-computed subset, a control.
- Know what your model is responding to. If the strongest predictor makes no scientific sense, that is a finding about the pipeline, not about the phenomenon.
- Reproduce the result. Rerun it, change the seed, rerun on a fresh split. If it does not hold, something you are not controlling is driving it.
- Plot the results and review them. Agents can sometimes help, but expert eyes are often needed.
None of this has changed. What has changed is speed: a plausible, clean-running, well-scoring analysis can now be produced in minutes, which means you can be misled in minutes as well. The checking has to keep pace.
Tests for good data science practice
Each of the practices above can be written as a test the agent implements and CI runs. Written before the feature they protect, they are test-driven development for research code. Prompts to start from:
- Know your data. Write a test that loads the raw data and asserts the row count, class balance and missing-value rate we expect. Print the majority-class baseline next to our metric.
-
Compare to a source of truth. Add a test that
runs our pipeline on the 20 rows in
hand_checked.csvand asserts every output matches the values I computed by hand. - Reproduce the result. Write a test that trains twice with different seeds on a fresh split and asserts the metric moves less than 2 points. If it moves more, the result is noise.
- Know what your model is telling you. Write a test that fails if any of the top five predictors is an ID column, a timestamp, or anything derived from the label.
- No leakage. Assert no subject, image, page or source document is in both splits, and no duplicate rows either. Then shuffle the labels and retrain. If the score does not collapse to chance, something leaks.
Agents as data scientists
Verification is not only about finding bugs. The agent is also a fast second reader of your results, if it is given something to read.
- Ask it to reason over results, not only to write code. What stands out, what disagrees, what to try next.
-
Leave evidence in the repository. Metrics files,
metadata, figures, run logs, a
results.md. What is not written down does not exist for the agent. - It can also read plots. A saved figure is context.
- Direct it to the evidence each time. It does not remember the previous session and will not open a file you did not name.
- It does not replace your own reading. Check every number it cites against the file. It sees a portion of the project, never all of it.
Read
results/feature1_metrics.json,figures/cv_by_fold.pngandplan.md. What stands out? Which fold or class is driving the average, and does the plot agree with the numbers? Propose the one experiment you would run next and say what result would change our plan. Do not run anything yet.
Exercise 2 (optional): What is wrong with this? (5 minutes)
The no-leakage test above is the general form of a common failure. This exercise shows the specific case.
PYTHON
# Brain decoding. 20 subjects, 400 trials each,
# one EEG window per trial.
X, y, subject = load_windows() # X: (8000, ch, t)
X_train, X_test, y_train, y_test = train_test_split(
X, y, test_size=0.2, random_state=42)
clf = make_pipeline(StandardScaler(), LogisticRegression())
clf.fit(X_train.reshape(len(X_train), -1), y_train)
print("accuracy", clf.score(
X_test.reshape(len(X_test), -1), y_test))
# accuracy 0.91The code runs. The number is high. Find the bug. Then write the one assertion that would have caught it.
Every subject appears in both splits. The model learned to identify each person, not what they were looking at. On a new subject the score drops:
PYTHON
X, y, subject = load_windows() # subject: one ID per trial
from sklearn.model_selection import GroupShuffleSplit
train_idx, test_idx = next(GroupShuffleSplit(
test_size=0.2, random_state=42).split(X, y, groups=subject))
assert set(subject[train_idx]).isdisjoint(subject[test_idx])
# accuracy on unseen subjects: 0.58Split by the unit that repeats, and assert it: subject in a brain-decoding study, camera burst in a wildlife-camera dataset, page in a document-transcription task, source document in a retrieval pipeline. The assertion runs every time, so it is never forgotten. Checks that must be remembered are eventually skipped.
If you did not find it, that is the usual outcome. Nothing in this
code looks wrong, no error is raised, and the score rewards not looking
further. This is the plausible-average-case failure from the previous
episode: train_test_split is the pattern in a million
notebooks, and the agent optimized for apparent completion, a clean run
and a high score. If your review consists of “does it run, is the score
good”, you and the agent have the same blind spot.
Autonomy is purchased with verification
The highest-leverage practice in agentic coding is to make verification executable. Agents perform markedly better when they can check their own output by running tests, comparing against known values, and validating properties, rather than relying on you as the only feedback loop. Include test cases in the prompt. Point at symptoms rather than fixes (“fix the root cause and verify; do not suppress the error”). For analyses, require printed evidence. Tests are now inexpensive to write: ask for them with every feature, ask for data-validation tests on the actual dataset (expected columns, value ranges, unique identifiers, row counts across merges), and ask the agent what inputs would break its own function.
The more trustworthy the checks, the more autonomy can safely be granted. Scale the checking to the stakes, and choose the tier explicitly before starting:
| Tier | Example | Minimum verification |
|---|---|---|
| Throwaway | one-off plot, scratch script | Read the diff; inspect the output |
| Working code | lab-internal pipeline, reusable utilities | Tests pass in CI; you review the diff; data-property checks printed |
| Load-bearing | results in a paper, shared package, anything cited | All of the above, plus comparison to a source of truth and a second reviewer |
- Checking is the bottleneck. Agents multiply commits far more than releases, pull requests are larger and harder to review, and unreviewed merges increase. Verification is the scarce skill.
- The pull request is the final human check. Review by eye alone does not scale, so it needs tests on every push and checks that fail loudly.
- Established practice still applies: know your data, compare to a source of truth, know what your model responds to, reproduce the result, plot and review.
- Test-driven development reverses the usual order: write the test that states the required behavior first, then have the agent make it pass. The test is the specification.
- For research code, the tests to write first are about the data and the result: data expectations, a hand-checked subset, seed stability, sensible top predictors, no leakage. Each can be a test the agent writes and CI runs.
- Split by the unit that repeats, and assert it. A clean-running 0.91 can be 0.58 on unseen subjects.
- After every feature, before the next: have the agent list its assumptions, propose tests and edge cases, add them, and run them. Then commit.
- Make verification automatic: tests in CI and a protected
main. Autonomy is purchased with verification. - Choose a review posture deliberately: the pull request as the gate (the agent commits freely; one full review of the diff) when tests and CI support it; per-change review when they do not. Incoming pull requests on a shared project are untrusted input, and the human makes the merge decision.
- Leave evidence in the repository and direct the agent to it. It reads figures and metrics, but only those you name, and you check every number it cites.
Content from MCP Tools and Skills: Extending Your Agent
Last updated on 2026-09-16 | Edit this page
Estimated time: 20 minutes
Overview
Questions
- How does MCP differ from an API, and when is each appropriate?
- What is an MCP server, and what happens when I connect one?
- What is inside a skill, and how does an agent decide to use one?
- What additional scrutiny does connecting an MCP server or installing a skill require?
Objectives
- Explain the difference between an API (you write the calling code) and MCP (the agent discovers and calls tools itself).
- Connect an MCP server and use it for one task without naming the tool.
- Install a published skill, trigger it, and explain what changed.
- Distinguish a context file, a skill, a hook, and an MCP server, and choose the right one for a recurring workflow.
- Apply the safety episode’s trust rules to a new MCP connection or skill.
- Locate community skill and MCP directories to check before building your own.
MCP compared with an API
An API is a contract you write code against: one integration per service. You read the documentation, write the request, and parse the response.
MCP (Model Context Protocol) is a standard for connecting tools and data to any agent. The integration is written once, and every MCP-compatible client can use it. With an API, you write the calling code. With MCP, the agent discovers the available tools and decides when to call them. Anthropic open-sourced MCP in November 2024; it is now supported by Claude, Copilot, and most other agents.
The rule of thumb: use MCP when the agent should reach a system on its own; use a direct API when you are writing the pipeline code yourself. MCP matters for agentic coding specifically because the agent, not the user, decides when to consult GitHub, a database, or a lab notebook.
What an MCP server is
An MCP server is a small program that exposes tools, resources, and
prompts to an agent over a standard protocol. It runs locally over stdio
or remotely over HTTP. Examples include the GitHub, filesystem, Slack,
and Postgres servers. When a session starts, the agent lists the
server’s tools (search_issues, run_query, and
so on) and calls them like any built-in tool. Connecting a server is
comparable to installing a plugin: it gives the agent a new capability
without any change to the agent itself.
The safety episode’s rules apply. Only add MCP servers you trust: tool output enters the agent’s context directly and the agent acts on it. An issue body or pull-request description fetched over MCP is exactly as untrusted as a README you did not write. Two rules follow:
- Scope the token to the minimum the task needs. A read-only token for summarizing issues; never a token with delete or administrative scope, and never your everyday organization-wide token on a workshop laptop.
- Configure per project rather than globally, where the tool allows it.
Exercise: Connect an MCP server (5 minutes)
GitHub’s official MCP server is a suitable first connection: most participants already have an account, and it can be kept read-only. Use a token with read-only scopes (see setup).
Then give a natural-language request that requires the tool, without naming it:
What are the five most recently opened issues on
<org>/<repo>, and which look stale?
Two things to observe: the agent chose the tool without being told which one, and an approval prompt appears when it first calls the server. That prompt is the same control described in the safety episode.
The agent is now calling GitHub’s API rather than answering from training data. Ask yourself what wider access it would need to do the next thing you would want (open a pull request, close an issue, write to a database), and whether you would grant it. Most people hesitate. That hesitation is the minimum-access principle applied correctly.
What a skill is
A skill is a packaged, reusable set of instructions:
a folder containing a SKILL.md file and optionally scripts,
which the agent loads on demand. Unlike MCP, a skill needs no running
server and no network call. It is markdown and possibly a script in a
folder. It is triggered automatically when a task matches its
description, or invoked directly with /skill-name.
If an MCP server gives the agent a new tool, a skill gives it a procedure: written instructions for one job, loaded without re-explanation in each session. Skills suit repeatable workflows: a review checklist, a repository-specific release process, a data-format specification, a group’s analysis conventions.
A skill cannot make the agent do anything it could not already do by reading files and running commands. The description is the important component, because it is what the agent matches against. A vague description (“helps with releases”) triggers unreliably; a specific one (“use when the user asks to cut a release, bump a version, or write release notes”) triggers when intended.
Skills also reduce cost. The full skill content is expanded only when relevant, rather than occupying context for the whole session as an overlong context file does. This is one of the token-saving measures in the next episode.
Exercise: Add the caveman skill (5 minutes)
A trivial, zero-risk skill is the quickest way to observe the mechanism. Caveman is a public plugin that rewrites the agent’s replies in a terse, telegraphic style. The author measured about 65% fewer output tokens with technical content intact. The effect is immediately visible, which makes the token saving concrete.
This is a plugin install rather than a hand-written skill file; the
mechanism is the same, packaged for distribution. To write your own,
create .claude/skills/<name>/SKILL.md with a
name, a description stating when to use it,
and the instructions:
The caveman skill demonstrates the mechanism. The practical use is packaging an instruction you would otherwise repeat. Choose one thing you find yourself re-typing in your own project (a commit-message convention, a data-checking routine, a report template) and turn it into a skill. Most people find that their first description is too vague to trigger reliably, which is useful practice in writing precise instructions generally.
Hooks, and when to codify what
Skills and MCP are two of four ways to record a recurring workflow instead of re-prompting it. The other two:
-
The project context file (
CLAUDE.md,AGENTS.md,copilot-instructions.md) holds standing instructions the agent reads every session. It is advisory. -
Hooks are deterministic scripts that run at fixed
points, such as after every edit or before every commit. Unlike
context-file instructions and skills, which the model may or may not
follow, hooks always run. Use them for rules that must never be skipped:
run the linter, block writes to
data/raw/.
A reasonable progression: context file first; a skill when you notice yourself repeating instructions; a hook when a rule needs enforcement rather than a reminder; MCP when the agent needs an external system.
Where to find more
Before building your own, check what has already been published:
- Parse.bot MCP marketplace: turns websites into typed, callable APIs exposed over MCP, with thousands of prebuilt endpoints for sites that have no purpose-built server.
- Matt Pocock’s skills: workflow enforcement, including test-driven development, planning, debugging, and git guardrails.
- gstack: Garry Tan’s Claude Code setup, with plan review, code review, QA, and shipping workflows as skills.
- Claude Science: Anthropic’s workbench for scientists, with analysis specialists and access to scientific databases as skills and connectors.
- ToolUniverse: Harvard’s open platform of thousands of scientific tools (databases, models, workflows), exposed over MCP with a Claude Code plugin.
- modelcontextprotocol/servers: the official reference MCP servers and the wider registry.
Treat these as the trust episode treats a package: read before you install. A skill is a set of instructions the agent will follow, and an MCP server is code that runs with whatever access you grant it. A well-known author is a reason to look first, not a substitute for looking.
- API: you write the calling code. MCP: the agent discovers the tools and decides when to call them. Use MCP when the agent should reach a system on its own, and a direct API when you are writing the pipeline.
- An MCP server exposes tools, resources, and prompts over a standard protocol. Connecting one is comparable to installing a plugin.
- A skill is a procedure: packaged instructions loaded on demand, with no server and no network. It saves context because it expands only when relevant.
- Context file, then skills, then hooks (which always run), then MCP: codify a workflow at the lowest level that enforces what you need.
- Everything an MCP tool returns is untrusted input. Scope tokens to the minimum and configure per project.
- Vet a skill or MCP server before installing it, regardless of the author. Parse, Matt Pocock’s skills, gstack, Claude Science, and ToolUniverse are reasonable starting points.
Content from Cost, Context, and Energy
Last updated on 2026-09-16 | Edit this page
Estimated time: 15 minutes
Overview
Questions
- How much energy does an agentic coding session use?
- Why do agentic sessions cost so much more than chat queries?
- Which habits reduce token usage without reducing quality?
Objectives
- Give an order-of-magnitude energy figure for a chat query, a coding session, and a heavy agentic day, and explain why the estimates vary.
- Explain why token use grows faster than linearly over a long agentic session.
- Use
/cost,/compact, model switching, and skills (or their equivalents) to manage context and spending. - Compare real session cost across models before committing to one.
Energy use of AI models
A common claim is that a single prompt consumes gallons of water. The estimates below replace that claim with numbers. They vary by an order of magnitude, and no provider publishes per-query figures, but the range is well established:
| Activity | Energy | Source |
|---|---|---|
| One chat query | ~0.3 Wh, about two minutes of an LED bulb | Epoch AI per-token estimates |
| One median coding session (24 model calls, ~590k tokens) | ~41 Wh, roughly 130 chat queries | Simon Couch, 2026 |
| One heavy agentic day | About one dishwasher cycle, or a refrigerator for a day | Simon Willison, 2026 |
| A median session on large analyses with subagents | ~600 Wh | Zeke Hausfather, 2026 |
Couch scaled Epoch AI’s per-token estimates by his own Claude Code token counts. Hausfather ran his own tokens through three published methods and obtained a figure an order of magnitude higher, because he runs subagents on large analyses. Nobody outside the labs knows the true per-token energy. The defensible statement is an order of magnitude rather than a precise figure: tens of watt-hours per session, hundreds under heavy agent use.
Two conclusions hold regardless of the uncertainty:
- The issue is aggregate demand. Individual queries are light, but at scale they add up. OpenAI’s chief executive has noted that a single California almond requires as much water as tens of thousands of ChatGPT queries. The comparison was meant to minimize per-query impact; it also shows how small unit costs accumulate when billions of queries are processed daily.
- Inference dominates training. Most AI energy now goes to serving queries rather than training models, so usage patterns are the variable within the user’s control.
This is not an argument against the tools; productivity per unit of energy may well exceed the alternative. It is an argument for deliberate use. An agent that loops because of a vague prompt spends energy a clear prompt would have saved.
Why agentic sessions use many tokens
A chat query is one round trip. An agentic session chains hundreds: read files, reason, write code, run commands, read the output, repeat. A focused task might use 50K–200K tokens; an underspecified session can exceed a million. Two mechanisms account for this:
- Agentic loops. A vague prompt sends the agent into cycles of trying, failing, reading more, and trying again. This is the same failure described in the feature-based-development episode: vagueness costs quality, money, and energy.
- Context accumulation. Every new message resends the accumulated conversation, including file contents and command output. The fiftieth message in a session costs far more than the first.
Reducing token use
- Watch usage. Knowing what you are spending is also how you detect an agent that is retrying in a loop.
- Match the model to the task. Not every task requires the most expensive model. Use a smaller model by default for mechanical work (renames, formatting, lookups) and switch to a larger one when the task requires the reasoning. Providers do not route for you; they are optimized for spend rather than efficiency.
- Keep sessions short. As a session grows, old context accumulates and every subsequent message pays for it again. Start fresh between unrelated tasks; compact a long thread rather than letting it grow. Prefer search over reading whole files, since context is what you pay for.
- Use skills. A skill loads a short pointer instead of a long explanation each time. The caveman skill from the previous episode reduces output tokens by design.
- Run long or independent tasks in a background agent rather than in a foreground session you are watching.
- Compare real session cost across models before committing to one. OpenRouter’s session-cost rankings report what people spend per session across live agentic-coding traffic, which is a useful check against vendor benchmarks.
In any tool, correct course early. An agent heading in the wrong direction generates output that is then carried in context, at cost, for the rest of the session. A specific prompt in a clean context is at once higher quality, cheaper, and lower in energy.
Use the model to build tools, not to be the tool
The wasteful pattern is not agentic coding but using a frontier model for every individual question: pasting data into chat to inspect it, asking it to convert units or check a threshold, repeatedly. Code generation reverses this. The model’s compute is spent once to produce a script, and the script then runs deterministically at a negligible fraction of the energy, indefinitely and reproducibly. If you ask an AI the same kind of question repeatedly, that is a script that has not yet been written.
Exercise: What did this session cost? (5 minutes)
- Check what your session has consumed (
/costin Claude Code; the usage dashboard for Copilot) and record the figure and the model. - Estimate the energy: if a median session is about 41 Wh, scale by the fraction of a typical session you have used (tokens are a reasonable proxy). How many chat queries is that? What fraction of a dishwasher cycle?
- Review the session history. Which single interaction consumed the most? Was it a vague prompt that produced a loop?
Most workshop sessions come to a few watt-hours, a small percentage of a dishwasher cycle. The informative result is usually the third item: one underspecified prompt accounts for a disproportionate share of the total. A clearer sentence in that prompt would have avoided those tokens.
- A chat query is about 0.3 Wh; a median coding session about 41 Wh; a heavy agentic day about a dishwasher cycle. Estimates vary by an order of magnitude, so think in tens to hundreds of watt-hours per session.
- The issue is aggregate demand, and inference now dominates. Usage patterns are the variable you control.
- Agentic sessions chain hundreds of model calls, and context accumulation makes late messages far more expensive than early ones.
- Watch usage, match the model to the task, keep sessions short and compact, use skills, and compare real session cost across models before committing.
- A specific prompt in a clean context is better, cheaper, and lower in energy. One discipline, three benefits.
Content from What the Research Shows, and Where This Leaves Us
Last updated on 2026-09-16 | Edit this page
Estimated time: 17 minutes
Overview
Questions
- Who benefits from these tools, and on which kinds of work?
- Is programming dead?
- What should I do differently starting tomorrow?
Objectives
- Summarize what early research says about productivity effects and who gains most.
- Explain why agentic coding is another abstraction layer, and the first non-deterministic one, and what follows for how much specification and verification it needs.
- Commit to three concrete practices for your next project.
What the research shows so far
The evidence base is young, but several findings recur:
- Coding speed is only one bottleneck. Agents multiply commits (+240%) far more than releases (+30%), and pull requests wait about five times longer for human review under heavy AI use (the verification episode’s figures). Analyses still require expert review and verification, and that step does not accelerate.
- Perceived and measured speed can diverge. In a 2025 randomized trial (METR), experienced open-source developers believed they were about 20% faster with AI tools on their own mature repositories while measuring about 19% slower. The rule applied to model scores applies to one’s own productivity: measure it.
- Learning with AI can cost understanding. In Anthropic’s 2026 study, developers who learned an unfamiliar library with AI assistance scored 17% lower on a quiz covering concepts they had used minutes earlier, with the largest gap on debugging questions. The participants who retained understanding used the assistant to ask why, not only to produce code (Anthropic, 2026).
- Gains are uneven. Experienced practitioners, who can specify precisely, review effectively, and recognize plausible-but-wrong output, obtain more value; novices are more likely to accept flawed results. Verification skill, not typing speed, is the limiting factor.
The evidence supports the conclusion that these tools amplify expertise more than they replace it. The practices in this lesson (scoping, specifying, verifying) are the expertise being amplified. The question of skill formation remains open: if agents do the routine work, where do junior researchers develop the debugging judgment that supervising an agent requires? Deliberate practice may need to be scheduled where it previously occurred as a by-product.
Is programming dead?
Before reading on, discuss with a neighbor. What in your own work became faster this session, and what did not?
Is programming dead? The evidence says no
Programming has been declared obsolete before. Assembly gave way to compilers and then to languages such as Python; manual memory management gave way to garbage collection; servers gave way to the cloud. Each time, the work moved up a level of abstraction and the discipline adapted. Agentic coding is the same transition, with one difference: the new layer is not deterministic. Compiling the same C source twice yields the same program, which is why nobody audits compiler output. The same prompt can yield different code on different days, and every unstated decision is filled in with the average case.
The craft of agentic coding is therefore making the layer deterministic enough. That means specifying and verifying at the level this lesson has practiced: a plan with a check for each step, one feature per prompt, tests the agent must pass, a review of every diff. Too little of this and the output is plausible and wrong. Too much, and the time spent writing prompts approaches the time it would have taken to write the code. The balance sits between those, and the evidence is that at the feature level the productivity gains are substantial.
Those gains are a function of prior expertise. Deciding what to build next, recognizing a plausible-but-wrong result, knowing which check matters for this data: these come from the person, not the prompt or the model. Agents amplify expertise; they are not a substitute for it, and they are not a magic wand. Programming is not dead. The work has shifted toward specifying intent, designing verification, and exercising judgment, which were always its difficult parts, and good data science practice still applies in full.
Pass it on
When you use AI to teach yourself something, write it up and share it. If it took many attempts to obtain a working pattern from an assistant, and the raw answer was only mostly correct until you fixed it, that effort has value beyond you. A blog post, an annotated notebook, a how-to guide, or a lesson contribution lets the next person start from your verified version rather than repeating the attempts.
This is the community-scale version of the energy argument in the previous episode: the compute is amortized across every reader instead of being spent again by each. It also follows from the note on documentation in the feature-based-development episode: the notes you leave for your future self are usually a short edit away from being useful to a stranger. At UW–Madison, the ML+X Nexus exists for this purpose (guides, notebooks, workshop materials, and posts from the community, including the guides this lesson draws on). Elsewhere, a lab blog, The Carpentries Incubator, or a well-documented public repository serves the same function.
Three things before your next sprint
Before your next project session, commit to:
-
Set up the guardrails once. Secrets in a keyring or
secrets manager (nothing in plaintext on disk), a project context file
(
CLAUDE.md,AGENTS.md, orcopilot-instructions.md) under 100 lines, and a branch-only workflow. - Write the contract first. For the next feature you delegate, write one test or printed check that encodes what “correct” means for your data, before you prompt.
- Review one full diff as a skeptical referee. Take one agent-produced change and review it as if a stranger had submitted it to your paper’s supplementary code: examine the data it touches, check a number against a source of truth, and determine what the model is responding to.
- Agentic tools amplify expertise. Verification skill, not typing speed, is the limiting factor, and perceived speedups can be illusory, so measure.
- Learning with AI can cost understanding (17% lower quiz scores, largest gap in debugging). Use the agent to ask why, not only to produce code.
- How novices build supervisory expertise in an agentic setting is an open and serious question.
- Agentic coding is another abstraction layer, like the move from assembly to Python, but a non-deterministic one. The craft is making it deterministic enough through specification and verification, without spending more time prompting than writing the code would take.
- At the feature level the productivity gains are substantial, and they scale with prior expertise. Agents amplify expertise; they are not a magic wand.
- The work shifts toward specifying intent, designing verification, and exercising judgment, and good data science practice still applies in full.
- When AI teaches you something at some cost, write it up (blog, notebook, lesson) so the next person starts from the verified version.