There is this emergence of kind of like a new, I would say, class of like engineer, which is like the AI-native engineer. And AI is that language.

AI is that new language. This particular generation of junior developers, of junior engineers, of people that are now entering the workforce will, I think, be the first kind of generation of that new shift.

A single developer becomes a manager of agents. Adding more agents doesn't always create for a better system.

In fact, it can make for a lot worse systems actually 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.

Like if you can do that really, really well, then you are literally like the top 0.1% of users even today.

I'm Mihal. 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 the first class where the focus is AI across the SDLC.

Within a few hours of the class being announced and it kind of opened up for enrollment, it filled up over 100 students trying to get into the class.

>> What is happening to junior software engineers?

there was this huge momentum around something kind of crazy is happening in software development, and AI is really starting to make its way into every single part of how software is being done.

And clearly something was changing, and I've heard some pretty scary anecdotes where I was talking to someone that had just graduated at Berkeley, and they were saying that they had applied to like a thousand places and had heard back from only back from like two places.

So not even like got interviews and, you know, had gone through the pipeline, but really were just heard back. So the reality is for a lot of junior engineers, it's very difficult for them to, you know, get some of these roles.

It's it's an interesting time in in the ecosystem, actually, the software ecosystem where where basically three things happened, came together in this kind of like perfect storm.

The first thing that happened was in around 2021, there was this huge surge of like hiring soon after COVID.

There was just a bunch of companies that felt they needed to increase their employee count, and then I think a lot of companies realized that they like overhired.

So there was like massive layoffs that happened where all these companies that had hired a ton of people realized that actually we can like reduce our workforce by 20%, 30%, and it's still okay.

That was combined with the fact that the growth of the CS curriculum, like the CS major nationally and internationally, has grown tremendously in the last like 10 to 15 years.

So when I was graduating, you know, there's like some number of graduates and I think since then, like 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 like been laid off. You have this new overwhelming like new generation of engineers who want jobs.

And then the third thing that I think was contributed to all this was AI became popular, right?

Like people started like 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 maybe for employment?

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

How top 1% AI native engineers orchestrate agents. At its core, I think that the AI native engineer is one that both has like a strong backing and a foundation in traditional programming, system design, and algorithmic thinking, but is very competent at using agentic workflows.

I always teach them like, 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.

Like, that that's like the wrong outcome that you should emphasize.

Again, I would build it one at a time. I would say, hey, like, I'm really good at doing one agent workflow quite well, and I can build like a complex piece of software with one agent, but then I know that I have to do this like other thing which is like maybe a small change.

Thinking about your tasks as something that are isolated and that can be done with confidence by something that is 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 like an isolated change that has nothing to do with what the second agent was doing.

And 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 those items of work, and then like 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, you know?

So, I would build it up more step by step rather than 10 agents at once. The second thing that I think is really, really important there is knowing how to like context switch.

In practice, what you're doing is you're like kicking off these like interns.

Basically, they're like very eager, savvy interns, these agents, and they're doing a thing and then you're just watching them in the terminal or like in the IDE, and you're just like seeing them do work and they're like contributing code and it's just getting written somewhere.

But sometimes they get stuck, right? How do you go from like one to another to like 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 like constantly switching back and forth.

And it's a very difficult thing to do even as a human, right?

To know how to like 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.

What I've described is basically what makes a good manager, like a good human manager.

It has nothing to do with like an agent. If you can do that task really, really well, then you also are just like a very good, you'd be like a good human manager in general.

And so the people that I see best at doing that are the ones that are also have been managers of like humans, you know, or human developers and have learned how to do that context switching and then apply similar principles to agents.

There's this concept that I'm calling like an agent-friendly codebase or an agent-friendly development ecosystem.

Uh, and 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 like 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 only can operate on contracts, like explicitly defined contracts of software. Any developer who's been in the industry knows that readmes get out of date with what's happening in the code almost immediately.

And so you have these like two descriptions of the same thing.

The code says one thing, but the readme says a completely different thing. If your code has that kind of a situation, then the agent will read the readme and maybe the code, and they'll ask them like, 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? This is like 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 kind of like 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 it's completely airtight in terms of design, in terms of testing, in terms of like the build, like a lot of these kind of core parts of the codebase itself before you even think about the agent.

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 kind of 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 like agent-friendly, agent-first codebases, are you consistent about like 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, 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 it 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 into your codebase and saw the two different ways of doing it, I would also ask myself, should I do one or two?

And I would probably end up asking a teammate, hey, which of these are we actually supposed to use?

Consistent design patterns and and kind of programmatic patterns I think is also something that the best agent-friendly codebases I've seen use.

>> functional software versus incredible software. >> A few things that define functional software from like incredible software. The one version of the answer is just taste, like what is good software taste, right?

And genuinely there's 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 sort of the the students in my class, we had some requirements like you have to build like five different flows or something like that.

You can create those flows, but if you want to push yourself, like do the bonus, you know, the bonus and then the extra credit, that is like, I think where the difference starts to arise is when someone is like, I know that I've already like hit 100% on this or, you know, got most of the credit for the assignment or the project, but I really want to like, I'm invested in like building the most complex thing because I want to solve a problem more than just get the grade, right?

But the taste building happens in that like that last mile, like where you go spend and you like do the extra work to like 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 like are now literally building startups around their projects because they like see that there's something there and they're going to like, they're rolling with it.

You know, like the class ended, but they're like, we're still, but 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 way the top engineers think. Experimentation is sort of the name of the game in becoming an AI-native software developer.

One example that comes to mind is when Boris came from Anthropic, came to speak. Someone like Boris, even a team like, you know, Claude at Anthropic that is building such an amazing piece of software, they basically rewrite Claude every week or like a week or two weeks using Claude, right?

So they are like 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.

Like 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. You know, 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 was, look, I can come here and I can 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 like 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 kind of make that a part of the kind of the new way of doing software development, experimentation, hacking, and just making that a part of your workflow.

>> Why the world still needs junior software engineers? >> 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 'cause 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.

I use Vim." The senior developers sometimes being the most stubborn, but someone who is coming to the industry for the first time, they're like they're like a sponge.

Like they're learning things for the first time. And so all of the things that are difficult about the world and society and and industries and verticals, they don't yet, they haven't internalized that yet.

They're not like scarred by like how hard healthcare is.

They just see like, oh, I see a problem. I don't know like why don't I go try and do it?

And so there's like a good naivete to how young 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 that have adopted that skill set that everyone is now asking for.

Even if there is concern that, you know, it's becoming harder to to kind of get employed, I think the people that are learning these skills for the first time end up being the most nimble and end up being the most like fast at like kind of using those skills.

So, I actually think they can still succeed in ways that senior developers cannot.

Fundamentally, like what you're teaching with software is like how to think about building of a of a complex system using digital means and like learning how to use algorithms to solve that system.

This is almost like more like math than it is like CS, right?

It's it's like you're learning like math skills almost. And I think that is just like teaching someone how to like think because so much of the CS profession is is breaking things up and seeing how things work and then fixing things and then expanding on things and kind of iterating on things.

And so I think that the people that are, you know, developers by trade, they're a a lot more willing to customize things.

They're a lot more willing to kind of fix things when they don't work. They're a lot more willing to say like, "Hey, why did this happen?

Let me see if I can kind of get into that, you know, get into 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.

Like the arrogance of a developer sees any problem and thinks software is the solution to the problem.

It's like the confidence to say like, "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, that I think, is the kind of the most powerful properties of CS developers.

>> 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 like, "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. Hi, my name is Rem Koning.

스탠포드에서 빅테크로 조용히 퍼지는 개발자 생존법, 대부분 모릅니다 | 미하일 에릭

'기업가정신'과 '기회'를 이야기합니다 


스탠포드에서 빅테크로 조용히 퍼지는 개발자 생존법, 대부분 모릅니다 | 미하일 에릭

Scripts