Cursor y Microsoft Research Prueban si los Agentes de IA Necesitan Acceso Completo al Depurador

ИИ-агенту для починки багов уже мало просто читать код и собирать логи: когда у него появляется доступ к настоящему дебаггеру, он начинает действовать ближе к живому разработчику и заметно лучше понимает, где именно ломается программа. В конце 2025 года Cursor выпустил Debug Mode — режим, в котором агент может собирать логи прямо из рантайма и использовать их как дополнительный источник контекста. Для практической отладки это важный шаг: вместо догадок по стэктрейсам модель видит, что происходит в момент выполнения, какие значения проходят через функции и в какой точке система ведёт себя не так, как ожидалось.

Такой подход оказался интуитивно понятным и разработчикам: по реакции сообщества стало видно, что идея воспринимается не как очередной маркетинговый режим, а как реально полезный инструмент для повседневной работы с багами. Но логирование — не единственный способ приблизить ИИ к нормальной инженерной практике. Следующий вопрос звучит ещё прямее: если агент уже живёт рядом с IDE, почему бы не дать ему те же инструменты, которыми пользуется человек?

Речь о брейкпоинтах, пошаговом выполнении, просмотре состояния программы и evaluate expression в нужной строке. Именно это проверили исследователи Microsoft Research в экспериментальном фреймворке Debug2Fix. В их постановке отдельный субагент получил инструменты для взаимодействия с отладчиком и на задачах из GitBug-Java и SWE-Bench-Live справлялся с багами примерно на 20% лучше, чем обычный агент без такого доступа.

Это не косметическое улучшение: для задач автоматического исправления кода такая разница уже меняет практическую ценность инструмента. Идея понятна. Логи почти всегда помогают увидеть симптомы, но дебаггер позволяет добраться до механики сбоя.

Агент может не просто прочитать, что значение оказалось неверным, а проследить, в какой момент оно стало неверным, какая ветка условия сработала, что лежит в объектах прямо сейчас и как поведёт себя выражение при проверке гипотезы на месте. По сути, модель получает не только наблюдение, но и управляемый эксперимент. Для отладки сложных состояний, гонок, неожиданных null-значений или ошибок бизнес-логики это может быть критично, потому что именно здесь статического анализа и даже подробных логов часто не хватает.

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

Сценарий получается почти человеческий: агент запускает программу, останавливается в нужной точке, смотрит состояние, проверяет гипотезу и только потом предлагает исправление. Это важное отличие от подхода, где модель в основном опирается на логгирование и косвенные признаки проблемы. Самое интересное в этой истории — не только прирост качества на бенчмарках, но и сама постановка вопроса: что полезнее для ИИ-разработчика будущего, хороший доступ к runtime-логам или настоящие «руки» внутри отладчика?

Полного ответа в одном эксперименте пока нет, но уже видно, что рынок движется сразу по двум направлениям. Один путь делает ставку на качественное наблюдение за выполнением программы, другой — на активное вмешательство в процесс отладки. Если второй подход подтвердит преимущество на большем числе реальных кейсов, AI coding assistants быстро перестанут быть просто умными автодополнителями и превратятся в полноценных напарников, которые умеют не только писать код, но и методично докапываться до корня бага.