From Writing Code to Managing Agents: Stanford's First AI Dev Course Instructor Says Most Engineers Aren't Ready从写代码到管 Agent：斯坦福首门 AI 软件开发课的讲师说，大多数工程师还没准备好

Mihail Eric taught a course at Stanford, CS146S "The Modern Software Developer," first offered in fall 2025, the first university course in the country to weave AI throughout the entire software development process. Within hours of enrollment opening, over 100 students scrambled to sign up.

Mihail is also the Head of AI at an early-stage startup in San Francisco. Previously, he led a technical team at Amazon Alexa and founded a YC-backed AI coding company. He came out of the Stanford NLP group, advised by Christopher Manning.

In an interview for EO channel's "The Thinking Mode" series, he spent 14 minutes discussing several questions: what junior developers are up against right now, how top engineers manage agents, what kind of codebase is agent-friendly, and why a junior engineer's "fearless ignorance" is actually an advantage in the age of AI.

Original video link: https://www.youtube.com/watch?v=wEsjK3Smovw

Key takeaways

Junior developers are facing a "perfect storm": post-COVID corporate layoffs of 20-30%, the number of CS graduates more than doubling within a decade, and AI making employers consider a "hire fewer people + AI" strategy — the combination makes it extremely hard for newcomers to find jobs

Managing multiple agents is "the final boss of the game" — don't think you should run 10 agents just because someone else does; start with one and scale up gradually

Agents can only operate based on explicit "contracts" (tests) — a codebase needs to be prepared with solid test coverage, documentation consistency, and consistent design patterns

Taste is cultivated in the "last mile" — even the Claude Code team itself rewrites its code every week

Senior developers tend to resist AI tools the most, while junior engineers, unburdened by historical baggage, learn the fastest

The junior developer's "triple perfect storm"

Mihail starts with a story. He knows someone who just graduated from Berkeley and sent out around 1,000 resumes, receiving only 2 replies — not interview invitations, just replies.

This isn't an isolated case. He believes the plight of junior engineers is the result of three things happening at once.

First, mass layoffs following over-hiring. Around 2021, after COVID, many companies felt they needed to expand and hired like crazy. Then they realized they'd overhired, and large-scale layoffs began. Many companies found that cutting 20%, 30% of their staff, the business kept running just fine.

Second, a surge in the number of CS graduates. Mihail says that when he graduated it was one number, and now it's roughly two to three times that.

Third, AI changed employers' calculus. Employers started running the numbers: do I keep hiring more people to fill the gap, or hire fewer but AI-native people to accomplish the same work with fewer heads?

The result of these three factors combined: a large wave of laid-off senior engineers and a large wave of newly graduated young people flooding the market at the same time, while employers' willingness to hire is actually contracting because of AI.

Mihail believes that this current generation of junior developers entering the workforce will be the first generation of the "AI-native transition." They must possess both solid traditional fundamentals and complete AI-native capabilities simultaneously — neither can be missing.

Don't think you should run 10 agents just because someone else does

In Mihail's view, the core definition of an AI-native engineer is: a solid foundation in traditional programming, systems design, and algorithmic thinking, combined with real proficiency in agentic workflows.

But he specifically flagged a common misconception. Boris Cherny, the creator of Claude Code, gave a guest lecture in his class, and Boris's practice of running 10 or even more agents simultaneously has become widely known in the developer community. Mihail says his students' first reaction after hearing this was "I should also start with 10." He believes that's exactly the wrong conclusion to draw.

Note: Boris Cherny is a Staff Engineer at Anthropic and the founding engineer of the Claude Code project. He has publicly shared his workflow: 5 Claude Code sessions open in the terminal, another 5-10 open in the browser, managing over a dozen parallel tasks at once.

His advice is to "build it up piecemeal."

First use a single agent to do one complex thing well, and confirm you've fully mastered that workflow. Then look for a second, isolated small task — say, fixing a logo. Add another agent to revise the website copy.

The key is that each task must be mutually isolated, with no dependencies between them.

Once the first one runs smoothly, add a second. Once the second is stable too, add a third. Not all 10 at once.

Truly learning to manage multiple agents is like the final boss of a game. Anyone who can do this is, even today, among the top 0.1% of users. ("Knowing how to properly handle multiple agents is like the last boss in a game. If you can do that really, really well then you are literally the top top 0.1% of users.")

Context switching: the real difficulty of managing agents

Speaking about the core skill of multi-agent workflows, Mihail points to a very everyday ability: context switching.

He offers an analogy: these agents are like a group of eager, smart interns — you hand out a task and they get to work in the terminal, code pouring out. But sometimes they get stuck.

At that point you need to switch from Agent 1 to Agent 2, then to Agent 3. Each time you switch, you have to remember where the previous agent left off, while also holding enough context to move the current task forward. Even for humans, this is hard.

Then Mihail says: what he just described is exactly what a good human manager does every day. It has nothing to do with agents — get good at this, and you'd also be an excellent team manager.

He's observed that the people who are best at orchestrating agents often have experience managing human development teams. In the process of managing people, they learned how to switch between multiple tasks, how to allocate attention, and how to make judgment calls with incomplete information — and then applied the same principles to agents.

What is an "agent-friendly codebase"

Mihail proposes a concept: the agent-friendly codebase.

The core question is: if you drop an agent into your codebase, can it understand what's going on?

He breaks this down point by point.

Tests are "contracts"

When you have an agent develop a new feature in your codebase, how does it confirm it hasn't broken anything? Through tests.

Tests are the contract that defines software correctness. If your test coverage is insufficient, it's as if you've given the agent no rules to follow.

Agents can only operate based on explicitly defined contracts. If you don't have sufficient test coverage, you haven't defined a contract for your software. ("Agents only can operate on contracts, like explicitly defined contracts of software.")

README and code need to be consistent

Anyone who's done development knows that a README goes stale almost as soon as it's written, drifting out of sync with the code. The code says one thing, the README says another. When an agent reads two contradictory descriptions at once, it gets confused: which one should it follow?

Agents rapidly compound errors

If an agent produces a misunderstanding in its first step, seeing the flawed code it created in that first step, it won't correct itself — instead it doubles down on the mistake, snowballing it, gradually turning the code into a bowl of "spaghetti code."

So the most important thing is: the first version of code an agent sees must be self-consistent, well-designed, and thoroughly tested.

Before you start letting an agent write code, get the codebase itself right first.

Design patterns need to be consistent

If one part of your codebase uses API 1 to create a certain kind of object, and another part uses API 2 to create the same kind of object, the agent doesn't know which one to pick.

But Mihail added:

If I walked into your codebase and saw two different ways of doing the same thing, I'd also ask myself: which one should I use? I don't know, both are in use, and I'd probably go ask a colleague. ("If I were walking to your codebase and saw the two different ways of doing it, I would also ask myself: should I do one or two?")

An agent-friendly codebase is, in fact, a codebase that's also friendly to humans.

Good engineering practices haven't changed — they've just become hard requirements in the age of agents, rather than "nice to have" suggestions.

Taste: the dividing line between functional software and outstanding software

What separates "software that works" from "software that's remarkable"? Mihail's answer is direct: taste.

In his class, every project has baseline requirements — say, implementing five different functional flows. Most people stop once they've met the requirements. But some students are different: they've already gotten full marks, yet they keep polishing, extending features, making the app more robust.

"The taste building happens in that last mile."

The difference lies in who genuinely wants to solve the problem itself, rather than just get the grade.

Mihail says that some of the best-performing students in his class are now starting companies built around their course projects. The course ended, but they're still working on the same thing, because they feel there's still more worth doing.

Top engineers don't stop when a task is complete — they accelerate when they spot possibility.

Even Anthropic is learning as it goes

On the subject of experimentation, Mihail gave an example. When Boris Cherny lectured in class, he mentioned that Anthropic's Claude Code team basically rewrites Claude Code itself using Claude every week or two. They use the tool they built to rewrite the tool itself.

Even a team like Anthropic, building the most cutting-edge AI coding tools, doesn't have "all the answers." They too are constantly experimenting, iterating based on user feedback, figuring out what works and what doesn't.

Mihail repeatedly emphasizes in class: I can come here and recommend tools to you, share what I think works well. But at the end of the day, you have to go hit the wall yourself.

You have to experiment yourself and see what works for you and what doesn't. Making experimentation and trial-and-error part of your workflow — that's the new way of doing software development.

A junior engineer's "fearless ignorance" is a superpower

Mihail points out that senior developers are often the ones most resistant to AI tools. People who've been writing code for 20 years are too used to their own ways, feeling like "there's only my way of doing this, the way I've always done it."

People entering the industry for the first time are completely different. They're like sponges — everything is new to them, everything feels possible. They haven't yet been "scared off" by the industry's various difficulties. They don't know how hard healthcare is, don't know how strict financial regulation is. They just see a problem and say: why not give it a try?

Young people have a kind of "good naivety," which is the perfect quality for a startup founder. ("There's like a good naivety to how young people think, which is perfect for a startup founder.")

Mihail believes that even though the job market really is getting tougher, the people who are the earliest to master AI-native skills — these very junior engineers — will ultimately turn out to be the most adaptable, fastest-learning group.

"Developer arrogance" and the trap of overengineering

Mihail also discussed the essence of CS education. He believes software development teaches how to build complex systems through digital means, how to solve systemic problems using algorithms — closer to mathematical thinking than narrow programming skill.

Developers have a distinctive mindset he calls "developer arrogance": faced with any problem, the first instinct is that software can solve it. This arrogance sounds like a pejorative, but it's actually an extremely powerful driving force.

But this arrogance carries new risks in the age of AI. You have Claude build one thing, then have Codex build another, and keep piling on features. A month goes by, and you've produced an exquisitely crafted, wildly overengineered product — and when you launch it, you find nobody wants it.

You've built the most beautiful piece of software, it's crazy overengineered, and then you launch and nobody wants it.

AI has made building too easy. So easy that you might forget to first verify whether anyone actually needs what you're building.

Rem Koning: the key to an AI-native organization

At the end of the video, Rem Koning, associate professor at Harvard Business School, makes a brief appearance previewing the next episode.

Note: Rem Koning's full name is Rembrand Koning, an Associate Professor at Harvard Business School whose research focuses on entrepreneurship and AI. He is co-founder of the Tech for All Lab at Harvard's D^3 Institute.

He raises several ideas worth thinking about.

First, the ability to "allocate intelligence" will become increasingly important. It's not about how smart you are yourself, but whether you can properly deploy intelligence to the right places.

Second, the key to an AI-native organization isn't using AI to do your work, but embedding AI directly into the product itself, letting AI collaborate directly with customers. The ultimate goal is to remove humans from the loop.

Third, when AI starts talking to AI, when AIs start collaborating with each other, what do they need? Koning believes that companies who figure this out could become trillion-dollar enterprises.

The core message Mihail Eric conveys in these 14 minutes can be distilled into three points:

AI-native engineers need to layer agent orchestration skills on top of traditional engineering fundamentals;

Codebases themselves need to be prepared for the arrival of agents — testing, consistency, and documentation are all indispensable;

And during this transition period, junior engineers' "fearless ignorance" and flexibility may actually be the most underrated assets.

The question is: in the transition from "writing code" to "managing agents," who gets left behind, and who gets phased out?

As agent capabilities continue to improve, could the skill of "managing agents" itself eventually be automated too?

Mihail doesn't offer an answer, but his course and his practice are themselves a kind of exploration of this question. By his own logic, the answer is likely to keep changing.

Full interview video: https://www.youtube.com/watch?v=wEsjK3Smovw