Stanford's CS336 ships a CLAUDE.md file that tells coding agents what they may and may not do, keeping agents from replacing student learning.
14-day trial. No DevOps. No Sales call. Provisioned in under a minute.
Stanford's CS336 (Language Models from Scratch) ships a CLAUDE.md file in its first assignment repository. The file tells coding agents what they may and may not do while students complete the work. It is a small artifact, but it captures a useful pattern for any course or team that wants to permit agent use without letting agents do the learning. ## What the file actually says The CLAUDE.md sits at the root of the assignment1-basics repository. It is read automatically by Claude Code and similar agents when they are invoked inside the project. The contents are short: a description of the assignment context, a list of behaviors the agent should adopt, and a list of behaviors that are forbidden because they would defeat the pedagogical purpose of the course. The framing is direct. Students are expected to implement byte-pair encoding tokenizers, transformer components, training loops, and optimizer code by hand. The course exists to teach those internals. An agent that simply writes the BPE merge loop or fills in the attention mask logic produces working code and a student who has learned nothing. The file's job is to make that failure mode harder to stumble into. ### The permitted behaviors The guidelines allow the agent to act as a tutor and a reviewer rather than a ghostwriter. Concretely, the file describes acceptable uses such as: - Explaining concepts from the assignment handout when asked. - Pointing out bugs in code the student has already written. - Suggesting test cases or edge conditions to consider. - Helping interpret error messages and stack traces. - Discussing the tradeoffs between two approaches the student is weighing. These are tasks where the agent's contribution is dialogue and review, not authorship. The student still produces the implementation. The agent's role is closer to a teaching assistant during office hours than a contractor. ### The forbidden behaviors The prohibitions target the cases where an agent would substitute for the student's own work: - Writing implementations of the functions students are asked to implement. - Producing complete solutions to assignment problems. - Filling in code blocks that the assignment marks as the student's responsibility. - Generating answers to the written questions in the assignment PDF. The list is short and concrete. It does not try to define academic integrity in the abstract. It enumerates the specific actions an agent should refuse inside this specific repository. ## Why a per-repository file is the right unit There is a long tradition of trying to write policies for AI use at the institutional level. Universities publish statements, course syllabi include paragraphs, and honor codes get amended. Those documents are useful for setting expectations among humans. They do not change what an agent does when a student types a prompt. A CLAUDE.md (or AGENTS.md, or the equivalent for other tools) lives in the repository that the agent actually reads. It travels with the code. When a student clones the assignment, the constraints arrive with it. When the agent opens a file in that directory, the constraints are in its context window. The policy is colocated with the work. This matters because the alternative is to rely on the student to paste the policy into every conversation, which they will not do, or to rely on the agent's default behavior, which varies by model and version. A file checked into the repository is the only mechanism that survives both forgetfulness and tool churn. ### Comparison to other agent configuration files CLAUDE.md is one of several conventions that have emerged for telling an agent how to behave inside a project. The pattern is not new. Editors have had .editorconfig for formatting, linters have had their own dotfiles, and CI systems read YAML from known paths. The agent equivalents play the same role: they encode project-specific defaults so the tool does not have to be configured by hand each session. What is new in the CS336 case is the use of the file for pedagogical scope rather than technical scope. Most CLAUDE.md files in open source repositories describe the build system, the test commands, the directory layout, and the coding conventions. The CS336 file describes what the agent should refuse to do because doing it would harm the human user, even though the human user is the one asking. ## What this tells us about agent design in 2026 Three observations follow from looking at this file in context. ### Refusal is a feature, not a failure mode For most of 2023 and 2024, refusal was treated as something to minimize. A model that refused too often was over-aligned, annoying, useless. The CS336 file inverts the framing. Here, refusal is the entire point. The course wants the agent to decline a specific class of requests so that the student does the work. The agent's value to the course is measured by what it does not produce. This generalizes. In any setting where an agent is delegated authority by one party (the institution, the employer, the parent) but takes instructions from another (the student, the contractor, the child), the alignment problem is not about following instructions. It is about following the right instructions while declining the wrong ones, where right and wrong are defined by a third party who is not in the conversation. ### Policy as text in a known location The CS336 file works because Claude Code reads CLAUDE.md by convention. There is no API call, no signed policy bundle, no enforcement layer. The agent reads a text file and adjusts its behavior. This is fragile in obvious ways: a student can edit the file, delete the file, or use a different agent that does not read it. The course does not pretend otherwise. The mechanism is a default, not a control. Defaults matter anyway. Most students will not edit the file. Most agents in the relevant class do read it. The realistic threat model is not the student who deliberately circumvents the policy, since that student could also just copy a solution from a friend. The threat model is the student who would have used an agent to write the code without thinking about it, and who, faced with a clear in-context instruction not to, will instead use the agent for hints and review. ### The handoff between human and agent has to be designed The most interesting thing about the CS336 file is not the list of rules. It is the implicit claim that there exists a sensible division of labor between the student and the agent for this particular assignment, and that the division is worth writing down. The course is not banning the agent. It is not embracing the agent. It is specifying a particular relationship. This is the work that most teams are not yet doing. The common patterns in industry are either "use the agent for everything" or "do not use the agent on this codebase." Both are easier to enforce and both leave value on the table. The harder work is to say: on this project, the agent does these tasks, the human does these tasks, and here is the file that documents the split. ## Applying the pattern outside the classroom The CS336 approach generalizes to engineering teams, though the motivation shifts. In a course, the goal is to preserve the student's learning. On a team, the goal is usually to preserve code review quality, to keep authorship attributable, or to keep certain subsystems under direct human authorship for safety or compliance reasons. A team adopting the pattern might write an AGENTS.md that says: 1. Agents may generate test cases, refactor for style, and write documentation. 2. Agents may not modify files in the crypto/ or billing/ directories without a human writing the diff. 3. Agents may suggest changes to the migration scripts but must not apply them. 4. Agents must run the test suite before committing and must not commit on red. 5. Agents must include their model version and prompt summary in any commit message. The specifics will vary. The format does not need to be elaborate. The value is in writing down which decisions are still the human's to make, in a file that the agent will read every time. ### Where the pattern breaks down The obvious limit is that the file is advisory. An agent that does not read CLAUDE.md ignores it. A model trained without instruction-following ignores it. A user who pastes the assignment text into a chat interface that does not have repository access bypasses it entirely. The mechanism assumes a particular workflow, and it provides no defense outside that workflow. There is also a drafting problem. The CS336 file works partly because the assignment is well-scoped: there is a clear list of functions to implement and a clear set of questions to answer. In a more open-ended project, "do not write the solution" is harder to specify, because there is no canonical solution to point at. The pattern is easiest to apply when the boundary between agent work and human work can be drawn at the level of files, functions, or specific tasks.