Каждый пост про ИИ магнитом притягивает десятки странных чуваков с одной и той же мыслью: вот однажды ваше навайбкоженное упадёт в проде — и тогда…
Что «тогда»? Я честно говоря не могу понять. И тогда мы выкинем ИИ и на коленях будем умолять вас разобраться? Сомнительно.
Это ведь и есть вся угроза целиком. Не аргумент, а многоточие. За ним предполагается апокалипсис такой силы, что его даже проговаривать не надо — само страшно. Так вот, давайте проговорим. Возьмём это «тогда» и разложим на конкретные действия — по масштабу конторы, которой не повезло уронить прод.
Ентерпрайз: у них что-нибудь да падает ежедневно
В ентерпрайзе обычно есть on-call, runbook и процедура инцидентов; если их нет, падение превращается не в “апокалипсис”, а в организационный баг. Критикал-баг сначала локализуют: откат, feature flag, hotfix или временное отключение сценария — уже потом разбирают, писал его ИИ или человек. Если инцидент затронул клиентов, саппорт или аккаунты отправят статус-апдейт по шаблону инцидента. При нарушении SLA включаются компенсации из договора: кредиты, скидки или другой заранее описанный механизм. После постмортема корневую причину стоит превратить в проверку: автотест, eval-кейс, правило линтера или пункт runbook’а.
Вот эта последняя часть — где инцидент затвердевает в reference-кейс — и есть весь смысл. Хороший исход постмортема — добавить минимальный воспроизводимый кейс в eval-харнес или тесты, чтобы этот же сценарий больше не проходил незамеченным. Если eval действительно встроен в CI/CD как blocking check, он остановит повторение того же класса ошибки. Это реальный failure mode, но он не уникален для ИИ: непокрытые сценарии и раньше становились материалом для новых тестов и правил. Так процесс улучшения получает новые проверочные кейсы.
Для зрелой инженерной команды это штатная процедура инцидент-менеджмента. В большой компании что-нибудь да падает ежедневно — и до всякого ИИ падало.
Малый бизнес: они «падали» руками десятки лет
В малом бизнесе владелец или подрядчик часто начинает с простого шага: копирует ошибку и логи в ассистента, чтобы получить гипотезу фикса. Ассистент может предложить фикс и краткий разбор причины; дальше человек или пайплайн должны проверить diff, прогнать тесты и задеплоить. Память агента может снизить шанс повторить тот же промах, но надёжнее дублировать это в тестах, чеклистах и ограничениях пайплайна. Файлы с решениями и ошибками полезны, если агент реально читает их перед изменениями, а команда проверяет, что правило сработало. На практике остаются проверки: не сломал ли фикс соседний сценарий, прошёл ли деплой и не вернулась ли ошибка.
Для многих SMB исправление прода и раньше было ручным: логи, подрядчик, быстрый hotfix и надежда, что рядом ничего не отвалится. Им к косякам на проде не привыкать — они годами зависели от перегруженных подрядчиков, случайных фрилансеров или одного внутреннего разработчика без нормального процесса. Разница ровно одна: раньше починку ждали от человека, у которого выходной, отпуск и своё настроение. Теперь первый разбор можно поручить ассистенту: он не ждёт рабочего дня, но его фикс всё равно надо проверять.
Продвинутый: Клод сам схавает логи и катнёт фикс
В одном из моих кейсов пайплайн устроен так: ассистент читает логи, готовит patch, прогоняет проверки и деплоит только при зелёных тестах.
Речь не о лозунге “50 деплоев в день”, а о том, что частые маленькие релизы проще откатывать и проверять. В этом конкретном проекте метрика такая: 10–15 деплоев в день в течение полугода: этот подопечный переписал десятилетнюю кодовую базу с ИИ; за полгода при 10–15 деплоях в день не было прод-инцидентов уровня X/Y — цикл “задача → diff → тесты → деплой” у него занимает около получаса. Полгода без падений не доказывают, что падений не будет; это лишь показывает, что сценарий “ИИ сразу уронит прод” не обязателен.
В этом кейсе главный страх не подтвердился: автоматизация ускорила диагностику и выпуск фиксов: система, где диагностика, patch и деплой занимают минуты, а не часы ожидания человека.
Так в чём, собственно, «тогда»
На разных масштабах падение прода разбирается по-разному, но почти всегда сводится к процедуре: обнаружить, ограничить ущерб, откатить или исправить, добавить защиту от повтора. Страх преувеличен, если его формулируют как безымянное “и тогда…”, а не как конкретные failure modes: потеря данных, простой, SLA, безопасность: он держится на неразобранном сценарии: что именно упало, кто заметил, какой есть откат и сколько стоит простой.
Если критики имеют в виду конкретный риск, его надо назвать: потеря данных, security breach, простой кассы, сломанный биллинг или нарушение SLA. Без конкретного сценария “а если упадёт прод” остаётся не аргументом, а страшилкой.