Проанализировал год работы с ИИ-агентами на рабочих проектах, ищем источник проблем
Мне стало интересно не где агент косячит вообще, а где его ошибка проходит тесты, ревью, спокойно доезжает до прода и уже там ломается. Взял свои проекты, которые реально крутятся на серверах. Это около 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 сначала пробовать руками
- большие изменения дробить
- слову готово от агента без независимой проверки не верить
Мне стало интересно не где агент косячит вообще, а где его ошибка проходит тесты, ревью, спокойно доезжает до прода и уже там ломается. Взял свои проекты, которые реально крутятся на серверах. Это около 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 сначала пробовать руками
- большие изменения дробить
- слову готово от агента без независимой проверки не верить