От помощи ИИ к ИИ-ориентированности: создание команды разработки нового поколения — Клэр Лигуори, AWS
AAI Engineer
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00Клэр Лигуори: Меня зовут Клэр Лигуори, я главный ведущий инженер в AWS.
00:00:17Я в основном работаю над Kiro, нашим ассистентом по декодированию, но сегодня я хочу рассказать
00:00:23о некоторых практиках, которые мы наблюдаем внутри Amazon, в командах Amazon, где мы видим
00:00:28действительно впечатляющие результаты роста производительности — это качественный скачок по сравнению с тем,
00:00:35что мы до сих пор видели с ИИ. Я занимаюсь агентным ИИ уже более трех лет,
00:00:43и я наблюдала эволюцию, происходящую в нашей индустрии в сфере помощи в написании кода
00:00:48с помощью ИИ. Сначала у нас было автодополнение кода в реальном времени, помогающее писать следующую строку,
00:00:55а может, и следующую функцию. Мы перешли к чату, задавая вопросы о нашем коде. Все начали заниматься
00:01:02вайб-кодингом в какой-то момент прошлого года, но теперь мы вступаем в фазу ранних последователей того,
00:01:08что мы называем рубежной или фронтирной разработкой. И совершенно субъективно, опираясь на собственный опыт,
00:01:14я чувствовала себя лишь примерно на 10–20% продуктивнее благодаря всем тем этапам, которые
00:01:20были до этого. Но теперь внутри Amazon мы проводим пилотные проекты с различными командами по всей компании,
00:01:27и мы видим медианный рост производительности в 4,5 раза, а иногда и более чем в 10 раз. Так что
00:01:34кое-что действительно изменилось теперь, когда мы наблюдаем эти скачкообразные улучшения производительности.
00:01:40И мне нравится определять тех, кого мы внутри Amazon называем разработчиками-фронтирами,
00:01:47через три паттерна поведения, которые я наблюдаю. Первый — это программирование без участия рук. Разработчики-фронтиры пишут, пожалуй,
00:01:541–2% производимого ими кода. Остальное делают агенты. Второй — они взаимодействуют со своими
00:02:01агентами нечасто. Они стремятся к тому, чтобы их помощник по кодингу работал часами без какого-либо
00:02:08вмешательства с их стороны. И третий — они минимизируют время простоя. Такие разработчики обычно запускают
00:02:15несколько агентов параллельно, обрабатывая бэклог задач. Впервые я увидел команду передовых
00:02:24в команде Bedrock Mantle. Bedrock — это наш сервис хостинга моделей. Он размещает такие языковые модели, как Claude
00:02:34и GPT. И в какой-то момент в прошлом году мы знали — или, точнее, я говорю «мы», но команда Bedrock знала, — что им придется
00:02:43создать новую плоскость данных для инференса. Но они оценивали это в 30 человек за 18 месяцев. Это огромный,
00:02:52огромный сервис. И потребовалось бы время на создание новой системы, миграцию клиентов, миграцию моделей.
00:02:58И они решили сделать шаг назад. Они взяли шесть человек и создали его за 76 дней с помощью Kiro.
00:03:06Так что это было колоссальное достижение. Это был первый случай, когда мы увидели нечто подобное внутри Amazon.
00:03:12Это была поистине команда-первопроходец, доказавшая возможность 20-кратного прироста. Теперь они проанализировали
00:03:21коммиты, и я упомяну еще пару способов измерения прироста производительности. Но
00:03:27в этой истории была одна проблема: да, проект был создан шестью людьми. Он был создан
00:03:34буквально лучшими инженерами компании, включая двух заслуженных инженеров. Так что это была
00:03:40не просто любая команда из шести человек. Это были эксперты по распределенным системам, эксперты по языковым моделям и их
00:03:49оказалась практически недостижимой для многих команд. Возникало много вопросов: можно ли это вообще воспроизвести
00:03:57в другой команде? Поэтому следующий эксперимент, о котором я хочу рассказать, — это экспериментальный спринт,
00:04:03который проводился в подразделении Prime Video. Они выделили 10-дневный спринт и провели эксперимент, поместив опять же шестерых инженеров
00:04:10в комнату и позволив им вовсю экспериментировать с Kiro. Они сократили оценку времени реализации проекта с предполагаемых
00:04:1990 недель до 24, основываясь на всем прогрессе, достигнутом за этот 10-дневный спринт.
00:04:29И они изучили историю своих коммитов, оценив, что они делали до этого
00:04:3610-дневного спринта и сколько коммитов они произвели всего за эти 10 дней. Этот спринт действительно
00:04:42доказал, что мы можем добиться чего-то близкого к тому, чего достигла команда Bedrock Mantle,
00:04:49но уже с другой группой инженеров. Но опять же, в этой истории была сложность: это были шесть
00:04:58инженеров в комнате без дежурств, с минимумом встреч и малым количеством отвлекающих факторов, которые, как мы все
00:05:05знаем, являются обычным делом в жизни инженера. При этом ведущий инженер команды потратил предыдущие
00:05:12три недели на создание очень подробных, небольших, хорошо проработанных задач с четкими требованиями для этих шестерых
00:05:20инженеров, чтобы те просто выполняли их в течение этих двух недель. Так что это, опять же, не обязательно была реальная жизнь.
00:05:28Это был структурированный спринт, изолированный момент времени, когда им удалось этого достичь. Но опять же,
00:05:35вопрос в том, достижимо ли это в реальных командах для повседневной работы? Поэтому Amazon Stores, куда входят
00:05:41Amazon.com, все наши розничные сайты, а также физические магазины, провели более структурированный пилотный проект.
00:05:51Они наблюдали за 50 абсолютно обычными командами с нормальным распределением начинающих специалистов, специалистов среднего уровня
00:05:59и старших инженеров, которые работали над существующими системами. Никаких проектов с нуля, как у команды Mantle,
00:06:07которая строила все с чистого листа — только существующие системы с уже имеющейся кодовой базой.
00:06:14И за ними наблюдали большую часть прошлого года, обнаружив нечто крайне интересное.
00:06:21Они выяснили, что существует огромная разница в приросте производительности между одной половиной команд и другой.
00:06:28В данном случае в качестве метрики производительности они использовали скорость развертывания в продакшн. То есть не просто коммиты,
00:06:34сколько коммитов они производят, а как быстро мы доставляем изменения клиентам? Как быстро мы
00:06:41способны выпускать релизы? И они увидели, что у половины команд прирост составил менее чем в 3 раза. И то,
00:06:48что определяло разницу между менее чем трехкратным ростом и теми командами, которые добились
00:06:56медианного показателя в 4,5 раза, а в некоторых случаях более 10, заключалось в том, как именно они использовали инструменты.
00:07:0190% этих команд использовали Kiro наряду с другими нашими внутренними инструментами. И выяснилось,
00:07:11что дело было не в самих инструментах, а в методах работы. Команды, добившиеся скачкообразного улучшения,
00:07:18целенаправленно изменили свой подход к работе,
00:07:26в то время как остальные просто «присыпали» Kiro и другие доступные инструменты поверх
00:07:31своего привычного рабочего процесса. И по крайней мере для меня это стало главным инсайтом: почему я не ощущала
00:07:39тот колоссальный прирост производительности, который обещал ИИ — все дело в изменении нашего метода работы.
00:07:47Поэтому в ходе этого пилота они опросили участвовавшие команды, а также сотрудников из других подразделений
00:07:55вроде Bedrock Mantle и Prime Video, и выделили пять привычек. И я использую
00:08:03слово «привычки» вполне осознанно, потому что дело не в каком-то одном спринте, а в том, чтобы применять это изо дня в день.
00:08:09И в ходе интервью с этими командами выяснилось, что речь действительно шла о привычках, которые приходилось вырабатывать ежедневно.
00:08:15Когда мы меняем свой рабочий процесс, эти привычки формируются с трудом, на это требуется время.
00:08:22Давайте пройдемся по каждой из них. Привычка первая — инвестирование в контекст агента.
00:08:30У нас в голове много информации, и мы привыкли передавать все эти знания другим людям
00:08:35через беседы в Slack, онбординг менторов, код-ревью,
00:08:42стендапы и планирование спринтов, но теперь им пришлось все это записать. И выработанная ими привычка
00:08:50заключалась в том, что каждый раз, когда агент совершает ошибку или делает что-то не так, как сделали бы вы,
00:08:55нужно задаться вопросом: чего не хватает в моих файлах навыков? Чего не хватает в моих файлах управления, что потребовалось бы агенту?
00:09:01Но затем, как мы знаем, за последний год мы увидели гигантские скачки в возможностях и поведении моделей.
00:09:09У Sonnet 3.7 в середине прошлого года было много особенностей, из-за которых нам приходилось прописывать кучу запретов
00:09:16в наших управляющих файлах. Теперь же с Opus 4.5, вышедшим в ноябре прошлого года, нам уже не приходится делать это столь часто,
00:09:23и с тех пор прошло уже больше шести месяцев улучшений со всеми новыми
00:09:29версиями моделей, появившимися с того момента. И новый вопрос, новая привычка: нужно ли мне
00:09:35все еще держать это в файлах управления? Или это просто загромождает контекст? Вторая привычка — замедлиться,
00:09:41чтобы ускорить процесс. Почти каждая опрошенная команда отмечала, что их производительность
00:09:48на самом деле падала при осознанном переходе на новый метод работы. Звучит контринтуитивно,
00:09:53правда? Вам нужно выполнить осознанную инженерную работу, прежде чем вы увидите эту
00:09:59хоккейную кривую роста производительности. Ведь нам приходится сначала проделать реальную работу в кодовых базах,
00:10:05чтобы агенты могли там преуспеть, особенно в унаследованных (brownfield) существующих кодовых базах. Поэтому им пришлось
00:10:11наращивать контекст агента, улучшать сообщения об ошибках существующих инструментов, чтобы модель понимала,
00:10:17что происходит при сбое; они создавали новые инструменты, новые MCP-серверы, помогающие модели реально
00:10:24выполнять нужную работу. Множество команд в итоге реструктурировали свою кодовую базу, чтобы агентам
00:10:29было проще в ней ориентироваться. Я даже видела радикальные изменения, такие как смена языка программирования
00:10:36кодовой базы. Часто я видела, как команды борются с Python или JavaScript, потому что это нетипизированные
00:10:43языки. Их сложно тестировать. Нет ошибок компилятора. Поэтому модель в некотором роде угадывает и
00:10:50возвращает результат вам. В связи с этим я наблюдала, как команды переходят на TypeScript. Rust стал очень популярен
00:10:56внутри Amazon. Компилятор выдает отличные сообщения об ошибках. И я видела немало
00:11:03команд, идущих на такие осознанные изменения ради получаемого прироста производительности.
00:11:09Третья привычка — подкармливать агентов, а не нянчиться с ними. И для меня это стало одним из тех инсайтов,
00:11:16почему мы наблюдаем этот скачкообразный рост производительности. Если вы занимаетесь вайб-кодингом, если вы
00:11:23целый день ведете диалог туда-сюда со своим агентом, конечно, вы не увидите
00:11:30четырех- или пятикратного роста производительности, потому что вы вовлечены в цикл все время. Вы, вероятно,
00:11:36сидите там от 30 секунд до минуты, ожидая, пока он сгенерирует код и вернется к вам
00:11:42с кодом для проверки. Если вы сидите и ждете этого, вы не можете заняться чем-то другим.
00:11:48stuff. It's really difficult to run agents in parallel. It's very difficult to get to to clone yourself
00:11:55into multiple agents. And so if your conversations look a bit like this on the left, then you're
00:12:01babysitting that agent as opposed to the right side where you're feeding it what it needs to do and how
00:12:08it can self-validate. And that's really the key so that agents can self-correct and only come back to you
00:12:14when it meets a certain quality bar, when it when it actually runs and compiles and passes tests, when
00:12:20it's testable, when it actually has high coverage. And of course, the next level is put all of this
00:12:26content into your steering file. So it does it every time without you having to prompt it.
00:12:33The fourth habit is to make intent explicit. At Amazon, we practice a lot of spectrum and development.
00:12:40We've built that into the Kiro product. And so it's very natural for Amazon engineers to adopt it
00:12:46in Kiro. What what I've typically seen with vibe coding as opposed to frontier engineering is giving
00:12:54a very high level prompt, letting the agent generate a ton of code, and then having a back and forth
00:13:02conversation saying, Oh, that's not really what I meant. That you haven't you haven't exactly gotten the requirements right.
00:13:10No, I didn't actually want to build it that way. Here's a technical design. And it is less I find less productive
00:13:17to iterate with the agent on code when the intent itself was incorrect. So often we'll have while see Amazon
00:13:26engineers go through this process for ambiguous, complex features of writing the specification.
00:13:34And in Kiro, of course, you don't have to write this whole specification, you can have the model generate
00:13:39it. But it's a lot easier to iterate with the model in kind of a back and forth conversation about a
00:13:46document than it is about code that's code changes that are spread across a code base. The fifth one is shift testing
00:13:56left. One of the keys here is to give the agent that fast feedback loop, because that's what lets it go off for hours
00:14:04at a time and self correct. The agent is going to make mistakes, and that's fine. But if you give it the right signals, it can
00:14:12self correct and it can spend a while doing that. So I've seen teams adding linters, adding unit tests,
00:14:20integration tests, performance tests, security tests. These are all things we all know we should have
00:14:24been doing all along. This is good engineering hygiene and practices. But now the ROI is, I think, finally
00:14:32high enough for us to actually invest in it. One thing that I've been seeing a lot of teams do is mock out
00:14:40services. Often with integration tests, we would test kind of end to end an entire system, including live
00:14:46services. But we've been investing a lot in mock services that run entirely locally with deterministic
00:14:52responses, because it lets the agent do everything locally. Doing everything on your laptop without
00:15:01having to spin up a bunch of other services and connect to cloud services makes everything a lot faster.
00:15:07Because the more that your agent can get fast feedback means the more loops that it can
00:15:14can do and the more productive your own agent can be. So across all of these, these are some of the
00:15:21habits we've seen. But of course, I would be remiss if I would tell you if you adopt all of these habits,
00:15:28you will achieve nirvana, you will be the most productive engineering organization the world has
00:15:35ever seen. Things are still hard. We are still very much in an early adopter phase and teams are still
00:15:42figuring it out. So one thing that we've been seeing across our teams just organizationally is the risk of
00:15:48burnout. I did not coin this term, I forget who did at what conference, but FOMAT is real. We've been seeing
00:15:56engineers staying up late, late at night, trying to get that perfect prompt that's going to make their
00:16:03agent run for hours overnight so that they wake up in the morning with a code change ready. The cognitive load
00:16:09increases as you run these multiple agents in parallel, you're constantly shifting between
00:16:15terminal tabs. And then we do see that reviewing AI output is often harder for some than than actually
00:16:22writing it, especially early in career. Senior engineers have have already spent a large portion of their
00:16:29career reviewing others code. But early career engineers don't have that muscle yet. And so reviewing
00:16:37it can can feel like a lot more cognitive load than they're used to in actually writing it. The other
00:16:44one is organizational change. So it's already hard to change the way we work as engineers. The way that we
00:16:52spend our entire day completely changes when we're frontier engineers. But also organizations have to
00:16:58change to enable frontier engineering teams. One that I've seen very commonly is accepting slowing down
00:17:07to speed up. And I've been guilty of this myself. My fellow leaders have been guilty of this of saying,
00:17:14well, you have the AI tools now and the models are so amazing now. Why are you not going faster?
00:17:22And that's because you have to take those two months to invest in your code base to figure out the best
00:17:29best practices for your team to make hard habit changes on your team. And if you're constantly expecting
00:17:38shipping features every month, because now we have these amazing models, and we're seeing
00:17:44all of these companies on X saying how they're shipping 20 PRs a day, we have to slow down to speed up.
00:17:54The second one is actually going too broad in the organization too fast. I think that if we had
00:18:01expected all teams in massive organizations to be frontier teams immediately, we would not have had
00:18:08the learnings that we had from the pathfinder, from the from the sprint experiment, from the pilot
00:18:16teams within Amazon. And now the challenge for us is how do we scale it out? And that's what 2026 is about.
00:18:22For Amazon is how do we scale this out to more and more teams to the next 2000 teams instead of 50 teams.
00:18:31And so I think that when you roll it out too quickly, you have a lot of teams who don't know what they're
00:18:37doing. You haven't had time to find the best practices for your own organizations, the the context
00:18:43that your organization needs. And the last one is that you're going to find new bottlenecks.
00:18:49Previously code writing code manually was the bottleneck. I find that within Amazon, we've found
00:18:58the speed of decision making becomes a new bottleneck. The more that you spend reviewing the decision to
00:19:05actually build a new product, the slower it is to build the product now because the code only takes one to two months to write.
00:19:12All of the review processes associated with the launch of a product become the bottleneck.
00:19:20When it used to take nine to 12 months to build a new product, it didn't matter so much in the in the overall
00:19:27wash of things. If it took two months to make the decision to build the product and then two months to
00:19:33approve the launch. But now those are the bottlenecks. Those are the long pole. And so you find all of
00:19:40these all of these things that slow you down. Often I find that frontier engineering teams spend more time
00:19:48making decisions than they do writing code. And so the more that you can make fast decisions, especially ones
00:19:54that are easy to be reversed, the better. So my one big takeaway for for everyone here is that frontier
00:20:03engineering is about intentionally changing the way that you work. And that is difficult. That takes time.
00:20:10It is forming new habits and a new way of working. And that goes across any engineering team as well as your
00:20:18organization. So I encourage you to think about how you're interacting with AI tools and how that can
00:20:27change to free yourself up from being in the loop. Thanks. I'll hang out a little bit if anyone has
00:20:34questions in the back. But thanks for the time today.