What Engineers Must Learn After Code Generation: Mihail Eric on Stanford, Monaco and Engineering Judgment

1. Guest Background

Mihail Eric approaches AI engineering from two connected positions: he is an adjunct professor at Stanford and head of AI at Monaco. At Stanford, he teaches CS146, The Modern Software Developer, with material covering coding agents, context engineering, design and architecture. His company work brings him into contact with large codebases and practical agent systems. That combination matters because the interview repeatedly tests educational ambitions against the constraints of software that other people must understand, maintain and use.

This approximately two-hour episode of Latent Space is hosted by Alessio Fanelli and Shawn swyx Wang. Its organizing subject is Eric's revised course, but the conversation extends into Monaco's engineering decisions and the possible evolution of software teams. The hosts contribute examples, objections and speculative directions; their claims should not automatically be attributed to Eric.

Eric says the course first ran in fall 2025 and that this is its second offering. At recording, the new version had only completed its first week. Consequently, the syllabus is evidence of what he intends to teach, rather than proof that every proposed exercise has already worked. His relevant authority here is that of a teacher and practitioner explaining decisions in progress, not someone presenting a settled curriculum or a controlled study of agent productivity.

2. What the Episode Covers

The course redesign begins with a mismatch between instructional exercises and increasingly capable tools. Eric describes the earlier version as a survey of agents across the software development lifecycle, including specification, review and reliability work. The revision gives more weight to context engineering, architecture, design and production repositories. Traditional computer-science foundations remain prerequisites. Eric's argument is that students must apply those foundations at a higher level, not that implementation automation makes them unnecessary. His comparison between Google L3 and near-senior capability expresses his view of rising expectations; it is not evidence of a universal hiring threshold.

Assignments change accordingly. Eric says some earlier exercises were easy enough for an agent to complete in one attempt. A submitted answer therefore revealed less about the student's engineering judgment. The new emphasis on real open-source contributions introduces existing architecture, maintainers and review. Students must encounter someone else's definition of a good change and revise their mental model in response. That is a different learning objective from demonstrating that a tool can produce code.

The technical entry point is deliberately small. Eric shows a coding-agent loop in about 200 lines, capable of interacting and editing files, while explicitly excluding features such as MCP and subagents. He then examines actual Claude Code requests through a proxy, exposing system, planning and compaction prompts. The contrast separates an understandable core mechanism from the additional responsibilities of a real product. The broader course connects these internals to context, skills and customization, then to repository readiness, review, security, background execution, team infrastructure and software factories.

Monaco supplies a parallel account of applying agents to a particular business. Eric describes an AI-native sales platform initially focused on early-stage startups. Its sales harness supports customer targeting, pipeline work, meeting preparation and summaries. He says the company combines Parallel, Exa and internal enrichment to maintain company and contact information. A salesperson changing jobs becomes an example of a possible outreach signal. GTM staff also help customers implement workflows and turn their domain knowledge into platform behavior. Eric claims benefits for finding buyers and booking meetings, but supplies no quantified improvement.

The internal engineering story is similarly specific. Monacoder, built on Coder.com, provides isolated environments for long-running agent work. Hal, a Slack bot, helps debug problems, propose repair PRs and answer salespeople's product questions. Yet Monaco continues to purchase Devin for code review. Eric's buy-to-learn, build-to-keep principle depends on product maturity and infrastructure fit. He describes Devin's later spread through engineers asking for access, which supports a claim about acceptance inside the team, not a measured claim about productivity.

3. Core Views: Reasoning, Examples, and Limits

The interview's strongest argument is that greater generation capability relocates engineering judgment. Eric observes that some Git and task-management guidance disappeared from system prompts and interprets this as capability moving into the model. He also favors a small set of general tools. But prompt removal alone cannot establish what a model has learned. The defensible lesson is to reassess the division of labor between model and harness. Instructions that helped a weaker model may become redundant or constraining as capabilities change; accumulating instructions indefinitely is not itself a reliability strategy.

For unfamiliar repositories, Eric makes that judgment explicit before implementation. His RAPID approach begins with research, develops alternative solutions, invites a human choice, and then proceeds through planning, implementation and testing. This exposes architectural disagreement while changing direction is still possible. Eric claims the approach can extend to codebases containing millions of lines. The episode offers no comparative results, however, so its value here is a reasoned workflow proposal rather than an established success rate.

Multiagent work complicates the proposal because context has to be distributed, not merely collected. Too little background can leave a worker unable to recognize a constraint. Too much history can elevate an incidental remark into an apparent rule. A host favors giving the overall reviewer complete information; Eric emphasizes consolidation, compression and refreshing bloated context. These positions reveal different needs for execution and oversight, but do not produce an optimal inheritance policy. Context management remains a task-dependent design decision.

Skills illustrate how automation can support comprehension. Eric's explain diff example combines a visual account of a change with a quiz about it. His organizational example encodes API conventions and service boundaries for review. swyx adds the maintenance problem: generated skills need repeated use, pruning and narrower triggers, or a procedure written for one project may activate elsewhere. The meaningful unit of progress is a procedure that behaves appropriately and helps someone understand the work. Neither a growing skill directory nor a large generated diff demonstrates that understanding.

The same distinction applies to throughput. Eric treats repository structure, comprehensibility and verifiability as foundations for parallel agents. He then points to blocked merge queues and slow application startup as problems that adding agents may not solve. His hypothetical 30-plus PRs per day makes the review constraint concrete: production of changes can outstrip the ability to judge them. He proposes exploring automatic approval for some changes under suitable architectural and verification conditions. Which changes qualify, and what human review should inspect, remain open questions.

Even a clear review can miss historical intent. Monaco's detailed PR descriptions explain implementation, file locations and service boundaries. The host objects that an internally consistent PR can still reverse a decision made weeks earlier. Eric cites Basis's versioned specifications and canonical state as a possible response. The distinction is consequential: explaining the current change and preserving the accumulated constraints of a system are separate maintenance obligations. The episode identifies the gap without establishing a common solution.

Security limits another tempting inference. Eric emphasizes dependency tracking and pinning, while the host challenges the idea that replacing external dependencies with internal code must be safer. Internal implementations introduce their own mistakes, and a broader open-source user population may help expose defects. Models may also introduce unfamiliar vulnerabilities. Cheap code therefore does not, by itself, establish a safer system. The discussion supports explicit scrutiny of risks rather than certainty about either self-building or automated repair.

Infrastructure consolidation has a comparable boundary. MCP portals and model gateways may share governance, security, auditing and cost-control responsibilities. Yet separate teams can own the relevant systems, making integration an organizational negotiation. The host also uses OpenRouter's focused model-routing approach to qualify his preference for a comprehensive middle layer. Architectural adjacency does not settle product scope, ownership or purchasing decisions, and the discussion explicitly leaves portal businesses unproven.

Software factories still retain human responsibilities in Eric's account: specifying intent, reviewing systems and reconciling product needs with technical constraints. The episode's 80–90% agent-driven-code scenario is hypothetical; the thirty-something-percent figure is a host-relayed vendor claim, not a common measurement. Dynamic workflows extend the exploration by generating task-specific code or harnesses for subagents. Eric says Monaco has a related GTM pattern, but provides neither implementation detail nor comparative evaluation. It is an interesting design direction, not evidence that it generally outperforms copying a parent agent.

4. Learning and Application

For a learner, the practical starting point is to test explanation separately from generation. Reproduce a minimal tool-calling loop, observe how actions lead to file changes, and then examine how a real product organizes planning and context compression. Follow that with a contribution to an existing repository and feedback from a maintainer. An explain diff-style exercise can test whether the student can account for the resulting behavior. These are applications of Eric's teaching approach; the compact demonstration does not imply that a production harness can omit its additional controls and extensions.

For an unfamiliar codebase, turn RAPID into a working agreement: research findings and alternatives arrive before implementation, and the human decision is explicit. In multiagent work, specify the background each task needs, the constraints that remain active and the information that must return. Full-history inheritance calls for checking obsolete comments; summaries call for checking lost restrictions. Those checks respond to the tradeoff described in the episode rather than presuming that either context policy is universally best.

Before expanding concurrency, inspect whether the repository is understandable and whether testing, building, startup, review and merging can absorb more changes. If work accumulates, identify the constrained stage before adding agents. The discussion of build logs, production analytics and event triggers suggests a way to connect detection with investigation and repair. Eric's multi-service classroom incident sandbox also offers a useful learning format: practice diagnosing a system through evidence. His view that complex dependencies increase AI SRE's value is a condition to examine, not a reason every small system needs a specialized platform.

Maintain current-change explanations and persistent intent together. A PR description can explain implementation and service boundaries, while a longer-lived specification records constraints spanning several changes. Skills can carry recurring API and boundary conventions, provided they are exercised, pruned and tested for inappropriate activation. Whatever the representation, someone must maintain it. Producing documentation once does not establish that future code and intent will stay aligned.

Make sensitive work explicit. Before delegating storage, billing, authentication or authorization changes, understand AuthN, AuthZ and IAM well enough to state requirements and evaluate the result. Combine dependency tracking, pinning, scanning and security review; none is presented as a guarantee. Procurement can likewise vary by function. Monaco's combination of internal background systems and purchased review suggests evaluating fit, maturity and actual use separately. Engineers requesting a tool is valuable feedback, but should not be relabeled as quantified productivity evidence.

Finally, give orchestration and dynamic-harness experiments a deliverable. The host's account of spending salary and tokens without receiving a product describes a failure mode worth checking. Student work could instead produce a substantive open-source contribution, a benchmark or evaluation addressing a defined question, or an engineering article whose method and limitations others can inspect. The hosts predict hiring and commercial benefits, but provide no measured outcomes. Likewise, support for a thousand-plus-agent experiment is a resource proposal, not a completed result. Assess what was delivered, how it was verified, where it applies and whether the cost was justified.

Source

• Original episode: One Million AI Engineer Special How Stanford Teaches AI-Native Engineering — Mihail Eric, Monaco