Mihail Eric, who teaches The Modern Software Developer at Stanford and leads AI at Monaco, rebuilt his course after finding that every sophomore and junior he surveyed already coded with an agent. The first run of CS146S had nine assignments and a capstone, but many exercises could soon be completed in one attempt, so homework now includes contributing to an open-source project. The story matters because it shows what engineering skill means when code generation stops being the constraint.
How Stanford course and Monaco practice changed
The ten-week CS146S syllabus now sends students to outside maintainers, who review their patches and decide whether a feature belongs in the project. A student can ask an agent to implement a change in an afternoon, yet still must learn why the code behaves as it does, whether the maintainer wants the change, and what else the patch might break. The episode frames that exchange as training for junior engineers, who learn from senior review in the same way. Linked materials list the syllabus, assignments and open-source partners for comparison with the prior year.
At Monaco, colleagues use coding agents to ship software and investigate outages, and the team tested commercial tools before settling on a split approach. For code review products the team evaluated options and kept using Devin, while agent workspaces went the opposite direction. A background agent needs a place to run the product, reproduce a failure and test a patch, and those details depend on how Monaco cloud infrastructure is set up. The team therefore built its own workspaces, following Eric rule paraphrased as buy to learn and build to keep.
The background includes Geoffrey Litt explain-diff skill, which turns a change into a visual walkthrough and then quizzes the reader about it. The suggested exercise is to run it on an agent-written patch and notice which question forces the code to be reopened. Another reference is Basis Authority Map, which addresses where an agent should look for current behavior, earlier decisions and intent. The episode also cites Stripe Minions as a production example of giving background agents an environment with a path to an engineer-reviewed pull request.
What this means for teams using coding agents
For companies, the practical shift is from writing code to reviewing, testing and explaining agent output. Monaco Hal illustrates the pattern: an engineer can ask it to investigate a breakage and open a pull request, while a salesperson can ask how the product works. One case produces a change for review, the other produces an explanation for a customer. Small firms gain a faster route to patches and answers, while large organizations need workspaces, permissions and review capacity so background agents can run safely.
The limits center on review load and missing history. A cited Faros study found teams with high AI adoption merged 98 percent more pull requests, while pull request review time was 91 percent longer. An agent sees current code but not why a similar change was rejected six months ago, which makes decision records and maintainer judgment more valuable. Before choosing tools, companies should verify where agents run, how dependencies and permissions are handled, and who approves the final merge.
A marker to watch is whether open-source repositories become agent-ready software factories with documented intent and decision history, as Eric predicts. If maintainers publish clearer contribution rules and more student patches pass review, the Stanford model is spreading. If review queues keep growing without faster decisions, code review will remain the bottleneck.
