Выпуск Stack Overflow Podcast от 7 августа зафиксировал неприятный для многих команд факт: ИИ уже ускорил написание кода, но не ускорил проверку и выпуск с той же скоростью. Для разработчиков вывод практичный: новый дефицит теперь не в генерации, а в тестах, валидации и безопасном выпуске.
Об этом в подкасте говорил ведущий Ryan Donovan с McLaren Stanley, Senior Principal Engineer в Amazon Stores. Разговор был не про замену разработчиков, а про более приземлённую вещь: что происходит после роста производительности, когда агентные инструменты начинают писать быстрее, чем команда успевает проверить результат и довести его до рабочей среды.
Цифры Amazon появились раньше подкаста
Основные метрики Amazon раскрыла 10 июня в блоге AWS. Там описаны эксперименты более чем с 50 командами: 25 коллективов, которые поменяли и инструменты, и сам процесс, обошли группы, где ИИ просто встроили в старый порядок работы.
Для Amazon Stores это выглядело так: обычные продуктовые команды работали по своему штатному бэклогу с Kiro и внутренними инструментами. Медианный рост нормализованной скорости выпуска функций составил 4,5 раза, а часть команд превысила 10 раз. Команда Perfect Order Experience стала выпускать функции за полдня вместо двух недель, а WW Grocery сократила подготовку документов по проектированию с пяти дней до нескольких часов.
Самый быстрый код не всегда быстрее доходит до пользователей
В том же материале AWS описала и более жёсткие кейсы. Команда Amazon Bedrock из шести старших инженеров за 76 дней закрыла проект, который раньше оценивали в 30 разработчиков и 12–18 месяцев работы. Нормализованная скорость коммитов выросла примерно в 20 раз: с двух до 40 на человека в неделю.
Команда Prime Video Financial Systems за 10 дней сделала 556 коммитов против базовых 96 и сократила оценку проекта с 90 до 24 недель. Но это не история про волшебный редактор кода. AWS прямо пишет, что выигрыш появлялся там, где команды заранее раскладывали работу на понятные требования, убирали переключение контекста и давали агентам доменные данные.
Узкое место сместилось в проверку и валидацию
Эту мысль подкаст формулирует довольно жёстко: если код генерируется быстрее, чем его успевают проверить, команда получает не ускорение, а очередь из рисков. В февральском материале AWS про оценку агентных систем Amazon перечислила, что именно приходится измерять в реальной среде: точность выбора инструмента, корректность параметров, правильность последовательности вызовов, качество извлечения контекста и склонность к галлюцинациям.
Для регрессии Amazon использует «золотые» наборы данных, собранные из исторических журналов вызовов API, а результаты дополняет выборочной проверкой человеком. Смысл простой: без такого контура ИИ ускоряет не поставку продукта, а накопление тихих ошибок, которые всплывают слишком поздно.
Значение для рынка
Для команд в России и СНГ сигнал вполне прикладной. Покупка ещё одного ИИ-помощника сама по себе не даст 4,5-кратного роста. Рост появляется там, где у команды есть понятные требования, автоматические проверки рядом с генерацией кода, прозрачный контур выпуска и инженеры, которые быстро отличают полезный результат от уверенной ерунды. Проще говоря, следующий раунд конкуренции пойдёт не за то, кто напишет больше кода за ночь, а за то, кто быстрее и безопаснее доведёт изменения до пользователей.
Логичный следующий шаг для рынка — переносить инвестиции с ещё одного генератора кода на тесты, валидацию и процессы доверия. Оригинал подкаста: . Данные Amazon по пилотам: . Подход к оценке агентных систем: .