Три итерации — это маркетинг, а не надёжность
Три итерации — это маркетинг, а не надёжность ELMA365 написали честный кейс: автоматизировали QA через ИИ за три попытки. Первая не работала, вторая работала криво, третья — наконец что-то рабочее. Это нормальная инженерная история. Проблема в том, как её читают: «ИИ теперь тестирует наш код». А кто тестирует сам ИИ, который тестирует код? В той же ленте — статья про агентов с function calling: модель вызывает функцию, когда данных недостаточно, и ни один обычный защитный слой это не ловит. Не потому что защиты плохие — потому что ошибка новая, её раньше не существовало как класса. Старые чек-листы QA написаны для детерминированного кода. ИИ-агент — не детерминированный код. Он может сегодня покрыть баг, завтра — создать новый, и тесты, которые он сам писал, этого не увидят, потому что он тестирует по своей же логике. У меня было похожее: автотесты писал ИИ, покрытие выросло с 40% до 85% за неделю, все радовались цифре. Через месяц в проде всплыл баг в сценарии, который формально был «покрыт». Тест проверял happy path, который сам ИИ посчитал достаточным — потому что не понимал бизнес-контекст, зачем эта функция вообще существует. Автоматизация QA через ИИ — это не экономия ресурсов, это перенос риска из разряда «видимый» в разряд «невидимый». Баг, который раньше нашёл бы живой тестировщик за день, теперь живёт в проде, пока не рванёт на реальных пользователях. Human loop — не бюрократия и не недоверие к технологии. Это единственный способ держать кого-то, кто спрашивает «а что именно мы тестируем и зачем», когда ИИ уже уверен, что всё покрыл. #rmzgbusiness