Stanford CS146S Notes: An 8-Week Map from Prompt to Agent Manager
CS146S — The Modern Software Developer is a new Stanford course from Fall 2025, taught by Mihail Eric, with a heavyweight guest each week (Boris Cherny, Zach Lloyd, Isaac Evans, Tomas Reimers…). I worked through all eight weeks in the official assignments repo and did the exercises along the way. This post is the consolidated note.
1. The Course’s Real Theme: A Shift in Developer Identity
The tagline on the course site is unusually direct:
“Many AI coding courses only teach you how to write fast — this course draws the baseline for shipping: testable, auditable, defensible.”
If you only skim the weekly schedule, you’d think it’s “An AI Tools Survey.” But after reading the materials and doing the assignments, a more honest description is:
It is systematically training you to become an Agent Manager.
Not “learn to code with ChatGPT,” but: stop being the person who writes the code and become the person who directs Agents to write it — and who owns the result. Boris Cherny (creator of Claude Code) gets quoted again and again:
“It’s not so much about deep work, it’s about how good I am at context switching and jumping across multiple different contexts very quickly.”
The eight weeks fall into three storylines:
- Prompt → Context (Weeks 1 → 3): from writing one good prompt to architecting a whole information environment
- Coder → Agent Manager (Weeks 2 → 5): from writing code yourself to directing and orchestrating multiple Agents
- Speed → Defensible (Weeks 6 → 8): from rapid output to auditable, defensible, ship-ready
The rest of the post follows those three lines.
2. Storyline One: Prompt → Context
Week 1: Six Foundational Prompting Techniques
Week 1 runs local models through Ollama and drills six techniques in turn: K-shot, Chain-of-Thought, Tool Calling, Self-consistency, RAG, Reflexion. One Python file per technique, iterate the prompt until tests pass.
The takeaway isn’t “I learned six tricks.” It’s: these aren’t parallel options, they form an evolutionary chain.
- K-shot gives the model a pattern
- CoT gives it room to reason
- Tool Calling lets it stop guessing and actually look things up
- Self-consistency trades sampling cost for stability
- RAG plugs external knowledge into the context
- Reflexion lets the model critique its own output and try again
By Reflexion, the model has gone from “answer machine” to “small self-correcting loop.” That is the seed of an Agent.
Week 2: First Time Closing the Loop on a Real Task
The assignment is a minimal FastAPI + SQLite Action Item Extractor: free-form notes → structured todo list. Use Cursor’s Agentic Mode to land five TODOs: replace rule-based extraction with an LLM, add unit tests, refactor, add a new endpoint + frontend button, generate a README.
In my own practice notes I distilled a minimum capability model for “a local Agent that executes simple requirements”:
understand intent → fetch code context → plan → generate code → verify → feedback
↑ |
└────────────── on failure, backtrack & correct ←─────────────────┘
Each step maps onto a Week 1 technique. Agents are not a new invention; they are those atomic capabilities wired up around this loop.
After running it end-to-end the strongest impression: today’s Agents shine on tasks with clear boundaries that you can verify. Scaffolding, single-function implementations, happy-path tests, doc generation — these are strengths. Deciding “what not to change,” reasoning about cross-module side effects, refactors that involve real tradeoffs — those still need a human.
Week 3: From Prompt Engineering to Context Engineering
Week 3 is the densest week of the course (the other one being Week 6). Boris Cherny is the guest. The thesis traces back to Andrej Karpathy’s definition:
“Context engineering is the delicate art and science of filling the context window with just the right information for the next step.”
| Dimension | Prompt Engineering | Context Engineering |
|---|---|---|
| Focus | What you say to the model right now | What the model knows when you say it |
| Scope | One carefully crafted instruction | The whole information ecosystem: memory, tools, retrieval |
| Nature | Static template | Dynamic infrastructure |
| Analogy | Handing a script to an improv actor | Building the whole stage, props included |
Two things in this week made me re-examine how I work:
“Context is King” — and a precondition for intelligence. A line that hits hard: “Claude is already smart enough — intelligence isn’t the bottleneck, context is. When the Agent fails, the instinct is to blame the model, but it’s almost always wrong. What’s actually underperforming is the information environment around it.”
Context Rot. Model performance degrades with input length, even on simple tasks. So /clear, /compact, tiered memory, keeping CLAUDE.md lean — these aren’t aesthetic choices, they’re performance strategies.
The Week 3 assignment is to build a custom MCP Server. I built a GitHub Issue assistant: 3 Tools (search_issues / create_issue / get_issue_detail) + 1 Resource (repo metadata) + 1 Prompt (bug report template), STDIO transport into Claude Desktop.
Building it by hand is the only way I really understood: the three MCP primitives (Tools / Resources / Prompts) aren’t abstract concepts — they map to three different ways an Agent “knows” something — what it can do, what it can look up, how it should phrase things.
Boris also shared his daily workflow: 20–30 PRs a day, sustained by running 5 Claude Code instances in terminals plus 5–10 sessions on claude.ai/code, every instance starting in Plan Mode, with CLAUDE.md as shared team memory. The line that gets hammered home:
“Give Claude a way to verify its own work — browser tests, test suites, simulators. Verification is what gives you a 2-3x quality improvement on the final output. Everything else (subagents, slash commands, MCP integrations) is built on top of that.”
3. Storyline Two: Coder → Agent Manager
Week 4: Claude Code as Agent Manager
Week 4’s central line:
“The goal is to train you as an Agent Manager — not someone who writes code, but someone who directs Agents to write code.”
This week catalogs 5 agentic workflow patterns:
- Sequential Flow — the default. About 70% of daily work.
- Operator — hierarchical: a central planner + specialized sub-agents
- Split-and-Merge — fan-out / fan-in, up to ~10 parallel branches
- Agent Teams — collaborative; agents can talk to each other across independent sessions
- Headless — triggered by CI/CD, Cron, webhooks; no human in the loop
Plus 12 “Agent Harness Patterns” (persistent instructions, directory-scoped instructions, tiered memory, memory hygiene, context compaction, parallel branching, checkpoint review, selective tool loading, purpose-built tools, permission granularity, lifecycle hooks, compounding corrections).
The line that stuck:
“The problem isn’t your model — it’s your harness. What separates a flashy demo from a production-grade AI system isn’t intelligence, it’s control.”
The assignment: build at least 2 automations (Slash Commands, CLAUDE.md, SubAgents) on a FastAPI starter app. After this week my muscle memory shifted: every time I see a repeated workflow I now ask “could this become a .claude/commands/ entry?”; every time Claude makes the same mistake twice I ask “should this go into CLAUDE.md?”
The phrase Compounding Engineering is one I like a lot: every recorded mistake becomes permanent leverage.
Week 5: The Terminal Is Not a Power User’s Toy
Week 5’s guest is Warp CEO Zach Lloyd. Warp 2.0 reframes itself from “a better terminal” to ADE — Agentic Development Environment.
The comparison table I found most useful:
| Tool | Strength | Weakness |
|---|---|---|
| Warp | Multi-tab parallel agents, visual diff review, multi-model support | Slightly weaker at deep code reasoning |
| Claude Code | Deep context, fine-grained CLAUDE.md control, autonomous reasoning | Anthropic models only |
These stack rather than compete: Claude Code can run inside Warp. The key tool for parallel Agents is git worktree — each Agent works in an isolated working tree, no clobbering, merge branches at the end. I started using this in real work after reading this week.
But the Warp team is honest about the cost: parallelism isn’t free. Saving 6–7 hours a week is real, but only if your cognitive bandwidth can actually steer 5 tabs at once — that turns out to be the real bottleneck.
4. Storyline Three: Speed → Defensible
Week 6: Semgrep and AI Code Security
Week 6 brings Semgrep CEO Isaac Evans. The opening number made me pause:
Claude Code, run as a security scanner, surfaced 46 real vulnerabilities — at a 14% true positive rate and 86% false positive rate.
This isn’t “Claude is bad.” It’s that AI’s security intuition isn’t reliable — out of 7 alerts only 1 is a real issue. Semgrep flips that ratio: 80% fewer false positives, 250% more true positives.
Semgrep’s three products:
- Code (SAST) — first-party code vulns, with cross-file analysis
- Supply Chain (SCA) — reachable CVEs in dependencies (reachability analysis filters out unreachable ones, cutting high/critical-severity false positives by 98%)
- Secrets — hardcoded credentials, with semantic + entropy analysis + live validation
The assignment: run semgrep ci --subdir week6 on a deliberately vulnerable FastAPI app and fix at least 3 findings. The fixes are unglamorous but fundamental: parameterized SQL, restricted CORS, secrets to env vars, dependency upgrades, stronger crypto, sanitized DOM writes.
The blunt takeaway: “Secure Vibe Coding” wants speed and safety unified, not opposed — the way you get there is automating scans into CI rather than retrofitting safety after the fact.
Week 7: Graphite Diamond and AI Code Review
Week 7’s guest is Graphite CPO Tomas Reimers. The thesis:
“AI will never replace human code review. But every PR should be reviewed by AI + human together.”
AI’s strengths in review: style consistency, common bug patterns, security vulnerabilities, code duplication, 100% PR coverage, second-level latency. Human strengths: architectural judgment, business logic correctness, tradeoff analysis, creative alternatives, team context, UX design.
The recommended pattern is “AI First, Human Second”: AI filters the mechanical stuff, humans focus on the high-leverage judgment calls. Graphite’s other product innovation is Stacked PRs — break a big PR into a chain of small sequential ones, because AI review performs noticeably better on small PRs.
The assignment is dense: 4 independent tasks, each going through “create branch → 1-shot AI implementation → manual line-by-line review → open PR → run Graphite Diamond → compare.” Then a written reflection: my review vs Graphite’s, which one was better, when, and why.
That comparative reflection is the most valuable part of the week, in my view. It isn’t teaching you to trust AI. It’s teaching you to know when AI is better than you, and when it isn’t. That meta-cognition is more durable than any specific tool.
Week 8: Bolt.new and Multi-Stack Rapid Builds
Week 8 pivots to “prototype to production.” The guest is Vercel’s Head of AI Research. The framing:
“Rapid prototyping is just the starting point. Between demo and production lies a chasm.”
Bolt.new uses StackBlitz’s WebContainer technology to run Node.js entirely in the browser, generating full-stack apps from prompts. But its capability curve is steep:
| Complexity | Result |
|---|---|
| 3–5 components | Usable in minutes, almost no debugging |
| 10–15 components | Needs prompt iteration, but generally works |
| 15–20+ components | Context degrades, token use spikes |
| Complex state + auth + 3rd-party integrations | Success rate drops to 31% |
The assignment asks you to build the same app in 3 different stacks, at least one via Bolt and at least one in a non-JS language. The design is sneakily clever — it trains two things at once:
- Abstraction — you have to pull the business logic out of the framework and figure out what’s essence vs implementation
- AI-tool literacy — the same prompt produces wildly different quality across Next.js / Django / Rails, so you have to develop a feel for “what does production-ready code actually look like”
5. Three Lessons I Actually Use Daily
After eight weeks of material and a stack of assignments, these are the three I’ve actually absorbed into my workflow:
5.1 Plan Mode Is Free Leverage
Boris’s “never let Claude write code before you have reviewed and approved a written plan” is the most-quoted line of the course. For any task longer than 30 minutes I now hit shift+tab into Plan Mode, iterate with Claude until the plan is right, then switch to auto-accept. Rework rate dropped noticeably.
5.2 CLAUDE.md Is Where Compounding Lives
Every time Claude makes a mistake or I notice a non-obvious project convention, it goes into CLAUDE.md. The habit is incredibly cheap and incredibly profitable — once it’s in there I never explain it again. Just keep it lean: it loads every session and eats context.
5.3 Always Give the Agent a Way to Verify Itself
Boris’s “most important insight.” Concretely:
- Backend work: have Claude run the tests, fail-then-fix, never “looks fine, ship it”
- Frontend work: spin up the dev server and have Claude actually click through the golden path with Playwright
- API integrations: get a minimal curl/httpie reproduction script first
This is just the engineering version of Reflexion (Week 1) — bake “self-review” directly into the workflow.
6. Closing: The Eight-Week Arc
Week 1: How to talk to AI → Prompt Engineering
Week 2: How AI uses tools → Coding Agents & MCP
Week 3: How to build AI's information env → Context Engineering
Week 4: How to manage AI → Agent Manager
Week 5: AI-native terminal → AI Terminal
Week 6: AI code security → Semgrep
Week 7: AI code review → Graphite Diamond
Week 8: AI-built applications → Bolt.new multi-stack
(Weeks 9-10: AI ops + the future → second half of the course)
Each week is the foundation for the next. What you walk away with isn’t a tool manual — it’s a new posture:
You aren’t the person writing code anymore. You’re the person designing the information environment, directing the Agents, and answering for the final output.
Coding speed is up 10x. So is the speed at which you can ship the wrong thing. The baseline this course draws — testable, auditable, defensible — isn’t a constraint. It’s the floor that makes the new posture viable.
References:
- Course homepage: themodernsoftware.dev
- Assignments repo: mihail911/modern-software-dev-assignments
- Community Chinese edition: ShouZhengAI/CS146S_CN
- Claude Code best practices: anthropic.com/engineering/claude-code-best-practices
- 12 Agentic Harness Patterns: generativeprogrammer.com
- How Anthropic Teams Use Claude Code: claude.com/blog
- Andrej Karpathy on Context Engineering (original X post)
- Boris Cherny’s workflow: howborisusesclaudecode.com