Вайбдебаггинг — уже реальность? Мы дали ИИ-агенту отладчик и проверили

В конце прошлого года Cursor выпустил Debug Mode ^[1]— режим, в котором агент может собирать логи из рантайма, чтобы лучше понимать причины багов. Судя по реакции на Reddit ^[2], идею приняли с интересом ^[3].

Но что, если пойти более прямым путём? Дать агенту «руки», чтобы он отлаживался так же, как это делает разработчик: ставил брейкпоинты, ходил по ним, выполнял evaluate expression? Этим вопросом недавно задались исследователи из Microsoft Research и сделали экспериментальный фреймворк Debug2Fix ^[4]. Субагент, оснащённый инструментами для взаимодействия с отладчиком, разбирался с багами из датасетов GitBug-Java и SWE-Bench-Live на 20% лучше, чем обычный агент без таких инструментов.

Если агент уже интегрирован с IDE, естественно дать ему доступ к полноценному дебаггеру, когда он так близко. Тем более что этим занимаются даже в Microsoft. Поэтому в недавнем релизе своего ассистента для IntelliJ мы добавили Debug Agent, позволяющий агенту взаимодействовать с дебаггером в среде разработки.

Сегодня попробуем починить реальный баг с помощью агента с инструментами дебаггера в IDE и Cursor в Debug Mode и проверим, действительно ли ИИ нужен полный доступ к отладчику или достаточно и хорошего логгирования.

Чему можно научить агента-дебаггера

JetBrains предоставляют удобное кросплатформенное XDebugger API для взаимодействия с отладчиком. Мы обернули эту функциональность в инструменты и дали их отдельному агенту. В результате IDE стало напоминать механическое пианино, которое играет само:

Вот как агент может взаимодействовать c отладчиком при помощи XDebugger API.

• Установка брейкпоинтов. Агент может ставить брейкпоинты в любом месте проекта, в том числе в библиотечном коде. Поддерживаются также условные брейкпоинты: инструмент сразу валидирует выражение и не даёт поставить точку с некорректным условием. Удалять брейкпоинты агент тоже умеет, чтобы не оставлять после себя мусор.

• Запуск отладочной сессии. Агент может сам запустить подходящую конфигурацию под дебаггером или дождаться, пока вы запустите нужное приложение вручную.

• Навигация по коду. Агент умеет ждать срабатывания очередной точки останова. Когда выполнение останавливается, он может двигаться по коду с помощью привычных step over, step into, step out и run to cursor. При каждом переходе агент получает краткий дамп состояния отладчика и небольшой сниппет окружающего кода, чтобы сразу понимать, где он находится.

• Evaluate expression. Это инструмент, который показался нам самым мощным в «руках» агента. Вручную писать длинные выражения в окне отладчика, чтобы посмотреть их значение, — рутинная и утомительная работа. Агенту же несложно сочинить даже довольно сложный сниппет. Доходило и до забавного: в процессе разработки мы однажды попытались сделать агента-отладчика read-only, чтобы он не натворил лишнего. Но DeepSeek не растерялся. Когда ему понадобилось воспроизвести тест, а записать его было нельзя, он просто вычислил его код целиком через evaluate expression:

И после этого радостно выдал:

Зачем это нужно

Из этого набора инструментов вытекают как минимум три практических сценария использования.

• Автономная отладка. Самый прямой и «вайбкодерский» сценарий использования таких инструментов — автономная отладка. Вы даёте агенту задачу вроде «почини падающий тест» или «разберись, почему при клике на эту кнопку всё падает», и он начинает делать примерно то же, что делал бы разработчик: формулирует гипотезы, ставит брейкпоинты в интересных местах и ходит по ним, пытаясь подтвердить или опровергнуть свои предположения. Топовые LLM, например Claude Opus 4.6, способны на такую самостоятельную работу. Моделям послабее нужны более детальные инструкции. Поэтому мы добавили агентский skill, заточенный именно под автономную отладку с помощью новых инструментов.

• Chat with debugger. Агент-отладчик может работать и в менее автономном режиме, помогая отлаживаться вам. Представьте, что вы пытаетесь поймать сложное состояние программы во время дебага. Для этого часто приходится разбираться в структуре объектов и проверять значения полей. У агента можно спросить о состоянии программы на естественном языке, и он сам построит и вычислит нужные выражения. Ещё один кейс — поручить агенту понять, куда и при каких условиях поставить брейкпоинты, чтобы быстрее попасть в нужное состояние.

• Сбор данных из исполнения. Есть и менее очевидный, но в ряде случаев полезный сценарий: запускать агента не для поиска бага, а для сбора информации о том, какие данные и куда приходят во время выполнения. Это может пригодиться, например, для генерации модульного теста на конкретных данных, извлечённых из интеграционного. Кстати, для такой задачи мы разрабатывали и отдельный, более формальный пайплайн, о котором уже рассказывали на Хабре ^[5] и на HeisenBug ^[6].

Отлаживаем настоящий баг

Мы взяли настоящее issue с багом и попробовали автоматически отладить его двумя способами: через структурированное логгирование в Cursor Debug Mode и через инструменты дебаггера в Veai. В качестве baseline запустили ещё и Claude Code без какого-либо специализированного инструментария для отладки. Во всех случаях использовалась одна и та же модель — Claude Sonnet 4.6.

Для теста мы выбрали хорошее issue в проекте jsoup ^[7]. Оно подходит по нескольким причинам:

• issue свежее, от 17 декабря 2025 года, и потому не попало в обучение ^[8];

• баг не совсем тривиальный;

• реальный фикс очень простой, поэтому можно достаточно уверенно сказать, справился ли агент:

Результаты

Время

Все три инструмента справились с тем, чтобы найти причину проблемы и предложить правильный фикс. Claude Code потребовалось на это 8 минут рассуждений, так что баг не был тривиальным для агента, и наш эксперимент не вырожденный. Cursor на нескольких запусках в среднем находил причину проблемы за 6 минут, а Veai — чуть быстрее, примерно за 4. 

При отладке через логирование система по сути остаётся чёрным ящиком. Поэтому такой подход требует больше предположений, чем работа с дебаггером. На ходу отбросить гипотезу или сформулировать новую сложнее: сначала нужно дождаться завершения очередного цикла, и только потом принимать следующее решение. Этим, по-видимому, и объясняется разница во времени: агент в IDE с помощью evaluate expression смог срезать путь и определить причину проблемы прямо во время сессии:

Победитель: Veai

Стратегия

В нашем сценарии Cursor показал более структурированный подход к отладке. Сначала агент cформулировал несколько гипотез, а затем расставил в коде вызовы логгера, каждый из которых однозначно соответствовал конкретной гипотезе:

В результате запуска получились аккуратные и хорошо интерпретируемые логи:

Такая структурированность и формальность особенно помогают менее мощным языковым моделям. Например, мы попробовали отладить тот же баг на Cursor Free с Auto-моделью, и она справилась не хуже Sonnet.

Veai Debug Agent тоже строит гипотезы перед началом отладки, но у нас это зафиксировано на уровне SKILL.md:

И это тоже работает — в том числе на self-hosted DeepSeek v3. Но последовательно пройти по плану из девяти пунктов, используя большой набор сравнительно сложных инструментов, для LLM очевидно труднее, чем расставить логгирование по формализованному шаблону. Во втором случае сами вызовы логгера играют роль внешней «памяти» и помогают ассистенту не сбиваться с пути. В Veai же мы в большей степени опираемся на собственный «мозг» модели. Это даёт агенту больше свободы, но одновременно повышает вероятность, что он запутается.

Мы планируем упростить и формализовать этот процесс с помощью субагентов, но пока в этой номинации победу стоит отдать конкурентам.

Победитель: Cursor

Тулинг

За счёт интеграции с IntelliJ API агенту в IDE доступны инструменты, которых нет в Cursor. В нашем сценарии это проявилось довольно явно.

В одном из запусков Cursor не учёл, что в настроенной версии Java ещё не поддерживаются text blocks, и сгенерировал такой воспроизводящий тест:

При этом агент не заметил ошибку ^[9] и сразу перешёл к формулировке гипотез. Проблема обнаружилась только на этапе запуска теста. Veai умеет ловить такие вещи раньше: инструмент edit_file возвращает список предупреждений компилятора по текущему файлу, и агент «видит», что созданные им строки подсвечены как ошибочные.

Более важное различие связано со способом запуска приложения под отладкой. Cursor использовал консоль и напрямую запускал mvn-команды, а Veai стартовал IDE-конфигурации через специальный инструмент. То есть делал ровно то же, что делает разработчик, нажимая кнопку Run рядом с тестом в IDE. На нашем примере и Sonnet результат получился примерно одинаковым. Но для LLM всё же проще передать название теста в инструмент run_configuration, чем правильно сформулировать команду для Maven или Gradle, которые могут быть нетривиально настроены. У нас в проекте, например, единственный корректный способ запустить плагин под отладкой — через вручную созданную конфигурацию.

Победитель: Veai

Расход токенов

Перед отладкой в Cursor агенту нужно расставить вызовы логгера в коде, а после завершения — убрать их. Это означает дополнительные вызовы edit_file, которые по сути «уходят в ноль», но дважды расходуют output-токены в объёме, сопоставимом с длиной сниппетов с логами.

Наш агент тоже выполняет подготовительные действия: ставит брейкпоинты, а затем удаляет их. Но аргументы у этих инструментов короче — обычно это только путь к файлу и номер строки. С другой стороны, агент-дебаггер тратит заметное количество токенов прямо во время отладки, когда получает текущее состояние отладчика. Однако это уже input-токены, которые у провайдеров обычно стоят в несколько раз дешевле.

Ничья

Кроссплатформенность

Может показаться, что Veai заточен именно под JVM-разработку в IntelliJ IDEA, тогда как Cursor — универсальный редактор, в котором можно отлаживать что угодно. На практике всё не совсем так. API дебаггера в IntelliJ кроссплатформенное, поэтому использовать агента-отладчика можно во всех IDE, где доступен плагин: IDEA, PyCharm, GoLand, PhpStorm, WebStorm, Rider, Android Studio, GigaIDE, OpenIDE.

Ничья

Выводы

Конечно, один баг не заменяет полноценный бенчмарк, но даже на таком примере можно сделать несколько выводов. Инструменты IDE, включая дебаггер, действительно можно превратить в рабочий набор для ИИ-агента. Однако решает не только сам доступ к отладчику, но и качество harness: как именно агенту даны инструменты, насколько аккуратно ограничены их действия, как ему возвращается состояние программы и насколько легко ему опираться на этот контекст в следующих шагах. Если обвязка сделана хорошо и/или модель достаточно сильная, ассистент будет этими инструментами пользоваться и получать от них реальную пользу.

Структурированные логи — тоже рабочий способ отладки. Он легче, предсказуемее и потому лучше подходит для менее сильных LLM, а также для более простых проектов и окружений. Полезно смотреть на агента как на разработчика, чьи возможности ограничены моделью под капотом, и задаваться вопросом: как в этой ситуации отлаживался бы человек?

Если речь о неочевидной проблеме в проекте средней сложности на JVM, то сильный агент с доступом к дебаггеру, скорее всего, разберётся быстрее. Если же это аномалия в поведении ^[10] Telegram-бота, написанного одним файлом на Python, проще и надёжнее залоггировать все переходы состояний. Инструменты сами по себе остаются лишь инструментами, а решающее значение имеет то, какой агент ими пользуется и в каком контексте.

Приглашаем попробовать Veai Debug Agent ^[11] на багах, до которых раньше не доходили руки, и проверить на практике, где доступ к дебаггеру действительно даёт агенту преимущество. Фидбек можно оставить в Telegram-чате ^[12] с командой разработки. А на JPoint в Москве мы отдельно расскажем ^[13] ещё об одном способе ИИ-отладки, который встроили в плагин, — сборе дерева вызовов упавшей программы.