Amazon возложила ответственность за ИИ-код на старших инженеров

Мой друг в Amazon не назвал это сменой политики. Он назвал это «новым ритуалом».

Сказал так, как будто описывал суеверие, которое существует только потому, что уже случилось что-то ужасное.

---

Теперь, прежде чем любой младший или средний инженер отправит изменение, к которому хотя бы прикасался ИИ-инструмент для кодирования, появилось новое требование:

Старший должен подписать.

Не «рекомендуется». Не «лучшая практика».

Гейт.

И причина — та самая, которая всегда создаёт новые гейты в больших технологических компаниях: сбой, который публично опозорил компанию.

5 марта 2026 года сайт и приложение Amazon пережили серьёзный сбой, связанный с развёртыванием программного кода. Пострадали оформление заказов, логин и ценообразование. Пик сообщений на Downdetector составил около 20 000, и Amazon заявила, что проблема была решена позже тем же вечером.

Этот сбой навредил не только клиентам.

Он сделал кое-что похуже внутри компании вроде Amazon:

Он изменил культуру за одну ночь.

---

На следующий день после сбоя никто не спорит. Все подчиняются.

Вот что описал мой друг — не версию «для всех», а настоящую версию:

• Шутки исчезают из Slack.

• Люди перестают использовать слова вроде «быстро» и начинают использовать слова вроде «безопасно».

• У старших инженеров внезапно больше встреч, чем рабочих часов.

• Каждый деплой ощущается так, будто происходит в зале суда.

И потом новая фраза появляется повсюду:

«Нам нужен sign-off».

Звучит разумно, правда?

Проверка старшим инженером — это нормальная инженерная дисциплина.

Но когда вы делаете её специально для ИИ-ассистированного кода, вы тихо признаёте кое-что:

Ваш пайплайн не был построен для скорости машинно-генерируемых изменений.

---

К слову об инструментах. Пока одни корпорации учатся на собственных сбоях, другие могут учиться на чужих. Если вы используете ИИ для кодирования или любых других задач — посмотрите на BotHub.

Для доступа не требуется VPN, можно использовать российскую карту.

По ссылке вы можете получить 300 000 бесплатных токенов ^[1]  для первых задач и приступить к работе с нейросетями прямо сейчас!

---

Это был не один инцидент. Это был паттерн.

Amazon ужесточает контроль не потому, что ненавидит ИИ.

Amazon агрессивно продвигала ИИ-инструменты для кодирования, потому что хотела скорости.

Но множественные отчёты говорят, что e-commerce подразделение Amazon теперь проводит «перезагрузку» безопасности после цепочки серьёзных инцидентов с кодом — включая один, связанный с их ИИ-ассистентом — и внедряет более строгие правила проверки и документирования для критических систем.

Важная деталь — не «ИИ написал плохой код».

Важно, что команды двигались быстрее, чем система безопасности могла обеспечить контроль.

Когда изменения приходят от человека, код-ревью — это раздражение.

Когда изменения приходят со скоростью машины, код-ревью становится бутылочным горлышком.

А бутылочные горлышки создают предсказуемое поведение ^[2] в организациях под высоким давлением:

Люди их обходят.

---

Настоящая проблема — не ИИ-код. Это ИИ-пропускная способность.

Вот неудобная математика ^[3], которую никто не хочет произносить вслух.

Человек пишет код с темпом, который позволяет социальным системам функционировать:

• ревью

• обсуждение

• тестирование

• планирование отката

• колебание «а мы уверены?»

ИИ-инструменты не колеблются.

Они генерируют уверенно.

Они выдают результат мгновенно.

Так что единственный способ поддерживать безопасность — сделать одно из двух:

1. Замедлить пайплайн.

2. Добавить больше ревьюеров.

Amazon выбрала вариант 2 — но с одной особенностью:

Она сконцентрировала ответственность наверху.

Если вы старший инженер, эта политика не ощущается как безопасность.

Она ощущается как перенос ответственности.

Потому что если что-то сломается теперь — все знают, кто это одобрил.

---

Почему это страшно для старших инженеров

Мой друг сказал кое-что, что звучало как шутка, но не было ей:

«Мы становимся человеческой контрольной суммой».

Вот чем становится подпись старшего на практике.

Не менторство.

Не ревью.

Контрольная сумма.

Человек, чья работа — впитывать риск.

И вот ловушка:

Если цель Amazon — скорость, компания не может позволить себе пропускать всё через старших вечно.

Так что старшие становятся бутылочным горлышком.

Потом руководство спрашивает, почему всё медленнее.

Потом старших обвиняют в том, что они «блокируют».

И машина продолжает давить.

Вот так вы получаете организацию, которая одновременно:

• одержима скоростью

• в ужасе от изменений

• и структурно неспособна учиться на инцидентах, потому что стимулы не выровнены

---

«Но разве Amazon уже не требовала двойных одобрений?»

Вот что делает эту историю важной.

В большинстве зрелых организаций критические продакшн-изменения уже требуют ревью.

Но репортажи Business Insider о внутренних изменениях Amazon описывают, как ранние контроли недостаточно последовательно предотвращали серьёзные инциденты — и как Amazon теперь внедряет более строгие практики (одобрения, документация, аудиты) для систем верхнего уровня, обращённых к потребителям.

Что означает: проблема была не в существовании политики.

Проблема была в том, что политика недостаточно строго соблюдалась под давлением.

ИИ-инструменты не изобрели эту слабость.

Они её усилили.

---

Быстрая проверка реальности: даже Amazon оспаривает фрейминг «ИИ виноват»

Amazon публично возразила как минимум одному репортажу, связывающему их внутренний ИИ-инструмент (Kiro) с инцидентом AWS Cost Explorer в конце 2025 года, заявив, что тот инцидент был вызван неправильно настроенными элементами управления доступом и был ограничен по масштабу.

Это важно, потому что подчёркивает реальный смысл:

Это больше, чем «ИИ вызвал сбой».

Это о том, как организации внедряют ИИ быстрее, чем эволюционируют их ограждения.

Даже если конкретный инцидент не был «виной ИИ», давление внедрения и изменения рабочих процессов — всё равно реальны.

---

То, что никто не хочет признавать

Amazon обязала внедрение ИИ-кодирования ради скорости.

Теперь Amazon платит налог за скорость:

• дополнительные одобрения

• дополнительные встречи

• дополнительное трение

• дополнительные операционные накладные расходы

И если отступить на шаг, это именно тот режим отказа, о котором предупреждал Gartner: Gartner прогнозирует, что более 40% проектов агентного ИИ будут отменены к концу 2027 года из-за растущих затрат, неясной ценности или неадекватного контроля рисков.

Amazon не отменяет.

Но она делает следующую самую честную вещь:

Признаёт, что пайплайну снова нужны люди.

---

Что это значит для всех остальных

Если Amazon — компания, построенная на операционной дисциплине — нуждается в гейтах одобрения старших для ИИ-ассистированных изменений…

Как вы думаете, что происходит в компаниях поменьше с:

• более слабой SRE-культурой

• более быстрыми привычками деплоя

• меньшим тестированием

• большим количеством стимулов «выкатить сейчас, починить потом»

Они не учатся этому уроку проактивно.

Они учатся ему дорогим способом.

---

Практический вывод (чтобы это не было просто апокалипсисом)

Если ваша команда использует ИИ-инструменты для кодирования и деплоит в продакшн, вам нужны три правила — не когда-нибудь, а сегодня:

1. ИИ-ассистированный код должен быть помечен в PR.
Если никто не может сказать, какие изменения были затронуты ИИ, вы не сможете провести аудит паттернов после инцидента.

2. Никаких ИИ-генерированных изменений на поверхностях с «радиусом поражения» без второго человека.
Аутентификация, биллинг, ценообразование, роутинг, разрешения, пайплайны деплоя.

3. Сделайте обход ревью сложнее, чем его прохождение.
Если ревью раздражает, но обход лёгок — вы встраиваете сбои в свою культуру.

Amazon делает корпоративную версию этого.

Вам тоже стоит.