Mihail Eric: There is this emergence of a new class of engineer, the AI native engineer. AI is that new language. This particular generation of junior developers, junior engineers, people now entering the workforce, will I think be the first generation of that new shift.

Mihail Eric: A single developer can become a manager of agents. Adding more agents doesn't always create a better system. In fact, it can make for much worse systems if you just let them go and do whatever they want. So, really 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 0.1% of users, even today.

Mihail Eric: I'm Mihail. I lead AI at an early-stage startup here in San Francisco. I also teach a class at Stanford. The title of the class is 'The Modern Software Developer'. It's definitely the first class where the focus is AI across the SDLC. Within a few hours of the class being announced and opened for enrollment, it filled up with over 100 students trying to get into the class.

Interviewer: What is happening to junior software engineers?

Mihail Eric: There was this huge momentum around something crazy happening in software development, and AI is really starting to make its way into every single part of how software is being done. Clearly, something was changing. I've heard some pretty scary anecdotes. I was talking to someone who had just graduated from Berkeley, and they were saying they had applied to like a thousand places and had heard back from like only two places. So, not even got interviews, and you know, had gone through the pipeline, but really just heard back. So the reality is, for a lot of junior engineers, it's very difficult for them to get some of these roles. It's an interesting time in the ecosystem, actually the software ecosystem, where basically three things happened, came together in this kind of like perfect storm.

Mihail Eric: The first thing that happened was around 2021, there was a huge surge of hiring. Soon after, there was just a bunch of companies that felt they needed to increase their employee count. Then, I think a lot of companies realized that they had overhired. So, there were massive layoffs that happened, where all these companies that had hired a ton of people realized that actually, we can reduce our workforce by 20%, 30%, and it's still okay. That was combined with the fact that the growth of the CS curriculum, the CS major nationally and internationally, has grown tremendously in the last 10 to 15 years. So, when I was graduating, there was a certain number of graduates, and I think since then, it's doubled to maybe 3x in terms of how many graduates from CS are graduating every year. And so, you have a huge workforce of people that have essentially been laid off. You have this new, overwhelming, new generation of engineers who want jobs. And then the third thing that I think contributed to all this was AI became popular, right? People started really paying attention to AI. And so, for a lot of employers, they started considering: Do I need to hire more people to fill my gaps, or can I just hire fewer people that are maybe native at AI, and that way cover the quota that I have for employment?

Mihail Eric: And so, this particular generation of junior developers, junior engineers, the people that are now entering the workforce, will, I think, be the first generation of that new shift, where they have to both have good fundamentals but also know how to be fully AI native.

Mihail Eric: At its core, I think the AI native engineer is one that both has a strong backing and foundation in traditional programming, system design, and algorithmic thinking, but is very competent at using agentic workflows.

Mihail Eric: I always teach them to build it up piecemeal. You know, Boris from Claude said he does like 10 agents at once, and so I should start doing 10 agents at once. That's the wrong outcome to emphasize. Again, I would build it one at a time. I would say, 'Hey, I'm really good at doing one agent workflow quite well, and I can build a complex piece of software with one agent.' But then I know that I have to do this other thing, which is maybe a small change. Thinking about your tasks as something that are isolated and can be done with confidence by a second or third agent. And so you add, you know, a second agent to fix the logo, and you're like, 'Well, this agent is fixing the logo.' Another agent maybe could also update the copy on the header of the website. And again, this is an isolated change that has nothing to do with what the second agent was doing. So, the way I would think about it is iteratively add more work for the agents. Make sure that you first understand what has to be done, and then know where the lines are between those items of work. And then, when you're feeling good about how one agent is doing something, then add a second one. Then, if the second one's doing well and you're feeling confident, then add a third one. So, I would build it up more step by step rather than 10 agents at once.

Mihail Eric: The second thing that I think is really, really important there is knowing how to context switch. In practice, what you're doing is you're kicking off these interns. Basically, they're very eager, savvy interns, these agents, and they're doing a thing, and then you're just watching them in the terminal or in the IDE, and you're just seeing them do work, and they're contributing code, and it's getting written somewhere. But sometimes they get stuck, right? How do you go from one to another to understanding, 'Hey, this agent one was working on this particular task, agent two was working on another task, agent three was working on another task,' and then you're constantly switching back and forth? And it's a very difficult thing to do even as a human, right? To know how to remember what the last thing was working on, but still have enough context to meaningfully push that task forward. And so, that switching, I think, is probably one of the core skills of getting multi-agent workflows to work really well.

Mihail Eric: What I've described is basically what makes a good manager, a good human manager. It has nothing to do with an agent. If you can do that task really, really well, then you are also a very good human manager in general. And so, the people that I've seen best at doing that are the ones that have also been managers of humans, you know, or human developers, and have learned how to do that context switching, and then apply similar principles to agents.

Mihail Eric: There's this concept that I'm calling an 'agent-friendly codebase' or an 'agent-friendly development ecosystem'. What I mean here is, if an agent was released into your codebase, would it know how to understand what's happening in the codebase? When you release an agent to go and build in the context of your codebase, the way you ensure that they're going to not break something and that whatever they contribute will work, is they test it against your tests, which are basically contracts that define the correctness of software. You need to define these contracts. If you don't have enough test coverage, then you don't have contracts for your software. Agents can only operate on contracts, like explicitly defined contracts of software.

Mihail Eric: Any developer who's been in the industry knows that readmes get out of date with what's happening in the code almost immediately. You have these two descriptions of the same thing: the code says one thing, but the readme says something completely different. If your code has that kind of situation, then the agent will read the readme and maybe the code, and they'll ask, 'Which of these? What's the right interpretation? Should I follow what the readme says or what the codebase says?' And so, make sure they're consistent, right?

Mihail Eric: This is a simple thing. When you get spaghetti code, it's typically when an agent has maybe gone on and built something for multiple iterations, maybe multiple features, and it just started going off the rails a little bit. One bad thing that they're really good at is agents can compound errors very quickly. If an agent has one misunderstanding in a code, and then it sees that misunderstanding that it created in step one, it can double down and create another error in step two; it'll magnify it. The most important thing is making sure that the first thing that the agent sees is completely robust and airtight in terms of design, testing, and the build – like a lot of these core parts of the codebase itself – before you even think about the agent.

Mihail Eric: So again, making sure that the first version of your code that an agent sees is self-consistent, making sure that it's well tested, making sure that you have linting in place and style checking so that your codebase is consistently formatted. A lot of these things will ensure that your agent is always adhering to the rules of your codebase that you've already defined. And then the last thing that I'll add, just to give another example of agent-friendly, agent-first codebases: Are you consistent about design patterns in your code? What I mean here is, if there's one part of your codebase where when you create a certain kind of object, you use this one API, and there's another part of the codebase where you also create the same object, but you're using a different API. When an agent now has to develop in your codebase, which of the two should it use? Should you use API 1 or API 2? And if people have an agent that goes and picks the wrong API, well, a human would also have been confused. If I were walking through your codebase and saw the two different ways of doing it, I would also ask myself, 'Should I do one or two? I don't know. I see both.' And I would probably end up asking a teammate, 'Hey, which of these are we actually supposed to use?'

Mihail Eric: Consistent design patterns and programmatic patterns, I think, is also something that the best agent-friendly codebases I've seen use.

Interviewer: Functional software versus incredible software.

Mihail Eric: A few things define functional software versus incredible software. The one version of the answer is just taste – what is good software taste, right? Genuinely, there are people that have taste and don't have taste, or just people that have taste that spend more time developing that taste. When I look at the students in my class, we had some requirements like you have to build five different flows or something. You can create those flows, but if you want to push yourself, like doing the bonus, the bonus and then the extra credit – that is where the difference starts to arise. It's when someone is like, 'I know I've already hit 100% on this, or got most of the credit for the assignment or the project, but I really want to build the most complex thing because I want to solve a problem more than just get the grade.' But the taste-building happens in that last mile, where you go spend and do the extra work to expand the feature, make it more robust, make more things possible in the application. You know, the students again that I think did the best were the ones that are now literally building startups around their projects because they see that there's something there and they're rolling with it. You know, like the class ended, but they're like, 'We're still working on the exact same thing because we think there's more to build here.' And that, I think, is where the top engineers think. Experimentation is sort of the name of the game in becoming an AI native software developer.

Mihail Eric: One example that comes to mind is when Boris came from Claude to speak. Someone like Boris, even a team like Claude at Anthropic, that is building such an amazing piece of software, they basically rewrite Claude every week or every two weeks using Claude. So they are constantly rewriting their own piece of software with software like that they've built. And so they themselves are also figuring things out as they go; they are building their system, but they are experimenting and constantly iterating based on feedback from their users. And even if they seem like they have all the answers, they don't. They themselves are also discovering what works and what doesn't work. And so, the more important thing is to build experimentation into your own workflows. And I tried to reinforce in the students: Look, I can come here and give you suggestions. I can say you should try this tool, here's what I think is good about this tool. But at the end of the day, you have to sort of beat your head against the wall a little bit yourself. You have to be able to experiment. You have to be able to see what works for you and what doesn't work for you, and really just make that a part of the new way of doing software development: experimentation, hacking, and just making that a part of your workflow.

Interviewer: Why the world still needs junior software engineers?

Mihail Eric: Senior developers historically tend to be a little bit resistant to AI tools because they're so ingrained in their own way of doing things; they've been developing for 20 years and they're like, 'Oh, the only way to do this is the way that I've done it.' The senior developer is sometimes the most stubborn. But someone who is coming to the industry for the first time, they're like a sponge. Everything is possible to them. They're learning things for the first time. And so, all of the things that are difficult about the world, society, industries, and verticals, they haven't internalized yet. They're not scarred by how hard healthcare is. They just see a problem and think, 'Oh, I see a problem. Why don't I go try and do it?' And so, there's a good naivety to how young people think, which is perfect for a startup founder. They're going to be brave enough to go and tackle the thing. In those situations, they end up being the best people who have adopted that skill set that everyone is now asking for. Even if there is concern that it's becoming harder to get employed, I think the people that are learning these skills for the first time end up being the most nimble and fastest at using those skills. So, I actually think they can still succeed in ways that senior developers cannot.

Mihail Eric: Fundamentally, what you're teaching with software is how to think about building a complex system using digital means and learning how to use algorithms to solve that system. This is almost more like math than CS, right? It's like you're learning math skills. And I think that that is just like teaching someone how to think, because so much of the CS profession is breaking things up, seeing how things work, fixing things, expanding on things, and iterating on things. And so, I think that the people that are developers by trade, they're a lot more willing to customize things. They're a lot more willing to fix things when they don't work. They're a lot more willing to say, 'Hey, why did this happen? Let me see if I can get into that, get into the internals a little bit.' In ways that other people are more like, 'The system doesn't work. Okay, I guess I need to move away from it.' Almost like arrogance. The arrogance of a developer sees any problem and thinks software is the solution to the problem. It's the confidence to say, 'Hey, I'm going to try and fix this in a way that I know how to use, and I'm going to use the tools that I know how to use, and let's see if we can make this work.' And that, I think, is the most powerful property of CS developers.

Mihail Eric: So you're like, 'Claude, make me something. Codeex, make me something.' And then you're like, 'Let's add this other feature.' And then, 'Let's do another one.' And a month goes by, and you've built the most beautiful piece of software. It's crazy overengineered, and then you launch, and nobody wants it.

Rem Koning: Hi, my name is Rem Koning. I'm a professor at Harvard Business School, and I study entrepreneurship and AI. I think we're in a world where increasingly what matters is your ability to allocate intelligence. The key for AI native is that you're not just using it to do the work; you're embedding it in the product so that the AI can directly do the work with the customer. You want to take you, the human, out of the loop. That's the key to building AI native organizations. What happens when the AI starts talking to one another? What happens when the AIs start collaborating? What do they need from one another? I think is a big, interesting open question. It's a little provocative to think that way, but I think it's one where there will probably be some trillion-dollar companies that come out of answering that question.