Stanford overhauls software engineering course after students started solving the assignment with an agent

No CS146S, disciplina que Mihail Eric leciona em Stanford e testa na prática como líder de IA na Monaco, o dever de casa agora é mandar patch para projeto open source de verdade, porque exercícios fechados já caem num único prompt.

In CS146S, the course Mihail Eric teaches at Stanford and puts into practice as head of AI at Monaco, homework now means sending a patch to a real open source project, because closed-ended exercises already fall to a single prompt.

Mihail Eric gives two different answers to the same question: what a software engineer needs to know to work today. One answer is CS146S, the elective course he teaches at Stanford under the name The Modern Software Developer. The other is his routine as head of AI at Monaco, a startup where colleagues use code agents both to ship features and to investigate production incidents. He told both stories in an interview of over an hour on the Latent Space podcast, published on November 8, 2026, by editor swyx, as a preview of the AI Engineer CODE conference taking place the following week in San Francisco.

The account matters to anyone who hires, trains, or is a junior right now: it shows, with names and numbers, what a top university has already considered obsolete within the span of a single academic year.

When the Exercise Becomes a Single Prompt

CS146S's first class, in the fall of 2025, had nine exercises and a final project. One of them asked the student to run an AI-based code reviewer over a repository and evaluate the output. It made pedagogical sense: it exposed the student to the tool and to the kind of feedback it generates.

The problem showed up in the course's second offering. Mihail Eric noticed that much of this homework had turned into a single-prompt task. In an informal survey of the class, made up of second- and third-year students, no student said they still wrote code by hand: everyone already used some agent on a daily basis. An exercise designed to teach had become, in practice, a test of who could phrase the request best.

The Assignment Now Is to Send a Patch for a Human to Review

The solution wasn't to make the prompt harder. It was to change the target. Part of the new class's homework is to actually contribute to an open source project, with the repository's maintainer reviewing the patch the student submits. The agent still handles the implementation in an afternoon. What it doesn't handle is figuring out whether the maintainer wants that change, why the code behaves that specific way, and what the patch might break elsewhere in the system.

It's that friction, the conversation with whoever decides what goes into the project, that's missing from a closed-ended exercise. Mihail Eric describes the mechanism as the same one that makes a junior engineer learn from a senior: it's not the line of code, it's the reasoning behind it.

Editor's note: the descriptions of third-party tools and cases cited in this article (explain-diff, by Geoffrey Litt, and Minions, by Stripe) are based on the interviewee's account and the Latent Space episode notes, not on official documentation from the respective makers. Validate how these tools work before using them in production.

One tool mentioned in the interview helps exactly with this point and works for any agent-generated PR, not just for the classroom. According to Mihail Eric, the explain-diff skill, by Geoffrey Litt, takes a code change and turns it into a visual step-by-step walkthrough, followed by questions about what changed. Running it on the last patch an agent wrote is a concrete way to find out which question can only be answered by reopening the code.

Buy to Learn, Build to Keep

The second half of the interview leaves the classroom and enters Monaco's engineering, where Mihail Eric deals with the same question at product scale. The team evaluated several automated code review tools and kept Devin. For agent workspaces, the environment where an agent runs the product, reproduces a bug, and tests its own patch, the path was different: build in-house, because the detail of how the company's cloud is configured isn't solved by an off-the-shelf product.

Mihail Eric sums up the criterion like this:

You buy to learn, and you build to keep.

Mihail Eric, head of AI at Monaco

The in-house result is called Hal. An engineer asks it to investigate something that broke and open a PR. A salesperson asks the same system how a product feature works. The useful output isn't the same in both cases: for the developer, it's a reviewable change; for the salesperson, it's an explanation they can pass along to the customer. Handing both people a dump of debug logs would only serve one of them.

Review Became the Bottleneck, and the Numbers Confirm It

The interview cites a figure from the study How to Kill the Code Review, produced by Faros: teams with high AI adoption closed 98% more pull requests, but the review time for those PRs rose 91%. The agent speeds up writing; reviewers haven't sped up at the same rate. This lines up directly with the reason Stanford swapped the closed-ended exercise for a flesh-and-blood maintainer: the stage that resists automation is precisely the one where someone decides whether the change should go into the project.

For teams already feeling this traffic jam, the interview also revisits the Five Stages of AI Adoption, a framework by Boris Cherny used as a reference toward the end of the conversation to separate personal adoption (a single developer using an agent on their own) from team autonomy (process and review redesigned around the agent). These are different stages, and confusing one for the other is like measuring individual productivity and assuming it solves collective review.

What's Missing: Institutional Memory of the Code

An agent sees the current state of the repository. What it doesn't see, according to the point raised in the interview based on the concept of Authority Map (from Basis), is why the team rejected a similar change six months ago. This gap in historical context is why Mihail Eric bets that open source repositories will turn into agent-operated software factories, with a human still deciding what goes in. It's also why having a student talk to a maintainer today is still worthwhile: someone needs to hold onto that memory the agent has no way to pull from.

The conversation also cites, according to the interviewee's account and the episode notes, the case of Stripe's Minions as a production example of a background agent with its own environment and a defined path to an engineer's review, and mentions in passing the convergence of infrastructure around MCP portals as a trend discussed in the episode.

What Doesn't Change

Mihail Eric is explicit about the limits of the course itself: CS146S doesn't replace traditional computer science, doesn't teach algorithms from scratch, and assumes a student with a solid foundation. The course's focus is what to do with that foundation when implementation work can be delegated to an agent: architecture, system trade-offs, and the hiring bar, which he describes as much higher for someone entering as a junior today, close to what was expected of a senior just a few years ago. For those hiring in Brazil, the takeaway is less about which tool to buy and more about which part of the work still requires someone deciding, not just generating.

Source

Latent Space, "How Stanford Teaches AI-Native Engineering, Mihail Eric, Monaco" (https://latent.space/p/cs146s/), published on November 8, 2026.