Потихоньку собираю себе вменяемый workflow для дебага реальных проектов с помощью AI. Генерация кода с нуля работает неплохо, этим уже никого не удивить. В интернете полно кейсов, где LLM по одному промпту клепает игру или веб-сервис, но что-то никто не хвастается, что с одного промпта пофиксили все баги в проекте.

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

Инструменты

Сейчас у меня всё заточено под веб-разработку. Проект на Laravel, часть покрыта тестами, часть — нет. В базовом сценарии, конечно, можно обойтись только одним инструментом — дать доступ к запуску команд в терминале. С этим уже можно что-то полезное сделать и задебажить, но, скажем, будет не очень удобно управлять браузером, например, или править файлы. Нейронка, скорее всего, будет изобретать велосипеды и тратить время. Поэтому подключаем дополнительные инструменты, но только минимальный набор, который действительно будет полезен.

Например, для отладки веб-приложения пригодятся штуки типа:

• управление браузером (через puppeteer/playwright)
  • открытие страниц
  • чтение логов из консоли
  • скриншоты (иногда полезнее и быстрее, чем парсинг DOM)
  • выполнение JS (жать кнопки, парсить содержимое, любые другие действия)
• поиск в интернете
  • сбор ссылок по запросу
  • просмотр содержимого по ссылке
• работа с файлами
  • правки, создание, удаление
  • просмотр файлов
• выполнение команд в терминале

Все это подключается через MCP в Claude Desktop, Claude Code, Cursor, VS Code и т.д. Для JetBrains я пока не видел, но, думаю, скоро будет.

Из прикольного: можно дать нейронке команду использовать GitHub CLI и получить таску из определенного issue. Например, “поправь баг из issue #123”. Ну или из любого другого трекера.

Цикл с обратной связью

Задача сводится к тому, чтобы заставить нейронку делать все то, что я и так делаю вручную:

• выполнить шаги, которые вызывают баг
• убедиться, что баг есть
• что-то полезное сделать
• повторить

Для первой итерации я обычно прошу ничего не менять, а просто собрать инфу — найти релевантный код или загуглить ошибку.

Если баг в куске, где уже есть тест, — супер. Просто показываю нейронке, как запустить тест. Если тестов нет, то приходится объяснять, какие шаги приводят к багу и где вообще искать ошибки. На начальном этапе уходит довольно много времени, чтобы описать шаги; думаю, это нормально, и с каждым новым кейсом получается быстрее. Кроме того, тут можно что-то оптимизировать (снять скринкаст и отправить его Gemini для получения текстового описания, например). Да и с каждым разом лучше понимаешь сильные и слабые места нейронки: что-то доходит с двух слов, а что-то нужно описать детально.

Идеальный сценарий 1: Проблема гуглится

Круто, сэкономили кучу времени, нашли релевантный фикс на Stack Overflow или в issue на GitHub. Иногда робот-бобот сам адаптирует решение под проект, и нужно всего пару итераций на шлифовку.

Идеальный сценарий 2: Проблема ясна из кода

Нейросеть пролезла по проекту, по зависимостям, и нашла, где всё ломается. Типа: приходит null, ты не понимаешь почему, а нейронка заглянула в библиотеку и нашёл нужный метод и нужный кусок логики. Такое вручную делать — боль, тут опять экономим время и нервы.

Менее идеальный сценарий

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

В результате для каждого проекта у меня копится набор инструкций о том, как запускать тесты, как общаться с базой, как лучше парсить элементы на странице и т.д. Это всё собирается в отдельный файл, который идет прицепом к основному промпту с задачей. В целом, это очень похоже на анбординг нового разработчика в команде.

Отдельно про Claude 3.7

Он обожает всё переделывать, добавлять тонну отладочной инфы, генерить свои файлы, выдумывать велосипеды. Если видишь, что начинается overengineering, лучше сразу останавливать — либо предложить альтернативы, либо перезапустить с другим запросом. И желательно добавлять инструкции о том, что менять нельзя, а что можно. Например, не менять код в сторонних библиотеках типа vendor и node_modules.