Где проходит граница внедрения AI в разработку. Кейс Amazon 🔴
Business Insider пишет об экстренном собрании в Amazon после уже не первого инцидента 5 марта, связанного с AI. Amazon.com лежал порядка 6 часов и потерял 6 млн заказов. Перед этим, 2 марта, в чекауте отображалось неверное время доставки, потери 120 000 заказов. В декабре 2025-го был 13-часовой даунтайм AWS из-за ошибок кодинг-асистента Kiro AI.
По моему каналу, я думаю, видно, что я активно топлю за внедрение AI в процессы разработки, но кейс Amazon является важным маркером.
1. Проблема не только в качестве кода, но и в скорости
AI генерирует код в разы быстрее. Пайплайны ревью и деплоя проектировались под человеческую скорость. Когда объём и скорость изменений резко растут, процессы контроля не успевают.
Либо жертвуешь контролем (и как следствие качеством), не глядя отправляя в продакшен. Либо жертвуешь скоростью, становясь бутылочным горлышком.
Конечно, нужно заниматься harness engineering, выстраивать окружение, которое подсвечивает агентам ошибки, но это не дает полной защиты.
2. Не жертвовать чем-то одним, а разделять на уровни критичности
Какие действия предпринимает Amazon:
• Они не убрали AI-агентов, а разделили сервисы на уровни критичности
• Выделили 335 сервисов уровня Tier-1, у которых высокий «радиус поражения» при выходе из строя
• Для этих сервисов ввели регламент обязательного ревью и одобрения минимум 2х других разработчиков
И это грамотные шаги. Пайплайн критичных сервисов осознанно «замедляем» человеческим ревью. Некритичные сервисы едут со скоростью AI-агентов. Да, может падать и лежать, но может и быстро починиться. Главное, чтобы агенты быстро получали обратную связь, что упало и чинили.
Оптимально, я думаю, иметь три уровня критичности сервисов с соответствующим регламентом:
1. с полным ревью (агент-ревью + ревью всего кода людьми)
2. с быстрым ревью (агент-ревью + по диагонали код)
3. без ревью (только агент-ревью)
3. Сокращения + AI = иногда ложная экономия
Amazon сократил 16 000 человек. AI-инструменты создали иллюзию, что можно компенсировать headcount автоматизацией. Но senior-ы на ревью — это не «накладные расходы», это safety net. Убираешь сетку — и акробат рано или поздно падает. Джеймс Гослинг (создатель Java, ранее distinguished engineer в AWS) прямо говорил, что компания демонтировала команды, которые не генерили выручку напрямую, но были критичны для стабильности.
Я не думаю, что сам процесс сокращений и оптимизации был ошибкой. Это часто оздоравливает и ускоряет команды. Но, похоже, щепок полетело больше, чем надо было.
—
Что по итогу. AI в разработке уже присутствует, и это неизбежно. Но сейчас индустрия проходит фазу адаптации. Появляется понимание, что скорость без контроля — это не только преимущество, но и риск. Это может быть вполне допустимый риск. Главное, это понимать.
🔗 Инженерия и AI | Ilyas Salikhov
Business Insider пишет об экстренном собрании в Amazon после уже не первого инцидента 5 марта, связанного с AI. Amazon.com лежал порядка 6 часов и потерял 6 млн заказов. Перед этим, 2 марта, в чекауте отображалось неверное время доставки, потери 120 000 заказов. В декабре 2025-го был 13-часовой даунтайм AWS из-за ошибок кодинг-асистента Kiro AI.
По моему каналу, я думаю, видно, что я активно топлю за внедрение AI в процессы разработки, но кейс Amazon является важным маркером.
1. Проблема не только в качестве кода, но и в скорости
AI генерирует код в разы быстрее. Пайплайны ревью и деплоя проектировались под человеческую скорость. Когда объём и скорость изменений резко растут, процессы контроля не успевают.
Либо жертвуешь контролем (и как следствие качеством), не глядя отправляя в продакшен. Либо жертвуешь скоростью, становясь бутылочным горлышком.
Конечно, нужно заниматься harness engineering, выстраивать окружение, которое подсвечивает агентам ошибки, но это не дает полной защиты.
2. Не жертвовать чем-то одним, а разделять на уровни критичности
Какие действия предпринимает Amazon:
• Они не убрали AI-агентов, а разделили сервисы на уровни критичности
• Выделили 335 сервисов уровня Tier-1, у которых высокий «радиус поражения» при выходе из строя
• Для этих сервисов ввели регламент обязательного ревью и одобрения минимум 2х других разработчиков
И это грамотные шаги. Пайплайн критичных сервисов осознанно «замедляем» человеческим ревью. Некритичные сервисы едут со скоростью AI-агентов. Да, может падать и лежать, но может и быстро починиться. Главное, чтобы агенты быстро получали обратную связь, что упало и чинили.
Оптимально, я думаю, иметь три уровня критичности сервисов с соответствующим регламентом:
1. с полным ревью (агент-ревью + ревью всего кода людьми)
2. с быстрым ревью (агент-ревью + по диагонали код)
3. без ревью (только агент-ревью)
3. Сокращения + AI = иногда ложная экономия
Amazon сократил 16 000 человек. AI-инструменты создали иллюзию, что можно компенсировать headcount автоматизацией. Но senior-ы на ревью — это не «накладные расходы», это safety net. Убираешь сетку — и акробат рано или поздно падает. Джеймс Гослинг (создатель Java, ранее distinguished engineer в AWS) прямо говорил, что компания демонтировала команды, которые не генерили выручку напрямую, но были критичны для стабильности.
Я не думаю, что сам процесс сокращений и оптимизации был ошибкой. Это часто оздоравливает и ускоряет команды. Но, похоже, щепок полетело больше, чем надо было.
—
Что по итогу. AI в разработке уже присутствует, и это неизбежно. Но сейчас индустрия проходит фазу адаптации. Появляется понимание, что скорость без контроля — это не только преимущество, но и риск. Это может быть вполне допустимый риск. Главное, это понимать.
🔗 Инженерия и AI | Ilyas Salikhov