Проанализировал год работы с ИИ-агентами на рабочих проектах, ищем источник проблем Мне стало интересно не где агент косячит вообще, а где его ошибка проходит тесты, ревью, спокойно доезжает до прода и уже там ломается. Взял свои проекты, которые реально крутятся на серверах. Это около 3400 коммитов за год, 6 проектов, код почти весь писали агенты. Для каждого фикса нашел коммит, который внес баг, проверил, был ли он уже на сервере, и разложил все по причинам. Переделки, где мы сами передумали, типа поменять верстку или убрать функцию, не считал. Осталось 650 настоящих поломок, которые были обнаружены уже после попадания на прод и исправлены (сколько еще осталось спящих проблем, но не всплыло, история умалчивает, поэтому ходим по границе ошибки выжившего) А вот и статистика, ради которой всё анализировалось. Из-за чего ломалось чаще всего: 1️⃣ Сервер не такой, как машина агента. 29% У агента все прогрето: кэш докера, заполненная база, настройки, которые когда-то вбили руками. На чистом сервере фронт стучится на localhost, переменная не прокинулась при сборке, миграция не накатилась. Как избежать: собирать с нуля без кэша, выкатывать на стейдж и прокликивать основное. Сразу в прод не пушить. 2️⃣ Не подумал про нестандартный случай. 14% Список грузит только первую страницу, и пока данных мало, все ок. Первый живой клиент ввел три ИНН, а код ждал один. Как избежать: тестить на объеме как в проде, а не на пяти строках. 3️⃣ Поправил в одном месте, а надо было в пяти. 12% Ввели правило, что каждый видит только данные своей компании, а часть фоновых задач про него не знает и месяцами тихо ничего не делает. Как избежать: в каждом ревью спрашивать, где еще это действует, и искать по всему коду. 4️⃣ Чужой сервис работает не так, как думал агент. 11% Телеграм, внешние API, новые версии библиотек. Агент пишет по памяти, а проверяет уже на проде. Как избежать: сначала руками дернуть настоящий API, потом писать код. Всегда отправлять агента читать свежую документацию, без исключений. 5️⃣ Два процесса одновременно или обрыв на середине. 8% Уведомление ушло дважды, деньги списались после отключения автопродления. Тесты идут в один поток и такого не видят. Как избежать: отдельно проверять параллельные запросы и перезапуск посреди работы. 6️⃣ Ошибка молчит. 6% Пустой catch, выключенный логгер, при падении базы человек видит "неверный пароль" в форме входа а не код ошибки. Такие баги живут около месяца, их просто никто не видит. Как избежать: любой сбой в лог, человеку понятная причина. 7️⃣ В базе лежат данные другой формы. 6% Поменяли формат, а старые записи остались. Одна такая запись роняла целый экран. Как избежать: тестить на копии данных с прода, битую запись пропускать, а не валить всю страницу. По мелочи: косяки в адаптивной верстке 5%, лишние доступы 3,5%, модель внутри продукта ведет себя не так, как рассчитывали, 2,6%, кончились память или диск 2%. Что еще вылезло: В двух самых больших проектах 97% коммитов с багом шли вместе с тестами. Тесты были, просто проверяли не то: на заглушках, на пустой базе, в один поток. Сама выкладка поймала только четверть поломок. Еще по четверти нашел я руками, логи и аудиты. 28% багов сидели в коде, который сам был фиксом, в деплое и интеграциях 40%. Агент часто чинит наугад и ломает дальше. Половина багов приехала в коммитах больше 1500 строк, хотя таких коммитов всего 3-9%. Ревью такой объем не тянет. Так что ревьюим теперь часто и по чуть-чуть. Иначе у агента фокус сбивается. Самые опасные баги тихие. 89 штук нашел только аудит, когда они уже прожили больше месяца. И агент любит писать закрыто, когда закрыл половину. Ловит это только независимое ревью. Что я для себя вынес (базированная база, но буду честен перед самим собой и зафиксирую очевидные вещи): - без стейджа и чистой сборки не выкатывать - в ревью всегда спрашивать, где еще это действует - раз в месяц гонять аудит на тихие баги: логи, гонки, доступы, деньги - тестить на данных как в проде - внешние API сначала пробовать руками - большие изменения дробить - слову готово от агента без независимой проверки не верить