Stanford’s new AI engineering curriculum shifts focus from coding to review
Mihail Eric updates Stanford’s CS146S course to reflect agent-native workflows, emphasizing open-source contribution and custom tooling over basic code generation.
Mihail Eric, who teaches The Modern Software Developer at Stanford and leads AI at Monaco, has updated his curriculum to address how software engineers should learn in an era dominated by coding agents. In a recent discussion with the AI Engineer YouTube channel, Eric outlined how academic assignments and professional workflows are shifting from writing code to evaluating it, managing agent environments, and understanding historical context within codebases.
What happened
The structure of Stanford’s CS146S course has changed significantly between its first and second runs. Initially, the course included nine assignments and a capstone project, one of which required students to run an AI code reviewer on a repository and evaluate its feedback. However, Eric observed that students were already using agents extensively, often completing previous exercises with a single prompt. Consequently, the current syllabus replaces many of those isolated tasks with a requirement to contribute to open-source projects, where human maintainers review student patches.
This shift forces students to engage with the social and technical realities of software development beyond mere implementation. While an agent can generate a feature implementation in an afternoon, the student must still determine if the maintainer wants the change, understand why the existing code behaves as it does, and anticipate potential breakages. This process mirrors the learning dynamic between junior and senior engineers, where the value lies in the conversation and critique rather than just the raw output.
At Monaco, Eric’s team has adopted a similar philosophy in their professional engineering practices. They evaluated various code review products and decided to continue using Devin for certain tasks. However, they found that off-the-shelf agent workspaces did not meet their needs because background agents require specific environments to run the product, reproduce failures, and test patches. Since these details depend heavily on Monaco’s specific cloud setup, the team built their own workspace infrastructure, resulting in an internal tool called Hal.
How it works
Hal serves as a unified interface for different roles within the company, demonstrating how agent outputs must be tailored to the user’s intent. An engineer can ask Hal to investigate a production issue and generate a pull request with a fix. A salesperson can ask the same system how a product feature works. In the first case, the output is a code change ready for human review; in the second, it is an explanation suitable for customer communication. This distinction highlights that raw debugging output is only useful to engineers, while other stakeholders need synthesized answers.
A critical component of this workflow is addressing the "authority map" problem. When an agent proposes a change, it typically sees only the current state of the code. It lacks visibility into why similar changes were rejected six months ago or what architectural decisions drove the current implementation. To solve this, teams must provide agents with access to historical context, such as past pull request discussions and decision logs. Without this context, agents may repeatedly propose solutions that were previously deemed incorrect or undesirable.
Eric also highlights techniques for improving human understanding of AI-generated code. One method involves using tools like Geoffrey Litt’s explain-diff skill, which converts a code change into a visual walkthrough and quizzes the developer on the modifications. This approach ensures that engineers do not blindly merge agent-written code but instead verify their understanding of the logic and potential side effects before integration.
Key details
- Stanford’s CS146S now requires students to contribute to open-source projects with human maintainer reviews instead of completing isolated AI evaluation exercises.
- Monaco built its own agent workspace tool, Hal, because existing solutions could not adequately replicate their specific cloud environment for testing and reproduction.
- Hal generates different outputs based on the user role: pull requests for engineers and explanatory text for salespeople.
- A study cited in the discussion notes that teams with high AI adoption merged 98% more pull requests, but their review time increased by 91%.
- Effective agent workflows require access to an "authority map" that includes historical decisions and past rejection reasons to prevent redundant or incorrect proposals.
- Tools that visualize diffs and quiz developers on changes help mitigate the risk of merging misunderstood AI-generated code.
Why it matters
For software engineers and technical leaders, this shift signals that proficiency with coding agents is no longer about prompt engineering alone. The bottleneck has moved from writing code to reviewing it and providing the necessary context for agents to operate correctly. Teams that fail to invest in custom agent environments or historical knowledge bases will likely see increased churn in pull requests and longer review cycles, as agents struggle to align with established architectural patterns.
The increase in review time despite higher merge rates suggests that human oversight remains critical. Engineers must develop new skills to efficiently audit AI-generated changes, focusing on intent, edge cases, and historical consistency. This requires a cultural shift where code review becomes a deeper investigative process rather than a superficial check, ensuring that speed does not compromise system stability or maintainability.
What you can do
- Replace isolated coding exercises with tasks that require contributing to real open-source projects or internal legacy codebases with strict human review.
- Build or configure agent workspaces that can accurately reproduce your production environment for testing and failure investigation.
- Implement tools that visualize code diffs and quiz developers on the changes to ensure deep understanding before merging.
- Create an "authority map" by indexing past pull request comments, design documents, and rejection reasons for agent access.
- Tailor agent outputs to specific roles, ensuring engineers receive actionable code while non-technical stakeholders receive clear explanations.
- Monitor pull request metrics closely, specifically tracking review time versus merge rate to identify bottlenecks in AI-assisted workflows.



