AI-агент действительно ловит баги? Пусть докажет на бенчмарке

[Yankee2d]

Ошибка в методологии - тесты белок по искусности бегать в колесе совсем не факт, что дают ориентир по их способности лазать по деревьям. На маленьком проекте разница между конфигами агентов может быть в 5% токенов, а на большом проекте эта же разница вырастает в 100 раз.

Также вырванный из общего контекста модуль вроде бы может иметь кучу «багов», но по факту в общей картине они никогда не выстрелят. Та же проблема с security или cross scripting - нет никакого смысла иногда решать её в каждом модуле, если продукт стоит за waf.

проблема сложных инженерных задач в том, что у вас нет надёжного способа оценить инструментарий кроме как «разведкой боем». А на альтернативные попытки уже нет времени, средств и «токенов». Кладбище тесткейсов не всегда делает проект лучше и надежнее, зачастую просто делает его дороже сопровождаемым на постоянную адаптацию тесткейсов при изменении логики. К тому же, в тесткейсе также можно ошибиться.

В выводе вы, конечно, правы - имея одну и ту же «силу мозга» можно решать задачи более успешно или менее успешно в зависимости от архитектуры процесса анализа и исправлений. Но в целом нет универсальной «обвязки» под все задачи, иначе её бы уже ии выучил в базе и без обвязки решал бы задачу не хуже.

По сути все обвязки, какие вы делаете направлены в той или иной форме на перепроверку себя и трату токенов - вы говорите ии «думай больше! Разбей на шаги! Отдельно поработай с требованиями! Отдельно сравни требования с юзкейсами! Отдельно сделай тесты и посмотри как работают! Всё запиши!». При этом решаете задачу нахождения оптимума по затратам токенов/времени, типа «пиши тесты, но без фанатизма! А то тестов будет в 5 раз больше, а ошибок найдёшь на 5% больше, не надо нам такого!». А в каждом проекте эта точка оптимума своя. Нужно ещё доказать, что результаты работы в песочнице можно натянуть на глобус реального проекта. Себя успокоить этими табличками можно, конечно.

[spoon03]

Про методологию и «разведку боем». Согласен полностью: любой бенчмарк — это синтетика, и переносить выводы с песочницы на реальный проект 1:1 нельзя. В статье я как раз поэтому упомянул оба сценария оценки: (1) анализ реальности на живых проектах и (2) бенчмарк на фиксированной песочнице. Они не взаимозаменяемы, а дополняют друг друга. Бенчмарк нужен для быстрых решений «эта правка промта/пайплайна сделала хуже или лучше» — там, где ждать накопления статистики на бою месяцами просто нельзя, потому что к тому моменту версия агента уже устареет. А реальный эффект всё равно меряется в бою — по-другому никак, тут вы абсолютно правы.

Про контекст и обесцененные «баги» (WAF и т.п.). Это очень верное замечание, и оно по сути упирается в более общую вещь: у каждого проекта должна быть своя стратегия тестирования — свой набор видов и типов проверок, свои приоритеты, свои исключения. И у оператора агента должна быть возможность это сконфигурировать: «security на уровне модуля не гоняем, потому что стоит WAF», «a11y не критично», «вот тут фокус на performance» и т.д. Сейчас я отлаживаюсь на узком скоупе, поэтому острой потребности в такой настройке нет — но если смотреть чуть шире, это однозначно необходимая фича, и в roadmap она уже маячит.

Про «кладбище тест-кейсов». Тоже больная тема. У меня уже есть проблема «огромного количества» автотестов — на одну фичу спокойно выкатывается под сотню тестов, и сопровождать это становится дорого. Пока я закрываю это избыточностью по пирамиде (отсюда test-requirements-optimizer и редандси-репорты, про которые писал в статье) — то есть стараюсь резать дубли между уровнями ещё на стадии генерации. Но это полумера, тут есть куда копать дальше: и в сторону приоритизации, и в сторону «умного» сокращения регресса.

Про отсутствие универсальной обвязки. Тут не соглашусь только с формулировкой, а по сути — да. Изначальная идея QA Assist как раз и закладывалась как максимально гибкая обвязка, которая адаптируется под разные стеки, разные тестовые стратегии и разные процессы команды. Не «один пайплайн на всех», а конструктор из скиллов, которые можно включать, выключать и настраивать под проект. Согласен, что серебряной пули нет — иначе её бы уже встроили в саму модель. Но за счёт изолированности скиллов хотя бы есть шанс не превращать настройку в редактирование одной мегапростыни промта.