Latent Space interviews Stanford CS146S instructor Mihail Eric: What should engineers learn in the AI era?

If last year's programming assignment can now be completed by an Agent with a single sentence, how should the course be changed?

Latent Space recently invited Professor Mihail Eric @mihail_eric to discuss this question. He teaches CS146S "The Modern Software Developer" at Stanford and also serves as the head of AI at Monaco. Teaching students on one hand while deploying Agents in a real team on the other means this interview does not remain at the level of educational philosophy alone.

The most noteworthy shift in the entire discussion is this: code generation is becoming easier and easier, but understanding problems, organizing work, verifying results, and taking responsibility have not become easier along with it. The training of the next generation of engineers must be redesigned around these latter capabilities.

When "handing in code that runs" is no longer enough to prove that you have learned

CS146S is not a course that teaches programming from scratch. Students need to already have foundations in algorithms and systems, and then learn how to use AI to participate in real software development.

The first iteration of the course was more like a tour of the AI development ecosystem, exposing students to different stages such as code review, specification design, and operations. But Mihail found that many teaching exercises could already be completed by an Agent in one go.

In the classroom survey he described, almost all of the students surveyed were already using coding Agents. Continuing to use "independently writing a piece of code" as the main assessment point makes it increasingly difficult to distinguish whether students actually understand the problem or have simply obtained a runnable result.

Therefore, the new round of the course incorporates real open-source contributions and maintainer review into the assignments.

An Agent can help students quickly write a patch, but it cannot answer all the questions on the students' behalf: does the maintainer need this change? Why does the existing code adopt this design? Which other features will the patch affect? And when facing review comments, how should it be revised?

The assessment point shifts from "can you generate code" to "can you propose a reasonable change and take responsibility for it."

Feedback from real maintainers also means that teaching is no longer limited to standard answers, but includes the negotiation, constraints, and trade-offs of real engineering.

First understand Agents, then learn how to organize Agents' work

This course does not simply teach a set of tools, but gradually moves from the internal mechanisms of Agents toward team-level engineering practice.

The starting point is to build a minimal coding Agent by hand and understand how the model calls tools, reads results, and continues to act. Then students observe how production-grade tools handle system prompts, planning, and context compression.

This order matters: only by understanding the basic loop is it easy to judge whether a failure comes from the model, the context, the tools, or the task definition, rather than switching models and adding prompts whenever a problem arises.

The subsequent content unfolds around several more enduring questions:

How can sufficient context be provided without stuffing all irrelevant information into the model?

How can repetitive work be consolidated into skills, and clear tool interfaces be designed?

How can repository instructions, execution hooks, and sub-Agents be used to customize workflows?

How can the codebase be given clear boundaries, readable documentation, and verifiable results, so that it is truly suitable for Agents to work in?

Only after that come code review, security, background tasks, continuous integration, and the infrastructure shared by the team.

The teaching logic behind this is: first learn to judge why an Agent is effective, and then consider how to scale up its work.

Specific tools will change, and model capabilities will also change. Capabilities that must be supplemented with extra prompts today may already be built into the model tomorrow; complex rules that were once useful may also become a burden. Therefore, the course needs to train the ability to experiment and update judgments, rather than having students memorize a fixed checklist of operations.

Lessons from a real team: buy first to learn, then decide what is worth building in-house

In Monaco's practice, Mihail summarized the tool strategy in one sentence: first understand the problem through procurement, then build in-house the capabilities that need to be mastered for the long term.

Code review is an example of procurement. After trying the product, the team believed that Devin was genuinely helpful, so they continued to use it, rather than rebuilding everything just to own the full technology stack.

The Agent workspace, by contrast, moved toward in-house development. Background Agents need to run the product, reproduce failures, and test patches, and these capabilities are closely tied to the company's cloud architecture and development environment. Monaco therefore built Monacoder based on Coder.

A companion engineering article mentioned that in the early days they relied on multiple local sessions and Git worktrees to scale up parallelism, which brought port conflicts, disk usage, and notification chaos. The problem cannot be solved by "opening a few more Agents," but requires isolated, reproducible working environments.

They also built a Slack bot called Hal: engineers can use it for troubleshooting and proposing code changes, while salespeople can use it to understand the product.

The same system serves different roles, but the form of delivery differs. Engineers need inspectable modifications, while sales need clear product explanations; handing a pile of debugging logs to sales does not count as completing the task.

This shows that the product value of an Agent comes not only from model capabilities, but also from whether the environment, permissions, context, and form of delivery match the user.

Agents can see the code, but they do not necessarily know the "why"

The interview raises a very practical question: an Agent can read the current code, but where does it go to find out why the team rejected a similar change six months ago?

Code records the current implementation, but it does not necessarily record the options that were once discussed, customer commitments, risk judgments, and organizational decisions.

Without this context, an Agent is very likely to propose again a plan that was long ago rejected, or to break important constraints in the course of local optimization.

This is also why teams cannot pursue only larger context windows; they also need to ensure that important decisions are explicitly recorded, so that the Agent knows which information is authoritative and which constraints it must not change on its own.

For engineers, an increasingly important task is to turn implicit context into consultable evidence, and to turn "good enough" into verifiable acceptance criteria.

The new bottleneck is review and understanding

When the cost of code generation falls, teams do not necessarily speed up by the same proportion, because review, testing, release, and decision-making still take time.

The Faros research cited in the program's accompanying materials points out that teams with high AI adoption see an increase in PR merge volume, while review time also grows noticeably. What it warns against is not "using less AI," but rather: once the generation side speeds up, downstream steps may become the new bottleneck.

The course therefore also discusses how to explain code diffs, helping people truly understand the changes rather than just quickly clicking approve.

A useful way to test this is: have the Agent explain the change, then ask questions in reverse. Which questions can you still not answer, and which require you to reopen the code to understand? Those places are the parts you have not yet mastered.

"Having read the explanation" is not the same as "understanding the change," just as "the tests pass" is not the same as "this feature is worth building."

Intent, architecture, security boundaries, product trade-offs, and the final release decision still require people to take responsibility.

This coincides with Addy Osmani's view

Reading note: junior engineers need to practice judgment earlier, not skip the fundamentals

This interview does not prove that a fully unattended software factory has matured, nor does it suggest that basic programming knowledge can be omitted.

On the contrary, when Agents can complete more of the implementation for people, judging whether an implementation is correct and reasonable requires a more solid understanding.

The change is that in the past, engineers might gradually gain exposure to review, architecture, and business trade-offs through writing a large amount of code by hand; now the implementation process has been compressed, but these judgment abilities do not automatically come with it. Teaching and team development must consciously fill in this gap.

The direction offered by this Stanford course is to expose students earlier to real repositories, real maintainers, and real constraints; Monaco's practice shows that for an Agent to remain effective, the environment, verification, and organizational memory must be built at the same time.

The competitiveness of the next generation of engineers is not just "what they can get AI to write," but the ability to propose changes worth making, organize reliable execution, and prove that they understand the results and their consequences.