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.

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

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


EO Korea

AI 네이티브 엔지니어는 기존 프로그래밍 기술과 더불어 AI 에이전트 워크플로우를 능숙하게 활용하여 복잡한 소프트웨어를 효율적으로 구축하는 능력을 갖춰야 합니다.

주니어 개발자는 AI 도구에 대한 개방적인 태도와 빠른 학습 능력을 통해 AI 시대의 기술 변화를 주도하며, 숙련된 개발자들이 어려워하는 부분을 해결하며 성장할 수 있습니다.

AI를 활용한 소프트웨어 개발에서는 에이전트 워크플로우를 점진적으로 구축하고, 에이전트 간의 효율적인 컨텍스트 전환을 관리하며, 일관된 테스트 및 코드 디자인 패턴을 통해 '에이전트 친화적인 코드베이스'를 유지하는 것이 중요합니다.

새로운 종류의 엔지니어가 등장하고 있는데, 이를 'AI 네이티브 엔지니어'라고 부르며, **AI가 새로운 언어로서 핵심적인 역할을 한다**고 설명합니다. 특히 현재 사회에 진출하는 주니어 개발자 세대가 이러한 변화의 첫 번째 주자가 될 것이라고 강조합니다.

하나의 개발자가 여러 에이전트를 관리하는 '에이전트 관리자'의 역할을 수행하게 됩니다. 에이전트를 많이 추가한다고 해서 항상 더 나은 시스템이 만들어지는 것은 아니며, 오히려 시스템을 방치하면 훨씬 나빠질 수 있습니다. 따라서 **여러 에이전트를 효과적으로 다루는 능력은 오늘날 상위 0.1%의 사용자만이 가질 수 있는 기술**이라고 언급합니다.

미하일은 샌프란시스코의 초기 스타트업에서 AI를 이끌고 있으며, 스탠포드에서 AI에 초점을 맞춘 첫 강의인 '현대 소프트웨어 개발자'를 가르치고 있습니다. 강의 발표 후 **수강 신청이 몇 시간 만에 100명이 넘게 몰렸다**는 사실은 AI와 소프트웨어 개발의 변화에 대한 높은 관심을 보여줍니다.

주니어 소프트웨어 엔지니어의 위기: 완벽한 폭풍

소프트웨어 개발 분야에 큰 변화가 일어나고 있으며, AI가 소프트웨어 제작의 모든 부분에 영향을 미치기 시작했습니다. 버클리 졸업생의 사례처럼, **많은 주니어 엔지니어들이 일자리를 찾기가 매우 어려운 현실**에 직면해 있습니다.

이러한 현상은 세 가지 요인이 동시에 작용하여 '완벽한 폭풍'을 이루었습니다. 첫째, 2021년 코로나19 이후의 채용 급증과 이후 발생한 대규모 정리 해고로 인해 **수많은 인력이 시장에 풀렸습니다.**

둘째, 지난 10~15년간 CS 전공 졸업생 수가 매년 급증하여 **새로운 엔지니어들의 공급이 넘쳐나고 있습니다.** 셋째, AI의 인기 상승으로 많은 고용주들이 더 적은 인원으로 고용 할당량을 충당할 수 있다고 고려하기 시작했습니다. 이로 인해 현재 노동 시장에 진입하는 주니어 개발자들은 **탄탄한 기본기를 바탕으로 AI를 완전히 활용할 수 있는 능력을 갖춰야 하는 첫 세대**가 될 것입니다.

최고의 AI 네이티브 엔지니어가 되는 법: 에이전트 오케스트레이션

AI 네이티브 엔지니어는 **전통적인 프로그래밍, 시스템 설계, 알고리즘 사고에 대한 강력한 기반**을 갖추면서 에이전트 워크플로우를 능숙하게 사용하는 사람입니다. 이들은 에이전트를 활용할 때 한 번에 여러 에이전트를 투입하기보다는 **하나씩 점진적으로 구축하는 방식**을 권장합니다.

작업 항목 간의 경계를 명확히 이해하고, 하나의 에이전트가 작업을 잘 수행하면 두 번째, 세 번째 에이전트를 추가하는 식으로 **반복적인 접근 방식**을 취해야 합니다. 이렇게 단계별로 구축하는 것이 에이전트를 효율적으로 활용하는 데 중요합니다.

두 번째 핵심 기술은 '컨텍스트 전환'입니다. 이는 마치 여러 인턴을 관리하는 것과 같습니다. 여러 에이전트가 각기 다른 작업을 수행할 때, **한 에이전트에서 다른 에이전트로 전환하면서도 작업의 맥락을 유지하고 의미 있게 추진하는 능력**이 중요합니다. 이는 훌륭한 인간 관리자가 갖춰야 할 자질과도 유사하며, 실제로 인간 관리 경험이 있는 사람들이 이 기술을 더 잘 적용합니다.

에이전트 친화적인 코드베이스 구축 전략

'에이전트 친화적인 코드베이스'는 에이전트가 코드베이스에 투입되었을 때, **코드베이스에서 무슨 일이 일어나는지 명확하게 이해하고 기여할 수 있는 환경**을 의미합니다. 이를 위해 소프트웨어의 정확성을 정의하는 '계약'인 테스트가 필수적입니다. 충분한 테스트 커버리지가 없다면, 에이전트는 작업 지침을 명확히 이해하기 어렵습니다.

코드와 Readme의 내용이 불일치하는 상황을 피해야 합니다. 에이전트가 Readme와 코드를 읽을 때, **어떤 해석이 맞는지 혼란을 겪지 않도록 일관성을 유지**해야 합니다. 에이전트는 오류를 매우 빠르게 누적할 수 있으므로, 처음부터 설계, 테스트, 빌드 측면에서 견고하고 완벽하게 튼튼한 코드베이스를 제공하는 것이 중요합니다.

따라서 에이전트가 보는 코드의 첫 번째 버전이 **자체적으로 일관성이 있고, 테스트가 잘 되어 있으며, 린팅과 스타일 검사를 통해 형식이 일관되게 유지되도록** 해야 합니다. 이는 에이전트가 코드베이스의 정의된 규칙을 항상 준수하도록 보장합니다.

마지막으로, 코드의 디자인 패턴이 일관성이 있는지 확인해야 합니다. 코드베이스의 다른 부분에서 동일한 객체를 생성할 때 다른 API를 사용한다면, 에이전트는 어떤 API를 사용해야 할지 혼란을 겪게 됩니다. **일관된 디자인 패턴과 프로그래밍 패턴**은 에이전트 친화적인 코드베이스의 핵심 요소입니다.

놀라운 소프트웨어와 개발자의 태도

기능적인 소프트웨어와 놀라운 소프트웨어의 차이는 단순히 취향의 문제일 수도 있지만, **문제를 해결하려는 열정에서 비롯됩니다.** 주어진 과제의 요구 사항을 충족하는 것을 넘어, 추가적인 노력을 기울여 기능을 확장하고, 더 강력하게 만들며, 애플리케이션에서 더 많은 것을 가능하게 만들 때 진정한 실력이 쌓입니다.

최고의 엔지니어들은 프로젝트를 시작으로 스타트업을 창업하는 등 **수업이 끝난 후에도 계속해서 아이디어를 발전시키고 실험**합니다. 앤트로픽의 클로드 팀조차도 클로드를 이용해 클로드를 재작성하며 끊임없이 실험하고 반복합니다. 이는 모든 해답을 가지고 있지 않더라도, **실험을 통해 무엇이 효과적인지 스스로 찾아나가는 과정이 중요하다**는 것을 보여줍니다.

학생들에게도 스스로 부딪혀 보고, **실험을 통해 자신에게 맞는 방식을 찾아내는 것**이 중요하다고 강조합니다. 실험, 해킹을 통해 새로운 소프트웨어 개발 방식을 업무의 일부로 만들어야 합니다.

주니어 엔지니어의 필요성: 순수함과 용기

경력이 많은 개발자들은 AI 도구에 대한 거부감을 느끼는 경향이 있습니다. 20년 동안 개발해온 자신만의 방식에 익숙해져 '이 방법만이 유일한 방법'이라고 생각하기 때문입니다. 하지만 **업계에 처음 입문하는 주니어 개발자들은 스펀지처럼 모든 것이 가능하다고 생각**합니다.

세상의 어려움에 대한 상처가 없기 때문에, 문제를 보았을 때 **'왜 내가 가서 시도하지 않지?'라고 생각하는 순수함과 용기**를 가지고 있습니다. 이러한 태도는 스타트업 창업자에게 완벽하며, 모두가 요구하는 AI 기술을 가장 민첩하고 빠르게 습득할 수 있게 합니다.

따라서 주니어 개발자들은 선임 개발자들이 할 수 없는 방식으로 성공할 수 있다고 생각합니다. 컴퓨터 과학은 **복잡한 시스템을 분해하고 작동 방식을 파악한 다음, 수정하고 확장하며 반복하는 작업**의 연속입니다. 개발자들은 문제가 발생하면 기꺼이 고치고, 내부를 파고들어 해결하려는 '오만함'에 가까운 자신감을 가지고 있습니다.

이러한 **개발자의 오만함, 즉 어떤 문제든 소프트웨어로 해결할 수 있다는 믿음**은 컴퓨터 과학 개발자들이 가진 가장 강력한 힘입니다. AI 네이티브의 핵심은 AI를 단순히 업무에 사용하는 것을 넘어, **AI가 사람의 개입 없이 고객과 직접 소통하며 업무를 처리할 수 있도록 제품에 내장하는 것**입니다.

AI들이 서로 대화하고 협업을 시작할 때 무엇이 필요할지에 대한 질문은 매우 흥미롭습니다. 이 질문에 대한 답을 잘 찾아내는 기업은 **조만간 조 단위의 가치를 지닌 기업**이 될 것이라고 예측합니다.

AI 네이티브 엔지니어란 무엇이며, 이들이 기존 개발자와 구별되는 핵심 역량은 무엇인가요?

주니어 소프트웨어 엔지니어들이 현재 겪고 있는 고용 시장의 어려움은 무엇이며, 이러한 어려움이 발생한 주요 원인 세 가지는 무엇인가요?

AI 에이전트 워크플로우를 효과적으로 관리하기 위한 '에이전트 친화적인 코드베이스'의 주요 특징과 구축 전략은 무엇인가요?

기능적인 소프트웨어와 '놀라운' 소프트웨어를 만드는 것의 차이점은 무엇이며, 후자를 달성하기 위해 어떤 노력이 필요한가요?

AI 시대에도 주니어 소프트웨어 엔지니어가 여전히 필요한 이유는 무엇이며, 이들이 시니어 개발자보다 더 잘할 수 있는 영역은 무엇인가요?

새로운 종류의 엔지니어가 등장하고 있는데, 저는 AI 네이티브 엔지니어라고 부르고 싶습니다. AI가 바로 그 언어입니다.

AI가 새로운 언어입니다. 지금 막 사회에 진출하는 주니어 개발자, 주니어 엔지니어 세대가 이러한 변화의 첫 번째 세대가 될 것이라고 생각합니다.

한 명의 개발자가 에이전트 관리자가 됩니다. 에이전트를 더 추가한다고 해서 항상 더 나은 시스템이 만들어지는 것은 아닙니다.

사실, 그냥 내버려 두고 원하는 대로 하게 하면 시스템이 훨씬 더 나빠질 수도 있습니다. 그래서 여러 에이전트를 제대로 다루는 방법을 아는 것은 게임의 최종 보스와 같습니다.

정말 능숙하게 해낼 수 있다면, 문자 그대로 오늘날에도 상위 0.1%에 속하는 사용자라고 할 수 있습니다.

저는 미하일입니다. 샌프란시스코의 초기 단계 스타트업에서 AI를 이끌고 있습니다.

스탠포드에서 강의도 하고 있습니다. 강의 제목은 '현대 소프트웨어 개발자'입니다. SDLC 전반에 걸쳐 AI에 초점을 맞춘 첫 번째 강의입니다.

강의 발표 후 수강 신청이 시작된 지 몇 시간 만에 100명이 넘는 학생들이 몰려왔습니다.

>> 주니어 소프트웨어 엔지니어에게 무슨 일이 일어나고 있는 걸까요?

소프트웨어 개발에서 뭔가 엄청난 일이 벌어지고 있다는 분위기가 팽배했고, AI가 소프트웨어가 만들어지는 모든 부분에 실제로 영향을 미치기 시작했습니다.

분명히 변화가 일어나고 있었고, 버클리를 갓 졸업한 사람에게서 꽤 끔찍한 이야기를 들었습니다. 천 군데에 지원했는데 겨우 두 군데에서만 연락이 왔다고 하더군요.

인터뷰를 보거나 채용 과정을 거친 것도 아니고, 그냥 연락만 받은 겁니다. 현실은 많은 주니어 엔지니어들이 그런 역할을 맡기가 매우 어렵다는 것입니다.

소프트웨어 생태계에서 흥미로운 시기입니다. 기본적으로 세 가지 일이 동시에 일어나 일종의 완벽한 폭풍을 이루었습니다.

첫 번째는 2021년쯤에 코로나19 이후 채용이 엄청나게 늘어났다는 것입니다.

많은 회사들이 직원 수를 늘려야 한다고 생각했고, 이후 많은 회사들이 과도하게 채용했다는 것을 깨달았다고 생각합니다.

그러니까 대규모 정리 해고가 있었는데, 수많은 사람을 고용했던 모든 회사들이 인력을 20%, 30% 줄여도 괜찮다는 것을 깨달은 거죠.

그것은 CS 커리큘럼, 즉 국내외적으로 CS 전공의 성장이 지난 10년에서 15년 동안 엄청나게 성장했다는 사실과 결합된 것입니다.

제가 졸업할 때만 해도 졸업생 수가 어느 정도 있었는데, 그 이후로 CS 졸업생 수가 매년 2배에서 3배로 늘어난 것 같아요.

그래서 본질적으로 해고된 엄청난 인력이 있는 겁니다. 일자리를 원하는 새로운 압도적인 차세대의 엔지니어들이 있는 것이고요.

그리고 이 모든 것에 기여했다고 생각하는 세 번째 요인은 AI가 인기를 얻었다는 것입니다.

사람들이 AI에 정말 관심을 갖기 시작한 거죠. 그래서 많은 고용주들이 제 공백을 메우기 위해 더 많은 사람을 고용해야 할까, 아니면 AI에 능숙한 사람을 더 적게 고용해서 고용 할당량을 충당할 수 있을까를 고려하기 시작했습니다.

그래서 이 특정 세대의 주니어 개발자, 주니어 엔지니어, 즉 지금 노동 시장에 진입하는 사람들은 좋은 기본기를 갖추고 AI를 완전히 활용할 수 있어야 하는 새로운 변화의 첫 번째 세대가 될 것이라고 생각합니다.

상위 1%의 AI 네이티브 엔지니어가 에이전트를 오케스트레이션하는 방법. 핵심적으로 AI 네이티브 엔지니어는 전통적인 프로그래밍, 시스템 설계 및 알고리즘 사고에 대한 강력한 기반과 토대를 가지고 있는 동시에 에이전트 워크플로우를 매우 능숙하게 사용하는 사람이라고 생각합니다.

저는 항상 그들에게 조금씩 구축하라고 가르칩니다. 클로드의 보리스는 한 번에 10개의 에이전트를 사용한다고 말했으니 저도 한 번에 10개의 에이전트를 사용해야 한다고 생각할 수 있습니다.

그것은 강조해야 할 잘못된 결과입니다.

다시 말하지만, 저는 한 번에 하나씩 구축할 것입니다. 저는 '나는 하나의 에이전트 워크플로우를 꽤 잘 수행할 수 있고, 하나의 에이전트로 복잡한 소프트웨어를 구축할 수 있지만, 아마도 작은 변화인 다른 작업을 해야 한다는 것을 알고 있다'라고 말할 것입니다.

자신의 작업을 고립되어 있고 두 번째 또는 세 번째 에이전트가 자신 있게 수행할 수 있는 것으로 생각하십시오.

그래서 로고를 수정하는 두 번째 에이전트를 추가하면, 이 에이전트는 로고를 수정하고 있습니다.

다른 에이전트는 웹사이트 헤더의 문구를 업데이트할 수도 있습니다.

그리고 이것은 두 번째 에이전트가 하는 일과는 전혀 관련이 없는 독립적인 변경입니다.

그래서 저는 에이전트에게 더 많은 작업을 반복적으로 추가하는 방식으로 생각합니다. 먼저 무엇을 해야 하는지 이해하고, 작업 항목 간의 경계가 어디에 있는지 파악한 다음, 하나의 에이전트가 작업을 잘 수행하고 있다고 생각되면 두 번째 에이전트를 추가하세요.

두 번째 에이전트도 잘하고 자신감이 생기면 세 번째 에이전트를 추가하는 거죠.

그러니까 한 번에 10명의 에이전트를 투입하기보다는 단계별로 구축하는 것이 좋습니다. 두 번째로 정말 중요한 것은 컨텍스트 전환 방법을 아는 것입니다.

실제로 여러분이 하는 일은 인턴을 투입하는 것과 같습니다.

기본적으로 이 에이전트들은 의욕이 넘치고 똑똑한 인턴과 같아서 어떤 일을 하고, 여러분은 터미널이나 IDE에서 그들을 지켜보면서 그들이 일을 하고 코드를 기여하고 어딘가에 작성되는 것을 보게 됩니다.

하지만 때로는 막히기도 하죠? 에이전트 1은 이 특정 작업을 하고, 에이전트 2는 다른 작업을 하고, 에이전트 3은 또 다른 작업을 하고 있을 때, 어떻게 한 에이전트에서 다른 에이전트로 전환하면서 '이봐, 에이전트 1은 이 특정 작업을 하고 있었고, 에이전트 2는 다른 작업을 하고 있었지'라는 것을 이해할 수 있을까요? 그리고 여러분은 끊임없이 앞뒤로 전환하게 됩니다.

그리고 그것은 인간으로서도 매우 어려운 일입니다.

마지막으로 작업하던 내용을 기억하면서도 해당 작업을 의미 있게 추진할 수 있을 만큼 충분한 맥락을 유지하는 방법을 아는 것이죠.

그래서 저는 그 전환이 멀티 에이전트 워크플로우를 정말 잘 작동시키는 핵심 기술 중 하나라고 생각합니다.

제가 설명한 것은 기본적으로 훌륭한 관리자, 즉 훌륭한 인간 관리자를 만드는 요소입니다.

그것은 에이전트와는 아무런 관련이 없습니다. 만약 여러분이 그 일을 정말 잘 해낼 수 있다면, 여러분은 매우 훌륭한, 훌륭한 인간 관리자가 될 것입니다.

제가 보기에 그걸 가장 잘하는 사람들은 인간 관리자, 그러니까 개발자들을 관리해 본 경험이 있는 사람들이에요. 그런 사람들은 상황을 전환하는 방법, 그리고 비슷한 원칙을 에이전트에게 적용하는 방법을 알고 있죠.

제가 '에이전트 친화적인 코드베이스' 또는 '에이전트 친화적인 개발 생태계'라고 부르는 개념이 있습니다.

여기서 제가 의미하는 바는 에이전트가 여러분의 코드베이스에 투입되었을 때, 코드베이스에서 무슨 일이 일어나는지 이해할 수 있을까 하는 것입니다.

코드베이스 환경에서 에이전트가 투입되어 빌드하도록 할 때, 에이전트가 뭔가를 망가뜨리지 않고, 에이전트가 기여하는 모든 것이 제대로 작동하도록 보장하는 방법은, 기본적으로 소프트웨어의 정확성을 정의하는 계약인 테스트를 통해 검증하는 것입니다.

이러한 계약을 정의해야 합니다. 충분한 테스트 커버리지가 없다면, 소프트웨어에 대한 계약이 없는 것입니다.

에이전트는 소프트웨어의 명시적으로 정의된 계약과 같이 계약에 따라서만 작동할 수 있습니다. 업계에 종사하는 개발자라면 누구나 Readme가 코드에서 일어나는 일과 거의 즉시 동떨어진다는 것을 알고 있습니다.

그래서 같은 것에 대한 두 가지 설명이 있는 것이죠.

코드는 한 가지를 말하지만, Readme는 완전히 다른 것을 말합니다. 코드에 그런 상황이 있다면 에이전트는 Readme와 코드를 읽고, 어떤 해석이 맞는지 물어볼 것입니다.

Readme에 따라야 할까요, 아니면 코드베이스에 따라야 할까요? 따라서 일관성을 유지해야 합니다.

맞죠? 간단한 문제입니다. 스파게티 코드가 되는 경우는 일반적으로 에이전트가 여러 번 반복해서, 어쩌면 여러 기능을 위해 뭔가를 빌드했을 때, 약간 궤도를 벗어나기 시작할 때입니다.

에이전트가 정말 잘하는 나쁜 점 중 하나는 오류를 매우 빠르게 누적할 수 있다는 것입니다. 에이전트가 코드에서 한 가지 오해를 하고, 1단계에서 자신이 만든 오해를 발견하면, 2단계에서 또 다른 오류를 만들 수 있습니다.

오류를 확대하는 것이죠. 가장 중요한 것은 에이전트가 처음 보는 것이 설계, 테스트, 빌드 측면에서 완전히 견고하고 완벽하게 튼튼한지 확인하는 것입니다. 에이전트에 대해 생각하기 전에 코드베이스 자체의 핵심 부분을 먼저 확인해야 합니다.

그러니까 다시 말해서 에이전트가 보는 코드의 첫 번째 버전이 자체적으로 일관성이 있는지 확인하고, 테스트가 잘 되어 있는지 확인하고, 린팅과 스타일 검사를 통해 코드베이스의 형식이 일관되게 유지되도록 해야 합니다.

이러한 요소들이 에이전트가 이미 정의한 코드베이스 규칙을 항상 준수하도록 보장할 것입니다.

마지막으로 에이전트 친화적인 코드베이스의 또 다른 예를 들자면, 코드의 디자인 패턴이 일관성이 있는지 확인해야 합니다.

여기서 제가 의미하는 바는 코드베이스의 한 부분에서 특정 종류의 객체를 생성할 때 이 API를 사용하고, 코드베이스의 다른 부분에서도 동일한 객체를 생성하지만 다른 API를 사용하는 경우입니다.

에이전트가 이제 코드베이스에서 개발해야 할 때 어느 API를 사용해야 할까요?

API 1을 사용해야 할까요, 아니면 API 2를 사용해야 할까요? 에이전트가 잘못된 API를 선택하면 사람이 봐도 혼란스러울 것입니다.

만약 제가 코드베이스에 들어갔는데 두 가지 다른 방법이 있다면, 저 또한 1번을 해야 할지 2번을 해야 할지 스스로에게 물어볼 것입니다.

모르겠어요. 둘 다 보이는데요.

아마 팀원에게 '어느 것을 사용해야 하죠?'라고 물어볼 것입니다.

일관된 디자인 패턴과 프로그래밍 패턴은 제가 본 최고의 에이전트 친화적인 코드베이스에서 사용하는 요소라고 생각합니다.

>> 기능적인 소프트웨어 대 놀라운 소프트웨어. >> 기능적인 소프트웨어와 놀라운 소프트웨어를 정의하는 몇 가지 요소가 있습니다. 한 가지 답변은 단순히 취향, 즉 좋은 소프트웨어 취향이란 무엇인가입니다.

진정으로 취향이 있는 사람과 없는 사람, 또는 취향을 개발하는 데 더 많은 시간을 투자하는 사람들이 있습니다.

제 수업의 학생들을 보면 다섯 가지 흐름을 만들어야 하는 등의 요구 사항이 있었습니다.

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

스크립트