Мой друг в Amazon не назвал это сменой политики. Он назвал это «новым ритуалом».
Сказал так, будто описывал суеверие, которое существует только потому, что уже произошло что-то ужасное.
Теперь, прежде чем младший или средний инженер отправит изменение, к которому хотя бы прикасался ИИ-инструмент, появилось новое требование:
Старший инженер должен подписать.
Не «рекомендуется». Не «лучшая практика».
Причина — та же, что всегда порождает новые барьеры в крупных технологических компаниях: сбой, который публично опозорил компанию.
Сбой, который изменил культуру
5 марта 2026 года сайт и приложение Amazon пережили серьёзный сбой из-за развёртывания кода. Пострадали оформление заказов, вход в аккаунт и ценообразование. Пик сообщений на Downdetector достиг 20 000. Amazon заявила, что проблема была устранена позже тем же вечером.
Этот сбой навредил не только клиентам. Он изменил внутреннюю культуру — за одну ночь.
На следующий день — тишина и контроль
Вот как это выглядит изнутри:
- Шутки исчезли из Slack.
- Люди перестали говорить «быстро» и начали говорить «безопасно».
- У старших инженеров больше встреч, чем рабочих часов.
- Каждый деплой ощущается как судебное заседание.
И повсюду появляется одна фраза:
«Нам нужен sign-off».
Звучит разумно. Проверка старшим — нормальная инженерная практика. Но когда она вводится специально для ИИ-ассистированного кода, это тихое признание:
Ваша система не была рассчитана на скорость машинных изменений.
Это был не один инцидент — это паттерн
Amazon ужесточает контроль не потому, что ненавидит ИИ. Компания агрессивно внедряла ИИ-инструменты ради скорости.
Но теперь подразделение e-commerce проводит «перезагрузку безопасности» после цепочки серьёзных инцидентов — включая один, связанный с их ИИ-ассистентом. Вводятся строгие правила проверки и документирования для критических систем.
Важно не то, что «ИИ написал плохой код». Важно, что команды двигались быстрее, чем система безопасности могла контролировать.
Когда изменения исходят от человека, код-ревью — раздражение. Когда они приходят со скоростью машины — ревью становится бутылочным горлышком.
А бутылочные горлышки в условиях давления ведут к одному: люди их обходят.
Проблема — не ИИ-код, а ИИ-пропускная способность
Вот неудобная правда: человек пишет код с темпом, который позволяет работать социальным системам — ревью, обсуждения, тестирование, планирование отката, сомнения.
ИИ не сомневается. Он генерирует уверенно и мгновенно.
Чтобы сохранить безопасность, нужно сделать одно из двух:
- Замедлить пайплайн.
- Добавить больше ревьюеров.
Amazon выбрала второй путь — но с нюансом: ответственность сконцентрирована наверху.
Для старших инженеров это не безопасность. Это перенос ответственности. Если что-то сломается — все будут знать, кто это одобрил.
Почему это страшно для старших инженеров
Мой друг сказал фразу, звучавшую как шутка, но не бывшую таковой:
«Мы становимся человеческой контрольной суммой».
Подпись старшего — не менторство. Это механизм, поглощающий риск.
И вот ловушка: если цель — скорость, компания не может вечно пропускать всё через старших. Они становятся бутылочным горлышком. Потом руководство спрашивает, почему всё медленно. Потом обвиняют старших в «блокировке». А машина продолжает давить.
Так появляется организация, которая одновременно:
- одержима скоростью
- в ужасе от изменений
- и структурно неспособна учиться на инцидентах из-за несогласованных стимулов
Проблема не в отсутствии правил — в их соблюдении
В зрелых компаниях критические изменения и раньше требовали ревью. Но, как пишет Business Insider, внутренние контроли в Amazon недостаточно последовательно предотвращали инциденты.
Теперь вводятся более строгие практики — одобрения, документирование, аудиты — для систем, обращённых к пользователям.
Проблема была не в отсутствии политики. Проблема — в том, что под давлением её не соблюдали.
ИИ не изобрёл эту слабость. Он её усилил.
Даже Amazon оспаривает тезис «ИИ виноват»
Компания опровергла сообщения, связывающие их внутренний ИИ-инструмент Kiro с инцидентом в AWS Cost Explorer в конце 2025 года. По их словам, проблема была в неправильных настройках доступа и ограничена по масштабу.
Это важно: дело не в том, что «ИИ вызвал сбой». Дело в том, что организации внедряют ИИ быстрее, чем эволюционируют их системы контроля.
Даже если ИИ не был прямой причиной, давление, которое он создаёт на процессы, — реальное.
То, что никто не хочет признавать
Amazon внедряла ИИ ради скорости. Теперь она платит налог за эту скорость:
- дополнительные одобрения
- дополнительные встречи
- дополнительное трение
- дополнительные операционные расходы
Это именно тот режим отказа, о котором предупреждал Gartner: более 40% проектов агентного ИИ будут отменены к концу 2027 года из-за растущих затрат, неясной ценности или неадекватного контроля рисков.
Amazon не отменяет проекты. Но делает кое-что более честное — признаёт: пайплайну снова нужны люди.
Что это значит для других компаний
Если Amazon, компания с высокой операционной дисциплиной, вводит гейты одобрения для ИИ-изменений…
Что происходит в компаниях поменьше:
- с более слабой SRE-культурой
- с привычкой быстро деплоить
- с меньшим тестированием
- с сильными стимулами «выкатить сейчас, починить потом»
Они не учатся проактивно. Они учатся дорогим способом.
Практический вывод
Если ваша команда использует ИИ для кодирования и деплоит в продакшн — введите три правила уже сегодня:
- Помечайте ИИ-ассистированный код в PR. Если нельзя определить, какие изменения затронул ИИ, вы не сможете проанализировать паттерны после сбоя.
- Никаких ИИ-изменений на критических поверхностях без второго человека. Аутентификация, биллинг, ценообразование, роутинг, разрешения, пайплайны деплоя.
- Сделайте обход ревью сложнее, чем его прохождение. Если ревью раздражает, а обход — прост — вы закладываете сбои в культуру.
Amazon делает корпоративную версию этого. Вам тоже стоит.