Как frontier teams переосмысливают AI-native разработку

Frontier teams не просто используют ИИ, чтобы писать код быстрее. Они перестраивают сам процесс создания ПО. В результате — рост производительности в 4,5 раза, а в отдельных случаях более чем в 10 раз.

Шесть инженеров. Семьдесят шесть дней. Проект, который изначально оценивался как работа для 30 разработчиков на 12–18 месяцев, был завершён за один квартал. Это не гипотеза. Так произошло, когда команда Amazon Bedrock перестала воспринимать ИИ как ускоритель кодинга и начала использовать его как основу своей работы. За пять месяцев команда выпустила в продакшен больше кода, чем за предыдущие десять лет.

Разрыв между такими командами и всеми остальными быстро растёт. AI coding agents радикально изменили скорость написания кода, но не скорость его попадания к клиентам. Количество коммитов растёт, CI/CD-пайплайны загружены как никогда. Но количество фич, доходящих до продакшена, не растёт тем же темпом. Узкое место не в том, что агент не умеет генерировать результат. Узкое место в доступе агента к знаниям, которые нужны для хороших решений, и в готовности команды перестроить работу под эту реальность.

Мы называем команды, которые это поняли, frontier teams. Они не ограничены элитными лабораториями. Они есть в разных отраслях и компаниях разного масштаба, и их объединяет одна дисциплина: они рассматривают внедрение ИИ как инженерную инвестицию, а не как простой запуск инструмента. Любая инженерная команда может стать frontier team; ниже — как к этому прийти.

Три пути к AI-native разработке в Amazon

AI-native software development предполагает, что ИИ становится основой того, как создаётся программное обеспечение, а всё более способные агенты направляются людьми-экспертами. То, как команды управляют этими агентами, и определяет результат. В Amazon основными целями применения ИИ в разработке были сокращение времени, которое разработчики тратят на не-кодовые задачи — документацию, координацию и операции, — снижение технического долга и уменьшение несогласованности кода между тысячами небольших команд разработчиков формата two-pizza. Мы экспериментировали на сотнях инженерных команд и выделили как минимум три пути: инициативу pathfinder, где эксперты решают конкретную задачу; структурированный sprint по заранее определённому плану; и in-situ эксперимент, где команды разделяли между обычным подходом и workflow, адаптированным под ИИ. Структура у этих путей разная, но вывод один и тот же.

Pathfinder initiative была контролируемым экспериментом. Шесть старших инженеров получили одну задачу: переписать Amazon Bedrock inference engine — проект, который изначально оценивался как работа для 30 разработчиков на 12–18 месяцев. Вместо наращивания штата команда первые недели перестраивала workflow вокруг ИИ: переходила от разрозненных задач к целям, запускала несколько агентов параллельно и настраивала систему так, чтобы ИИ мог самостоятельно работать в нерабочее время. Проект был сдан за 76 дней. Индивидуальная продуктивность разработчиков выросла примерно в 20 раз, если считать по normalized commit velocity — числу коммитов на разработчика в неделю с поправкой на сложность репозитория и размер команды. Количество коммитов выросло с 2 в неделю до 40. Команда выпустила в продакшен больше качественного кода за пять месяцев, чем по проектам за предыдущие десять лет, если мерить это количеством строк, доведённых до production.

Structured sprint пошёл по другому пути. Команда Prime Video Financial Systems провела 10-дневный эксперимент, вдохновлённый моделью pathfinder. Шесть инженеров, одна комната, никакого контекстного переключения, без on-call, без других проектов, минимум встреч. Старший инженер заранее потратил три недели на то, чтобы разложить сложность на чётко определённые задачи с подробными требованиями. Команда использовала spec-driven development для сложной функциональности и прямую agent-assisted development там, где требования уже были ясны. За 10 дней они сделали 556 коммитов против базового уровня в 96 и сократили оценку проекта с 90 недель до 24 недель. Это даёт почти 6-кратный рост throughput и ускорение в 4 раза. Они объясняют выигрыш тремя факторами, которые усиливают друг друга: ускорением низкозначимых задач (1,5x), большей концентрацией на высокозначимых задачах без переключения контекста (1,5x) и мгновенным доступом к domain expertise, зафиксированной агентом (1,5x). Уберите любой из факторов — и эффект исчезает. Сейчас команда ищет способ встроить эти три фактора в обычную работу с помощью подробных product specs, которые содержат доменные знания, и автономных агентов, освобождающих время для фокусной работы.

В in-situ experiment среди 50 с лишним изученных команд 25 команд, которые внедрили и новые инструменты, и новые практики, показали результаты лучше, чем те, кто просто добавил ИИ в существующий workflow. Amazon Stores провела структурированные пилоты с обычными development teams, работавшими со своими стандартными backlog’ами, используя Kiro и специализированные AI tools без особых условий и без отобранных вручную инженеров. Медианный рост продуктивности составил 4,5x, а у некоторых команд — более чем 10x по normalized deployment velocity, то есть по числу фич, выпущенных за спринт, с нормализацией относительно исторической базы. Perfect Order Experience теперь выпускает фичи за одно утро вместо двух недель. WW Grocery сократила создание design document с пяти дней до нескольких часов.

Разные пути, один вывод: важен workflow, а не только инструмент.

Пять шагов к frontier team

Независимо от выбранного пути, у самых сильных команд есть пять общих практик. Логика одна: уменьшить барьеры для контекста у агента и увеличить объём работы, которую он может выполнять самостоятельно.

Здесь frontier teams отходят от прежних привычек. Исторический подход оптимизировал скорость генерации кода отдельным разработчиком. Frontier teams оптимизируют другое: скорость, с которой правильное, production-ready ПО доходит до клиентов. Это различие и определяет каждую практику ниже.

1. Инвестируйте в контекст для агента. Самые продвинутые команды серьёзно вкладываются в то, чтобы проекты и знания было проще потреблять агентам: через agent steering files и инструкции по командным conventions, coding standards, testing и навигации по codebase. Команда инфраструктуры Bedrock собрала весь код и документацию в monorepo и сохранила inline commentary, которое генерировали AI agents, как постоянную память. Команды, которые пропускают этот шаг, потом удивляются, почему их агенты снова и снова совершают одни и те же ошибки.
2. Сначала замедлитесь, чтобы потом ускориться. Эта практика требует времени и терпения. Все высокоэффективные команды отмечали, что в начале работа действительно замедлялась, пока они учились работать с моделями. Они кодировали cross-functional expertise в переиспользуемые steering docs для агентов, перестраивали репозитории так, чтобы LLM могли по ним рассуждать, и добавляли комментарии и пересобирали разбиение кода под потребление ИИ. Команды, которые прошли этот учебный период и сначала определили ожидаемый результат, получали ускорение, которое накапливается. Те, кто ожидал мгновенного эффекта без изменения workflow, были разочарованы. Первые две недели, скорее всего, будут казаться медленнее. После этого недели начнут ощущаться заметно быстрее. Те, кто сдаются на второй неделе, никогда не видят накопительного эффекта.
3. Кормите агентов, а не нянчитесь с ними. Frontier teams поддерживают стабильный backlog из хорошо определённых задач с ясным результатом, запускают несколько агентов параллельно и проверяют результат асинхронно. Разработчики говорят, что заканчивают крупные фичи короткими рывками, а работа движется вперёд даже тогда, когда они не ждут завершения задачи в режиме реального времени. Один principal engineer выпустил полноценное изменение, имея всего «пару часов непрерывного времени», потому что агент работал, пока инженер переключался между code review, operational support и встречами.
4. Явно формулируйте intent до написания кода. Будь то структурированные specifications, подробные документы с требованиями или хорошо декомпозированные задачи, frontier teams заранее дают агентам чёткий контекст о том, что означает «готово», ещё до генерации кода. Некоторые команды, использующие такой подход, пишут вручную лишь 1–2% кода, при этом делают значительно больше коммитов на человека в неделю, чем раньше.
5. «Сдвигайте тестирование влево». Frontier teams строят tooling так, чтобы агенты могли локально запускать все integration tests и сами исправлять ошибки ещё до попадания кода в pipeline. Команда Prime Video инвестировала в automated guardrails, component tests, performance tests и formatters, которые ловили проблемы на ранней стадии. Code review сместился к проверке interface definitions и architectural decisions, а не к стилю кода и naming conventions.

Что могут сделать технологические лидеры уже сегодня

Не каждая команда добивается таких результатов. Команды, которые пропускают этап построения контекста, воспринимают ИИ как замену без изменений процесса или ждут немедленного эффекта без перестройки работы, стабильно показывают худшие результаты. Разработчики по всей отрасли уже внедрили AI coding tools. Но не все видят рост production-метрик. Проблема не в неправильных инструментах. Проблема в правильных инструментах, встроенных в неправильный workflow.

Главные выводы такие:

1. Измените способ работы, чтобы ИИ мог работать на своём лучшем уровне.
2. Результат дают три фактора, которые усиливают друг друга: ИИ выполняет низкозначимые задачи × непрерывный фокус на высокозначимых задачах × мгновенный доступ к domain expertise.
3. Сначала пилот, потом масштабирование.

Практическая отправная точка — не широкий rollout. Это осознанный pilot. Начните с небольшой команды, которая готова первые недели строить agent context — steering files, шаблоны спецификаций, monorepo — ещё до написания production code. Дайте команде задачу перестроить workflow. Измеряйте commit velocity, deployment frequency и time-to-resolution, а также показатели удовлетворённости разработчиков. Затем используйте выводы как основу playbook для остальной организации.

Команды, которым удаётся получить рост производительности в 4,5x–10x+, не просто внедрили лучшую технологию. Они поняли, как работать с ней по-другому. Это решение доступно сегодня любой инженерной организации. Разумеется, скорость коммитов — только часть истории. Мы хотим помочь и с другими аспектами software development lifecycle: от упрощения release management, operations и security operations до решения EOL upgrades и множества рутинных задач, которые сопровождают software engineering. В следующем блоге я расскажу, как мы подходим к этому.

Узнать больше о frontier teams >

Подключайтесь к AWS Summit New York City, чтобы узнать больше об AI-native development.

Материал — перевод статьи с английского.

Оригинал: How frontier teams are reinventing AI-native development