Stanford teaches students to submit patches to maintainers: inside CS146S

What to assign students when an agent does everything itself

It's a familiar problem: you give a junior developer a task, and Claude Code or another agent completes it with a single prompt. Instructors face the same issue. Last year's homework no longer measures what students have learned.

Mihail Eric teaches Stanford's CS146S, The Modern Software Developer, and leads AI at startup Monaco. For the course's second run, he changed the assessment format itself. Open-source project maintainers were brought into the course. Students must understand an unfamiliar repository, propose a change and explain their patch to the person who might merge it.

That maps well to real work. Generating code is now cheap. Understanding someone else's codebase, keeping track of context and taking responsibility for a diff are the expensive parts. A maintainer won't give you credit for an elegant prompt: they'll ask why the change is needed and what it will break.

What survived contact with production

In an episode of the Latent Space podcast marking the AI Engineer channel reaching one million subscribers, Eric walks through the ten-week course syllabus. He explains which lessons proved useful in his own engineering team. Topics include the architecture of a coding agent's loop, tools and harness; context engineering for a large repository; and the skills needed to understand a diff instead of blindly accepting it.

A separate section addresses the build-or-buy decision. Monaco built its own agent workspaces: working environments for each agent. It bought code review tools. Its on-call agent was given access to Datadog and GitHub so it could inspect alerts and connect them to the code on its own. Eric sums up the approach as: buy to learn, build to keep.

Other topics include preparing a repository for agents, what to do when code review becomes a bottleneck, security, dependencies and permissions, background agents such as Stripe Minions, MCP portals and the question of what work remains for developers.

Limitations and practical takeaways

This is a two-hour conversation, not a study with metrics. So far, we have only seen the announcement and table of contents, so specific details and figures will need to be checked in the episode itself. Some of the material is openly promotional: the podcast feed and Monaco are both advancing their own agendas.

The practical takeaway is still useful. If you hire or train junior developers, replace the test of whether they wrote code with a test of whether they understood someone else's code and defended a change. If you're building a team around agents, decide in advance what you consider your core capability and keep in-house, and what you will buy. Above all, prepare the repository for the agent: a clear structure, tests, access to observability and limited permissions. Otherwise, review will become the bottleneck, rather than generation.