Stanford's AI-Native Engineering Course: How to Teach Programming in the Age of Agents

When Homework Can Be Completed with a Single Prompt, How Should the Course Be Taught?

Last May, during the summer after Stanford University's CS146S course ended, Mihail Eric realized an awkward fact: if students can use a single prompt to get a coding agent to complete course assignments, then traditional teaching methods have become obsolete. So in the second iteration of CS146S, he chose a completely different path—inviting open-source maintainers into the classroom and having students face real, unfamiliar codebases.

This teaching experiment comes from Mihail Eric's sharing on the podcast "One Million AI Engineer Special." He is also the founder of Monaco and an instructor of this AI-native engineering course at Stanford. According to him, the core design of the course is: students must learn an unfamiliar repository, propose a change, and complete the entire process from understanding to submission.

From "Completing Assignments" to "Solving Real Problems"

Open-Source Maintainers Become Course Partners

The focus of the CS146S second iteration reform is to shift course assignments from simulated scenarios to real open-source projects. Mihail Eric invited open-source maintainers to participate in the course, with maintainers providing real problems from their own projects, and students needing to propose change solutions in codebases they have never encountered before.

This design directly addresses the core challenge of AI-native development: engineers no longer primarily face "writing code from scratch," but rather "locating problems in existing systems, understanding context, and making safe changes." When agents can rapidly generate code snippets, human value is more reflected in judgment and direction selection.

What Students Must Experience

According to Mihail Eric's description, the course requires students to complete three key actions: learn an unfamiliar repository, propose a specific change, and drive it to implementation. This process deliberately preserves the friction of real engineering—codebases may have historical baggage, documentation may be incomplete, and maintainers may have their own priorities.

This differs from the previous model of "assign an algorithm problem, submit a solution that passes tests." Students need to proactively understand project context, communicate with maintainers, and make decisions amid uncertainty.

In actual workflows, "proposing a change" in an open-source repository often takes the form of a pull request: contributors first fork the repository, submit modifications on an independent branch, and then initiate a merge request to the original project for review by maintainers. The review process checks code style, test coverage, commit message conventions, and whether backward compatibility is broken. For contributors new to the repository, they also need to first read the contribution guidelines (CONTRIBUTING), understand the context of issue discussions, and may need to first explain their approach in an issue to gain maintainer approval. This entire process is exactly the "real friction" the course hopes students will experience—it cannot be skipped with a single prompt, because much of the judgment depends on understanding the project's history and maintainer preferences.

The Teaching Logic of AI-Native Engineering

What Agents Are Good At and Not Good At

Mihail Eric's course design implies a judgment: coding agents perform excellently on tasks with "clear input and output," but still require human leadership in "understanding unfamiliar system intent" and "weighing change risks." Therefore, the course focuses training on the latter.

Changes proposed by students in unfamiliar repositories often need to answer a series of questions: Is this change consistent with the project direction? Will it introduce regression risks? Do existing tests cover the relevant paths? These questions cannot be solved with a single prompt and require engineering judgment.

A coding agent typically refers to a system built on large language models that can autonomously plan and execute multi-step coding tasks. Its typical capabilities include generating functions based on natural language descriptions, fixing test failures, and refactoring local code. Unlike single-turn code completion, agents can invoke tools such as file reading/writing, terminal commands, and test execution, forming an "observe—act—feedback" loop. Such systems are highly efficient in scenarios with clear task boundaries and automatic verification through tests, but when facing problems with ambiguous requirements, cross-module coupling, or implicit business constraints, they tend to produce changes that seem reasonable but do not align with project intent. Understanding this capability boundary is a prerequisite for judging when work should be handed to agents and when human intervention is needed.

Maintainer Perspectives Enter the Classroom

Bringing open-source maintainers into the course also brings another layer of value: students need to face real review standards. Maintainers have their own requirements for code quality, commit conventions, and communication styles, which are closer to real engineering environments than classroom grading.

Mihail Eric mentioned that this arrangement allows students to learn to collaborate with maintainers during the course, rather than catching up on this lesson after starting work.

Implications for AI Engineering Education

The Signal Behind Course Reform

The adjustment of CS146S reflects a broader trend: when AI tools lower the barrier to coding, the focus of engineering education is shifting from "writing code" to "making engineering decisions." Students need the ability to read unfamiliar code, assess the impact of changes, and communicate with stakeholders.

This judgment is consistent with industry discussions about the role of AI engineers—agents handle repetitive implementation work, while human engineers are responsible for defining problems, validating results, and controlling quality.

Reusable Teaching Design

From the practice of CS146S, several teaching design principles can be extracted for reference:

• Real projects first: Use open-source projects instead of fictional assignments, allowing students to face real constraints and uncertainty.
• Preserve friction: Do not oversimplify processes; let students learn through communication, review, and iteration.
• External perspectives: Introduce external roles such as maintainers to provide feedback close to production environments.

These principles are not only applicable to university courses but also have reference value for internal AI engineering training in enterprises.

Conclusion

Mihail Eric's attempt at Stanford CS146S is essentially answering a question: when agents can complete old assignments, what should the course train? His answer is—train students to make judgments and changes in real systems. This answer may not be the only one, but it provides a concrete, actionable sample for AI-native engineering education.

One-line Summary

Stanford CS146S invites open-source maintainers into the classroom to train students to make engineering judgments in unfamiliar codebases.

Paragraph Summary

Mihail Eric, instructor of Stanford University's CS146S course, discovered that students can use a single prompt to get coding agents to complete traditional assignments, so the second iteration of the course was completely redesigned: inviting open-source maintainers to provide real problems, requiring students to learn code in an unfamiliar repository, propose changes, and drive implementation. The course deliberately preserves the friction of communication, review, and iteration, shifting training focus from "writing code" to "understanding system intent, assessing change risks, and collaborating with maintainers." The article points out that behind this is a shift in the focus of AI-native engineering education—agents handle repetitive implementation, while humans are responsible for defining problems and controlling quality, and distills three reusable principles: real projects first, preserve friction, and introduce external perspectives.