Поиск и исправление багов

Чем больше кода пишут кодовые Agent, тем больше времени инженеры тратят на ревью этого кода и поиск багов. Даже с помощью кодовых Agent стоит освежить в памяти основы эффективной отладки и подумать, какие части этого процесса можно делегировать Agent, чтобы ускорить работу.

Основы отладки

Эффективная отладка строится на одних и тех же принципах независимо от того, выполняет работу человек или Agent:

1. Создайте надёжный способ воспроизведения. Если вы не можете воспроизвести баг, вы не сможете проверить исправление. Запишите точные шаги, входные данные и условия, при которых возникает проблема.
2. Сведите проблему к минимальному случаю. Уберите всё, что не связано с багом. Чем меньше сценарий воспроизведения, тем проще найти корневую причину.
3. Изолируйте переменные. Меняйте по одному параметру за раз. Если изменить три вещи и баг исчезнет, вы не поймёте, какое из изменений его исправило.
4. Формулируйте конкретные гипотезы. Предложите несколько возможных корневых причин. «Баг, вероятно, в коде оплаты» — слишком расплывчато. «Баг возникает, потому что calculateTotal() не учитывает отрицательные скидки» — гипотеза, достаточно конкретная для проверки.
5. Добавьте в код средства диагностики. Добавьте логирование входных и выходных данных в месте, где, по вашему мнению, возникает проблема. Сравните ожидаемые значения с фактическими.
6. Предотвращайте регрессии с помощью тестов. Найдя и исправив баг, напишите тест, который выявил бы его. Это предотвратит повторное появление того же бага.

Два подхода к отладке

Быстрое исправление простых ошибок

Если у бага понятное сообщение об ошибке или очевидная причина, Agent часто может сразу найти и исправить проблему. Вставьте текст ошибки, добавьте контекст о том, когда она возникает, и позвольте Agent выполнить работу.

TypeError: Cannot read properties of undefined (reading 'profile')
at getProfile (src/services/UserService.ts:45)
at UserController.show (src/controllers/UserController.ts:23)

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

Режим отладки: сначала факты

Для более сложных багов режим отладки использует другой подход. Вместо того чтобы угадывать исправление, он сначала собирает данные о работе программы.

Режим отладки следует пяти шагам, основанным на базовых принципах отладки:

1. Формирует гипотезы о том, что могло пойти не так
2. Добавляет в ваш код целевое логирование
3. Просит вас воспроизвести баг, пока собирает данные
4. Анализирует логи, чтобы определить корневую причину
5. Вносит целевое исправление на основе собранных данных

Режим отладки поможет найти и исправить самые сложные баги. Он использует рассмотренные ранее основы и обучает Agent эффективной отладке, автоматизируя исследование, которое иначе пришлось бы проводить вручную.

Запускайте несколько моделей параллельно

При сложных багах разные модели иногда находят разные решения. Cursor позволяет одновременно запускать один и тот же промпт для отладки в нескольких моделях. Каждый Agent работает изолированно, поэтому они не будут мешать друг другу.

Рабочий процесс:

1. Составьте чёткое описание задачи по отладке с шагами воспроизведения и вашими гипотезами
2. Выберите несколько моделей в раскрывающемся списке Agent
3. Отправьте промпт — каждая модель будет работать независимо
4. Сравните предложенные каждой моделью исправления
5. Выберите подход с наиболее убедительными аргументами

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

Добавьте данные времени выполнения в цикл работы Agent

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

Начните с вопроса

Чтобы начать расследование, не всегда нужны логи или инструменты профилирования. Задайте Agent прямой вопрос, и он проанализирует ваш код на наличие распространённых проблем.

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

Передавайте Agent данные времени выполнения

Когда одного анализа кода недостаточно, передайте Agent реальные данные. Вставьте в диалог выходные данные Терминала, логи запросов или другие данные. Agent сможет использовать их, чтобы быстрее найти корневую причину.

Например, если вы исследуете медленный запрос к базе данных, выполните EXPLAIN ANALYZE для медленного запроса Postgres, вставьте выходные данные — и Agent сможет связать проблему с вашей схемой:

Seq Scan on orders  (cost=0.00..45892.00 rows=47 width=244) (actual time=0.423..1203.112 rows=47 loops=1)
Filter: (user_id = 'usr_abc123')
Rows Removed by Filter: 2341856
Planning Time: 0.089 ms
Execution Time: 1203.298 ms

Этот подход также работает с логами приложения, данными профилирования и выходными данными сборки и тестов.

Используйте браузер для отладки фронтенда

При проблемах с фронтендом интегрированный браузер Cursor предоставляет Agent прямой доступ к вашему веб-приложению. Он может читать логи консоли, анализировать сетевые запросы и просматривать DOM — вам не нужно ничего копировать.

Попросите Agent открыть страницу, воспроизвести проблему и проверить консоль на ошибки или вкладку «Сеть» на наличие медленных запросов. Agent видит то же, что и вы в DevTools, и может проследить проблему до исходного кода.

Подключите инструменты мониторинга через MCP

MCP‑серверы дают вашему Agent новые возможности и подключают его к инструментам наблюдаемости в продакшене. Вместо того чтобы вручную вставлять данные, Agent по запросу получает всё необходимое.

В примере выше Agent запрашивает Sentry через MCP и получает нужные сведения об ошибке. Он сопоставляет ошибку с логами, находит проблемный код и предлагает исправление — всё в рамках одного диалога.

Полезные MCP‑серверы для отладки:

• Sentry: Сведения об ошибках, стеки вызовов и breadcrumbs
• Datadog: Логи из продакшена и трассировки APM
• Базы данных: Запрашивайте данные из продакшена для проверки гипотез
• Linear или GitHub Issues: Добавляйте в диалог отчёты об ошибках и шаги воспроизведения

Можно настроить рабочие процессы, в которых оповещения мониторинга в вашем приложении в продакшене автоматически запускают расследования Agent. Если частота ошибок резко возрастает, в Linear создаётся тикет, и Agent начинает диагностировать проблему ещё до того, как её увидит человек. Это может сократить время на устранение ошибок, о которых сообщили клиенты, или даже исправить проблемы до того, как клиенты их заметят.

Распространённая ошибка: принимать исправления, сути которых вы не понимаете

Если вы не понимаете исправление, вы не сможете проверить, корректно ли оно. Agent может добавить проверку на null, после которой ошибка исчезнет, но несогласованность данных останется.

Когда Agent предлагает исправление, задавайте вопросы, пока не поймёте его суть. Почему это значение равно null? Что изменилось и привело к этому? Это корневая причина или мы лишь маскируем симптом? Как мы уже разбирали в основах, агенты могут галлюцинировать правдоподобные объяснения. Вам нужно самостоятельно разобраться в проблеме и использовать данные своего исследования, чтобы подтвердить, что Agent выявил истинную корневую причину.

Что дальше

Теперь, когда вы знаете, как отлаживать код и как кодовые агенты могут ускорить поиск причин проблемы, нужно убедиться, что внесённые изменения корректны и не приведут к регрессиям. В следующей главе вы узнаете, как проводить ревью кода и систематически его тестировать.