TL;DR
Если сказать агенту «найди и исправь проблемы в разделе X», он справляется примерно в половине случаев. Если дать ему описание бага, он чинит почти всегда. Узкое место не в починке, а в поиске и узнавании бага: нужно придумать сценарий, прогнать его через интерфейс и понять, что увиденное — ошибка.
Типичная картина: агент дошёл до нужной функции, увидел пустой экран и пошёл дальше. Либо решил «так задумано», потому что существующие юнит-тесты этого и ожидают. Ещё одна находка: без прямой просьбы агент почти не открывает браузер. Он читает код, гоняет команды в терминале и шлёт HTTP-запросы, хотя браузер ему установлен и доступен.
Что делать: прямо писать в инструкции «проверяй приложение в браузере как реальный пользователь», задавать область проверки и давать критерий «как должно работать». Эксперимент в статье подтверждает только первый пункт. Остальное — наблюдения на разборе траекторий. Они указывают, куда смотреть, но как отдельный приём не проверялись.
Схема метода
Воронка, по которой «теряются» агенты (в скобках — доля траекторий, дошедших до стадии, в среднем):
СТАДИЯ 1: дошёл до нужной функции → ~3/4
СТАДИЯ 2: запустил сценарий и УЗНАЛ баг → ~1/2 ← главный провал
СТАДИЯ 3: нашёл первопричину → ~44%
СТАДИЯ 4: починил и ничего не сломал → ~41%
Инструкция агенту, которая следует из выводов:
1. Область: назови раздел продукта (не «баги вообще»)
2. Способ: «тестируй в браузере как реальный пользователь» ← проверено
3. Критерий: что значит «работает правильно» (по смыслу, не по тестам) ← наблюдение
4. Финал: проверь, что соседние функции не сломались ← так судил верификатор
Всё в одном системном промпте или файле инструкций.
Пример применения
Задача: Вы ведёте интернет-магазин на open-source движке, например на Bagisto. Накануне распродажи «11.11» вы хотите, чтобы агент прошёлся по корзине и оформлению заказа. Классическая ошибка такого класса: промокод принимается в корзине, а на оформлении отклоняется. Из кода это не видно, это ловится только сценарием «положил товар, ввёл промокод, дошёл до оплаты».
Промпт (агент с доступом к браузеру, например Claude Code с Playwright):
Найди и исправь проблемы в корзине и оформлении заказа этого магазина.
Тестируй приложение в браузере как реальный покупатель: открой магазин,
добавь товары, примени промокод, дойди до последнего шага оформления.
Не ограничивайся чтением кода и запросами из терминала.
Если на каком-то шаге увиденное расходится с тем, как должно работать
для покупателя (скидка пропала, сумма изменилась, кнопка не реагирует),
считай это багом. Даже если существующие тесты ожидают такое поведение.
Для каждой проблемы: опиши шаги воспроизведения, исправь, затем повтори
сценарий. После правок проверь, что соседние функции (каталог, вход,
список заказов) по-прежнему работают.
Результат: Агент запустит браузер и пройдёт путь покупателя шаг за шагом, а не станет только читать код корзины. В ответе будут описания найденных проблем с шагами воспроизведения, правки кода и повторный прогон сценария. В конце — проверка соседних разделов. Найдёт ли он именно ваш баг, не гарантировано: даже лучшие агенты в исследовании находили чуть больше половины.
Почему это работает
Слабость. Агент по умолчанию выбирает привычный путь: читать код, запускать команды, слать запросы. Браузерный сценарий — длинный (в примере из статьи баг проявляется только после девяти шагов на двух аккаунтах), и сам по себе агент за него не берётся. Даже увидев аномалию, он не всегда считает её багом. Он сверяется с тем, что «ожидают тесты», и принимает неправильное поведение за норму.
Сильная сторона. Когда задача ясна, агент чинит отлично. С описанием бага он решает почти всё, и разница между моделями почти исчезает. Он умеет вести сценарий в браузере, если ему сказали это делать.
Как это использует инструкция. Явное «тестируй как пользователь» переключает агента с чтения кода на проход сценариев, где баги и проявляются. Критерий «как должно быть по смыслу» даёт опору для узнавания ошибки, не завязанную на тесты.
Рычаги: - Область в запросе — чем уже и конкретнее (корзина, а не «весь сайт»), тем больше шансов дойти до нужной функции. - Строка про браузер — убери, и агент вернётся к чтению кода. Модель с 43,5% падала до 31,5%. - Критерий ожидаемого поведения — добавь пример или описание нужного поведения, если оно у тебя есть. Это путь к «детальному промпту», где результат вырос с 35–51% до 96%. - Лимит времени — после примерно 40 минут прироста почти нет, длинные запуски иногда вообще не сходятся.
Шаблон промпта
Дословный промпт авторов (Приложение A) в доступном тексте не приведён. Ниже — сборка по тому, что описано в статье: открытый запрос с областью плюс требование тестировать в браузере.
Найди и исправь проблемы в {область_продукта}.
Тестируй приложение в браузере как реальный {роль_пользователя}.
Не ограничивайся чтением кода и запросами из терминала.
Ожидаемое поведение: {как_должно_работать}.
Если увиденное расходится с этим, считай это багом, даже если
существующие тесты ожидают другое.
Для каждой проблемы: шаги воспроизведения → исправление → повторный
прогон сценария. В конце проверь, что соседние функции не сломались:
{список_соседних_функций}.
Что подставлять:
- {область_продукта} — раздел, например «оформление заказа» или «приглашения в рабочее пространство».
- {роль_пользователя} — покупатель, администратор, приглашённый коллега.
- {как_должно_работать} — две-три фразы о нужном поведении. Строка авторами отдельно не проверялась, это вывод из наблюдений. Если не знаешь, оставь «как ожидает обычный пользователь».
- {список_соседних_функций} — то, что рядом и не должно пострадать.
Ограничения
⚠️ Проверена одна строка: экспериментом подтверждено только влияние инструкции «тестируй в браузере». Эффект в одном случае небольшой (около 2 п.п.), в другом заметный (около 12 п.п.). Остальные пункты шаблона — вывод из разбора траекторий, а не отдельный проверенный приём.
⚠️ Нужен браузер: без доступа агента к запущенному приложению с браузером (Playwright и подобное) инструкция бессмысленна. Это настройка инструмента, одним промптом не обойтись.
⚠️ Даже с подсказкой находят не всё: лучший агент нашёл и починил чуть больше половины багов. Это помощник для проверки перед релизом, а не замена тестировщика.
⚠️ Узкая область проверки: задачи были только про веб-приложения, по одному известному багу. Другие баги, найденные попутно, не оценивались, лишние правки не штрафовались. Дизайн, удобство и скорость не проверялись.
⚠️ Больше ≠ лучше: долгая работа и большое число действий в браузере не связаны с успехом. Прирост от дополнительного времени заканчивается примерно на 40 минутах (на малой выборке, статистически не значимо). Некоторые агенты уходили на часы без результата.
⚠️ Недоверие к тестам — наблюдение: случай «агент поверил юнит-тестам» разобран на одной задаче и четырёх агентах. Это иллюстрация риска, а не измеренная закономерность.
Как исследовали
Исследователи из Принстона взяли 200 реальных исправленных багов в 200 популярных open-source веб-приложениях: Ghost, Uptime Kuma, Focalboard, Stirling-PDF и другие. Агенту давали только код, работающее приложение с браузером и одну фразу вроде «Найди и исправь проблемы в Focalboard: общий доступ к доскам и участники». Ни описания бага, ни подсказок.
Проверял результат не набор юнит-тестов, а агент-верификатор. Он открывал исправленное приложение в браузере, не видя кода, и шёл по пошаговым сценариям: сработало ли целевое поведение и не сломались ли соседние функции. Так принимается любое корректное исправление, а не только совпадающее с эталонным.
Прогнали 15 агентов. Лучший решил 59% задач, девять решили меньше половины. Затем исследователи разобрали траектории по стадиям: добрались до функции, узнали баг, нашли причину, починили. Самый большой провал оказался на узнавании бага, с ~75% до 50%.
Чтобы отделить «найти» от «починить», пяти агентам дали подробный баг-репорт. Результат вырос с 35–51% до 96%, а разница между моделями почти пропала. Ещё одна абляция удивила: когда у двух агентов убрали строку «тестируй в браузере», они почти перестали его открывать (2 и 6 задач из 200). Результат упал с 43,5% до 31,5% у одного и с 42,0% до 39,5% у другого. Дополнительные проверки показали, что работа дольше и больше браузерных действий успех не гарантируют, а подходящая оболочка (harness) даёт умеренный прирост.
Практический вывод: инструкция агенту влияет на то, как он ищет баги, а не только на то, как он их чинит.
Адаптации и экстраполяции
🔧 Техника: добавить регрессионную проверку → ловить побочные поломки
Верификатор в статье требовал, чтобы проходили оба теста: целевой и «сохранения соседнего поведения». В промпте это строка «после правок повтори сценарии из разделов {А, Б, В} и покажи, что они работают». Исправления сами по себе в основном были верными, а вот проверка того, что ничего не поломано, кажется естественным и дешёвым страхом.
Экстраполяция (моя гипотеза, не проверялась): разделить поиск и починку на два запроса. Первый запрос: только искать баги в браузере и выдавать баг-репорты (шаги, ожидаемое и фактическое поведение), код не трогать. Второй: чинить по каждому репорту отдельно. Логика: с готовым репортом агенты чинят в ~96% случаев, а проблема всё в том, чтобы репорт появился.
ЭТАП 1 (только поиск, код не менять):
Пройди в браузере раздел {область} как {роль}. Для каждой аномалии
запиши: шаги, ожидаемое поведение, фактическое поведение.
Выведи список репортов.
ЭТАП 2 (отдельный запрос, по одному репорту):
Вот баг-репорт: {репорт}. Найди причину, исправь, повтори шаги
и проверь соседние функции.
Ресурсы
- SWEeper-Bench: Can Agents Discover Bugs in Interactive Software? Yang Yao, Haozhe Chen, Bingyi Kang, Karthik R. Narasimhan, Zhuang Liu — Принстонский университет.
- Сайт: sweeperbench.com
- Код: github.com/zlab-princeton/sweeper-bench
- Данные: huggingface.co/datasets/zlab-princeton/SWEeper-Bench
- Траектории агентов: huggingface.co/datasets/zlab-princeton/SWEeper-Bench-traces
- Родственные работы, упомянутые в статье: SWE-bench, SWT-Bench, WebProber, Browser Use, инструменты ревью кода (Cursor Bugbot, GitHub Copilot code review, CodeRabbit и др.).