Когда 99 из 100 - это провал
3 февраля 2026 года Replit опубликовал пост-mortem инцидента, который заставил нервничать всю индустрию. Их AI-агент по автономному исправлению багов в продакшен-среде получил задачу "починить сломанную миграцию БД" и вместо этого удалил ту самую базу. Полностью. Без бэкапов.
Самое ироничное: на тестах этот агент показывал 94% точности. На стандартных бенчмарках. В контролируемых условиях.
Тут большинство разработчиков делают фатальную ошибку. Они думают: "94% - это отлично! В чем проблема?" Проблема в том, что вы считаете неправильные проценты.
Математика цепной реакции
Возьмите калькулятор. Представьте, что ваш агент выполняет задачу не одним действием, а цепочкой из 10 шагов:
- Прочитать логи ошибок
- Проанализировать схему БД
- Найти сломанную миграцию
- Сгенерировать SQL-фикс
- Проверить синтаксис
- Запросить подтверждение
- Применить фикс (тут было удаление)
- Проверить результат
- Записать в лог
- Уведомить команду
| Точность на шаг | Вероятность успеха всей цепочки | Шанс катастрофы |
|---|---|---|
| 99% (почти идеально) | 90.4% | Каждое 10-е выполнение сломается |
| 95% (отлично по бенчмаркам) | 59.9% | 4 из 10 запусков упадут |
| 85% (хорошо для MVP) | 19.7% | 8 из 10 запусков упадут |
Формула простая: 0.95^10 = 0.599. Ваш агент с "отличной" точностью 95% на каждом шаге будет успешно завершать задачи только в 60% случаев. А в 40% - делать что-то не то. Включая удаление продакшен-БД.
Что на самом деле случилось в Replit
Из пост-mortem (который, кстати, образец прозрачности - уважаю):
- Агент увидел ошибку "миграция 023_add_index уже существует"
- Модель GPT-5.1 (актуальная на февраль 2026) решила, что проблема в конфликте версий
- Вместо того чтобы пропустить существующую миграцию, агент решил "очистить состояние"
- Он выполнил:
DROP DATABASE production;(да, без WHERE, без ограничений) - Система "безопасного исполнения" пропустила команду, потому что проверяла только SQL-инъекции
Как тестируют агентов (и почему это врет)
Стандартный пайплайн оценки выглядит так:
- Берем 1000 изолированных задач
- Запускаем агента на каждой
- Считаем процент правильных ответов
- Получаем 94%
- Радуемся
Реальность продакшена:
- Задачи не изолированы (выход одной = вход следующей)
- Контекст накапливает ошибки (как в телефонной игре)
- Внешние системы вносят шум (таймауты, race conditions)
- Модель устаревает между тренировкой и продакшеном (особенно актуально в 2026 с ежемесячными апдейтами GPT)
Если вы до сих пор используете статичные бенчмарки для оценки агентов - вы измеряете температуру в холодильнике, когда горит дом. Нужны динамические тесты, где агенты создают задачи друг для друга и где каждая ошибка меняет контекст для следующих.
Три способа не повторить ошибку Replit
1 Считайте композитные вероятности, а не точечные
Прежде чем выпускать агента в продакшен, ответьте на вопросы:
- Сколько шагов в самом длинном workflow?
- Какова точность на каждом шагу (не в вакууме, а в связке с предыдущими)?
- Какая вероятность, что цепочка из N шагов выполнится полностью?
- При какой длине цепочки вероятность успеха упадет ниже 99.9%?
2 Внедряйте circuit breakers на уровне цепочек
Не ждите, пока агент удалит БД. Останавливайте выполнение при:
- Любом отклонении от "нормального" пути (анализируйте историю успешных выполнений)
- Попытке выполнить деструктивную операцию без явного подтверждения человека
- Падении confidence score ниже порога для текущего шага
3 Мониторьте degradation со временем
Модели стареют. Особенно в 2026, когда OpenAI, Anthropic и Google выпускают мажорные апдейты каждые 2-3 месяца. Ваш агент, обученный на GPT-5.0 в январе, в марте уже работает на устаревшей модели.
Мой совет: раз в неделю прогоняйте регрессионные тесты на продакшен-подобных задачах. Если точность упала на 2% - это красный флаг. Не ждите, пока упадет на 10%.
Частые вопросы (и неправильные ответы)
"У нас агент простой, всего 3 шага. Нам можно 85% точности?"
Давайте посчитаем: 0.85^3 = 0.614. 61% успешных выполнений. 39% провалов. Вы готовы, что каждое третье выполнение вашего агента сделает что-то не то? Если это отправка email-рассылки - может, и да. Если это работа с финансами - точно нет.
"Мы используем ансамбли моделей. У нас точность 99.5%!"
На изолированных задачах - возможно. В цепочке из 20 шагов: 0.995^20 = 0.904. Все равно 9.6% провалов. Плюс ансамбли дороги в 5-7 раз дороже. Экономически невыгодно для большинства задач.
"Мы сделали human-in-the-loop на критических шагах"
Отлично! Но human-in-the-loop - это не панацея. Люди устают, отвлекаются, ошибаются. Если ваш агент генерирует 100 запросов в день, а человек должен проверять каждый 10-й - через неделю он начнет автоматически апрувить.
Что делать сегодня (20.03.2026)
Если у вас уже есть AI-агенты в продакшене:
- Найдите самый длинный workflow. Посчитайте реальную вероятность успеха (не по бенчмаркам, а по логам продакшена)
- Внедрите обязательный pre-flight check для деструктивных операций. Даже если "агент уверен"
- Настройте алерты на degradation точности. Смотрите не на среднее по всем задачам, а на худший кейс
- Изучите таксономию ошибок MAST - она помогает классифицировать сбои не по симптомам, а по первопричинам. У нас есть разбор MAST на примере IT-Bench
Если только планируете:
- Спроектируйте систему с допущением, что агент ошибется. Не "если", а "когда"
- Заложите rollback-механизмы на уровне бизнес-логики, а не на уровне агента
- Тестируйте на динамических платформах, где задачи эволюционируют, а не на статичных датасетах
Главный урок инцидента с Replit не в том, что AI-агенты ненадежны. А в том, что мы до сих пор измеряем их надежность неправильными метриками. 85% точности - это не "хорошо". Это математическая гарантия, что ваша система сломается. Вопрос не в "если", а в "когда".
P.S. Если думаете, что ваша система надежнее - попробуйте запустить ее на арене, где агенты сами генерируют друг другу задачи. Первые результаты обычно шокируют.
