In a Latent Space podcast and writeup marking the AI Engineer YouTube channel passing one million subscribers, Mihail Eric described changes to Stanford's CS146S course and practices at Monaco, where he leads AI. Eric teaches The Modern Software Developer and said that when he surveyed a room of Stanford sophomores and juniors, everyone reported already coding with an agent. Because students could 'one-shot' many of the first run's nine assignments, the course now requires contributing to an open-source project, with the repo maintainer reviewing the student's patch. Eric framed this as teaching students to learn an unfamiliar codebase, understand why code behaves as it does, and explain changes to the person who decides whether to merge them. At Monaco, the team evaluated code-review products and continued using Devin, but built its own agent workspaces because they depend on how Monaco's cloud is configured. Eric's stated rule of thumb: 'You buy to learn, and you build to keep.' Monaco built a system called Hal that engineers can ask to investigate outages and open a PR, and that salespeople can ask how the product works. The episode also cited a Faros study noting teams with high AI adoption merged 98% more PRs while PR review time ran 91% longer. Timestamps and show notes accompany the full video interview.
- CS146S now requires students to contribute to open-source projects, reviewed by the repo maintainer
- Eric's rule: 'You buy to learn, and you build to keep' — Monaco bought code review (Devin), built its own agent workspaces
- Cited Faros study: high-AI-adoption teams merged 98% more PRs but PR review time was 91% longer
- Episode published by Latent Space to mark the AI Engineer channel reaching one million subscribers
What it means for you
This is a deep-in-the-weeds conversation for people who build software, but one idea in it travels well beyond engineering: when a tool can produce work faster, the bottleneck moves to the review and the decision at the end. The cited study is blunt about it — teams using AI heavily shipped nearly twice as many code changes, but took almost twice as long to review each one. The work didn't disappear; it moved. Eric's buy-to-learn, build-to-keep rule is also a sensible way to think about any tool decision.
Try this
Pick one process where a tool now produces output faster than before (code, drafts, reports, replies). Map what happens after the output is created — who checks it, how long that takes, and whether that step has quietly become the new slow point.
Who should care
Engineering leads and anyone managing a team that has adopted AI for generating work — plus whoever owns the review or approval step downstream of that work.
Skip this if
You don't run a software team and aren't making buy-vs-build tooling decisions. The specifics here are for practitioners; the one portable lesson is in 'try this'.
Sources: Latent Space — read the original