English is the first teaching language. By the end of the course you can deliver changes in a real codebase with a coding agent, confirm that the agent got them right, and explain and modify your own work without an agent.
The course follows the public Fall 2026 calendar of Stanford CS146S in its topics, their order and the position of its deadlines, and adds three things: two weeks on verification (weeks 7 and 10), a project defense, and one decision line at the end of every assignment (accept, narrow, recheck or stop) with the evidence behind it. That course's assignment repository carries no licence, so only its public structure is followed: every assignment, lecture note and rubric here is written for this course, and no text is copied.
Course pages, lecture materials and rubrics are being rearranged to this calendar. Where another page still describes the earlier fourteen-week layout, this syllabus takes precedence.
Overview
- Audience and prerequisites: senior undergraduates and taught master's students in computing or software engineering, with programming, data structures, Git and testing. No experience with AI coding tools is assumed.
- Length: 12 teaching weeks, then an assessment week (expo and defenses) in week 13.
- Two sessions a week: the first is a lecture that generates and then verifies, live. The second is a practitioner guest; in a week without a guest it is a studio, where you work on your own project or contribution while staff circulate. Each session is 90 minutes; the plan is one cohort of 60 students.
- Three lines of work: six assignments (mostly in the first six weeks), four open-source contributions (across two repositories), and one term project (one or two people).
How the course is designed
- Verification first: every example shows both the generating step and the verifying step. No lecture shows "let the agent finish it".
- Individual AI-off evidence is a pass condition: two in-class checkpoints and the defense carry 30 marks, and a student below half of them does not pass.
- Marked on engineering evidence: the project and the contributions are marked on the specification, instruction file, gates, tests, evaluation and your own verification, not on how the interface looks or how many features there are.
- Contributions do not depend on luck: a mark never depends on whether a maintainer replies; where a repository has no partner contact, a teaching assistant gives an acceptance review.
Learning outcomes
- LO1: Explain a coding agent's loop, system prompt and tool definitions, and predict how it fails on context, tools and stopping.
- LO2: Design an agent development workflow: context and specifications, MCP tools, skills, instruction files, hooks, subagents and background tasks.
- LO3: Write a requirement as a specification an agent can implement and a test can check, and revise it when new evidence arrives.
- LO4: Make an unfamiliar real codebase agent-ready, and deliver a change in it without breaking callers.
- LO5: Verify agent-written code with regression and mutation tests, code review, static analysis and security scanning, and defend each acceptance.
- LO6: Evaluate agents: check that a test can fail, that the denominator is complete and that a judge is reliable, and read small-sample results correctly.
- LO7: Recognise and mitigate agent security risks (prompt injection, credentials, supply chain), verifying a defense with a local reproduction and a regression.
- LO8: Describe how a team operates agents (portals, gateways, routing, cost), and how to recover from an incident and prove the recovery with a regression.
- LO9: Collaborate responsibly: follow upstream rules, disclose AI use honestly, submit no low-effort generated work, and decide again when the inputs change.
Outcomes in teaching and individual assessment
| LO | Teaching introduction | Practice and application | Individual assessment evidence |
|---|---|---|---|
| LO1 | Week 1: the internals of coding agents | A1 | CP1; defense |
| LO2 | Weeks 2-4,9: context engineering, skills, customizing the agent and repository, background agents | A2, A3, A4; project | Defense |
| LO3 | Week 2: spec-driven development | Project proposal and technical specification | Defense |
| LO4 | Week 5: agent-ready codebases | A4, A5; contributions | CP1 |
| LO5 | Weeks 6-7: agentic code review and tests that notice a fault | A5; contributions; final project | CP1; CP2 |
| LO6 | Week 10: evaluating agents | A6; final project | Defense |
| LO7 | Week 8: security | Contributions; final project | CP2 |
| LO8 | Week 11: building an AI-native team | Final project | CP2; defense |
| LO9 | Weeks 1-12: every teaching week | The decision line on every assignment; contributions | Defense |
Calendar
| Week | Topic | First session (lecture) | Second session | Due |
|---|---|---|---|---|
| 1 | The internals of coding agents | Build a minimal agent live, then read a real agent's requests: system prompt, tool list, loop and stop. | Studio: capture and read your own session. | A1 |
| 2 | Advanced context engineering | Prompting, research–plan–implement workflows and spec-driven development; MCP and tool design for a model reader. | Studio or guest; contribution projects introduced. | A2; project proposal |
| 3 | Agent skills and the CLI | What a skill encodes; trigger tests and near misses; working from the command line. | Guest or studio. | A3 |
| 4 | Customizing your agent and repository | Instruction files, hooks as gates, subagent roles. | Guest or studio. | Contribution 1; project technical specification |
| 5 | Agent-ready codebases | Structure, documentation, tests and checks that let an agent work; scoring readiness. | Guest or studio. | A4 |
| 6 | Agentic code review | What model review catches, misses and invents; disposing of each finding. | CP1 (30 minutes, on paper), then guest or studio. | A5; CP1 |
| 7 | Tests that notice a fault | A surviving mutant is a gap in the tests; a property and its shrunk counterexample; an agent that weakens a test to pass it. | Studio on your project's tests. | Project alpha and task backlog |
| 8 | Security | Text as data or as authority; an inert local injection chain; scan, triage and reproduce. | Guest or studio. | Contribution 2 |
| 9 | Background agents | Asynchronous and parallel agents; issue-to-pull-request pipelines; what changes when nobody is watching. | Guest or studio. | Contribution 3 |
| 10 | Evaluating agents | Can the check fail, was the pass earned, is the denominator complete; pass@k on a small table; calibrating a model judge. | Studio: audit one instance. | A6 |
| 11 | Building an AI-native team | Portals, gateways, routing and cost; recovering from an incident and proving it with a regression. | CP2 (30 minutes, on paper), then guest or studio. | CP2 |
| 12 | The software factory and what comes next | Self-running pipelines as a claim to test; course review. | Defense walkthrough; studio. | Contribution 4; final project |
| 13 | Assessment week | Project expo. | Individual defenses. | — |
Weeks 7 and 10 are this course's additions. The deadline for work due in a week is Sunday 23:59 of that week.
Assessment
| Component | Marks | When | AI |
|---|---|---|---|
| Term project: four milestones | 20 | Weeks 2, 4, 7 and 12 | allowed |
| Project defense | 15 | Week 13 | off |
| Four open-source contributions | 30 | Weeks 4, 8, 9 and 12 | allowed |
| Six assignments | 15 | Weeks 1-3, 5, 6 and 10 | allowed |
| CP1: AI-off diagnosis, test and repair | 7.5 | Week 6 | off |
| CP2: AI-off review of unfamiliar code and recovery reasoning | 7.5 | Week 11 | off |
| Participation: guest questions, studio, expo | 5 | All term | — |
Passing requires at least 60/100 overall and at least 15/30 across CP1, CP2 and the defense. There are no bonus marks. An assessment not yet taken stays missing; it is not scored as zero.
For each of CP1, CP2 and the defense, a student who first scores below half may take one equivalent resit with the same learning outcomes, duration and difficulty after feedback. The effective mark is the higher of the two, and a resit can replace the original with at most half of the item's maximum. Both the original record and the resit record are kept. A sitting that was validly passed cannot be retaken to raise the mark. A sitting voided by a technical failure or an approved accommodation is replaced by an equivalent sitting and does not use up the resit.
Assignments
Six assignments are worth 2.5 marks each. Each one hands in the work, the verification result and a short explanation, and ends with one decision line and the evidence behind it. Note your AI use once. Assignments are marked on completion and evidence; there are no hidden tests.
| Assignment | Week | What you do | LO |
|---|---|---|---|
| A1 | 1 | Capture one real coding-agent session with a forced failure; label each behaviour as observed or inferred. | LO1 |
| A2 | 2 | Build a small MCP tool server; graded on whether a model can pick the right tool, call it correctly and recover. No third-party sign-in is required. | LO2 |
| A3 | 3 | Write one skill for a workflow you first ran by hand; test that it triggers on the right requests and stays quiet on a near miss. | LO2 |
| A4 | 5 | Make a messy repository agent-ready: instruction file, a hook that blocks a bad commit, structure and checks. | LO2, LO4 |
| A5 | 6 | Score a repository's agent readiness with observable anchors and report what would change the score. | LO4, LO5 |
| A6 | 10 | Audit one evaluation instance and its scorer; state what the results do and do not support. | LO6 |
Term project
One or two people, on a topic of your choice: build working software from scratch with agents. A two-person project has a correspondingly larger scope, and the two defenses are separate.
| Milestone | Week | Content | Marks |
|---|---|---|---|
| Proposal | 2 | What it is, who it is for, the core scenario, and the agent's role in development. | 2 |
| Technical specification | 4 | A design document: requirements, key decisions with a rejected alternative each, interfaces and data models, test strategy, what is out of scope. | 4 |
| Alpha and task backlog | 7 | One minimal path that runs end to end; the repository already has an instruction file and one hook gate; a backlog of remaining tasks. | 6 |
| Final | 12 | Working software; tests with their mutation result; one evaluation script; the disposition of a security scan; a README. | 8 |
| Defense | 13 | Fifteen minutes each, no devices: the examiner changes one thing or plants one fault in your own code, and you locate it, explain it and decide what to do. | 15 |
Marks go to engineering evidence only. Any topic is allowed, but a project with an interface and features and no specification, gate, tests or evaluation earns no milestone marks. The two members of a pair share the marks for the proposal, specification, alpha and final; the defense is marked individually. The expo is held in week 13 before the defenses and counts towards participation.
Open-source contributions
| Contribution | Week | Repository | Marks |
|---|---|---|---|
| 1 | 4 | First | 5 |
| 2 | 8 | First | 10 |
| 3 | 9 | Second | 5 |
| 4 | 12 | Second | 10 |
- Small, then substantial: the first contribution in each repository is a small onboarding fix (5 marks); the second is a substantive change (10 marks).
- Two repositories: you rank your preferences in week 2 and the teaching team assigns your first repository; after contribution 2 you move to a second one. The point is to onboard onto two different real codebases.
- Project list: public open-source projects that partner companies maintain or depend on come first, with other active projects added. A project qualifies with an OSI licence, contribution guidelines, an AI-use policy that permits the work, and no CLA that assigns copyright. At most five students work on one repository at a time. You do not make a marked contribution to a repository owned by your own residency employer. The number of partner repositories and maintainer contacts is not yet confirmed.
- Completion: in a repository with a partner contact, a merged pull request meets the completion condition. Where there is no contact, or a maintainer has not replied within seven days, a teaching assistant gives an acceptance review against the project's own contribution guidelines instead.
- Quality line: low-effort AI output scores zero; the maintainer or the teaching assistant decides. Each contribution needs a check that fails before the change and passes after it, and your own answers to what changed, why, which inputs could break it, and what you verified yourself.
- Boundaries and rights: contribute to public repositories only. Residency, employer or partner-internal code never enters the course or a model. You may use a pseudonym where the project permits it. If you will not publish, or will not sign a CLA or DCO, you may take the course-hosted equivalent route without giving a reason, with the same rubric and maximum.
Workload and participation
There is no hour budget. Weekly time estimates are published after a timed human pilot and include out-of-class cost honestly; required content is not cut to fit a total.
The second session each week is offered to a practitioner for at most 45 minutes, invited for that week's topic, with no product pitch and with sources for any numbers. Write one question beforehand. The course runs with however many guests can come; the number is not yet confirmed. Participation marks cover guest questions, studio work and the expo.
Privacy, fairness and accessibility
Course repositories, prompts, session records and marking material carry no real credentials and no unrelated personal data. Submit only the smallest process record that shows your work, redacted first. Required materials and activities have keyboard-operable, captioned or text alternatives, and you may ask for equivalent time or an equivalent way of taking part; an accommodation keeps the same learning outcomes and the same attainable marks. Oral defenses use a shared rubric and comparable answering time, and a second calibrated marker reviews cases near a threshold, cases where markers disagree and cases a student asks to have reviewed. Course data is not used for teaching research; any later use needs ethics approval and your separate consent first.
Tools and model access
- Coding agent: you use a mature coding agent directly. The course states the capabilities it needs (instruction files, hooks, a permission mode, MCP, subagents, a readable session record) and names no vendor.
- Seats and credit: every student has a working agent seat or credit when teaching starts, at no cost to the student. Teaching credit from partners or providers is used first, and the course budget buys the rest; how much partners provide is not yet confirmed.
- Safety: run the agent in a dedicated directory or container; keep residency, employer and cloud credentials out of that environment; keep keys out of repositories, prompts, screenshots and logs; run the injection demonstration offline against the local machine only. The Week 0 setup page explains each practice and how to check it.
- Other tools: pytest, one mutation-testing tool and one property-testing library, Semgrep, gitleaks, pip-audit.
AI use and responsibility
The checkpoints and the defense are done alone. All other work may use an agent, noted once in the work. Authorship is never inferred from writing style; contradictory evidence goes to a human process.