Поиск и фикс багов

Чем больше кода пишут agents, тем больше времени уходит на ревью и охоту за багами. Даже с помощью agents стоит освежить fundamentals debugging и понять, какие куски расследования можно делегировать.

Debugging fundamentals

Хороший debugging одинаков для человека и для agent’а:

1. Надёжное reproduction — без воспроизведения нет проверки фикса. Запиши шаги, inputs, условия.
2. Минимальный кейс — вырежи всё лишнее. Чем меньше repro, тем проще root cause.
3. Изолируй переменные — меняй по одному. Поменял три вещи и « Magically починилось» — не знаешь, что сработало.
4. Конкретные гипотезы — «баг где-то в payments» слишком широко. «calculateTotal() не учитывает negative discounts» — уже можно проверить.
5. Инструментируй — логи на входах/выходах подозрительного участка, сравни expected vs actual.
6. Regression test — нашёл и починил → напиши тест, который бы поймал баг. Чтобы он не вернулся.

Два подхода

Быстрый фикс простых ошибок

Если есть чёткий error message — часто хватает «вставь стек + контекст» и отпусти agent.

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

Работает, когда причина видна в ошибке. Не всегда — тогда нужен более системный подход.

Debug Mode: сначала evidence

Для хитрых багов Debug Mode идёт от доказательств, а не от угадывания фикса:

1. Генерирует гипотезы
2. Ставит targeted logging
3. Просит тебя воспроизвести баг, пока собирает данные
4. Анализирует логи и находит root cause
5. Делает точечный фикс по evidence

По сути Debug Mode автоматизирует тот же цикл fundamentals, который ты делал бы руками.

Несколько моделей параллельно

На сложных багах разные модели иногда находят разное. В Cursor можно прогнать один debugging brief по нескольким моделям одновременно — каждая в изоляции.

Workflow:

1. Чёткий brief: repro + гипотезы
2. Выбери несколько моделей
3. Отправь prompt — работают независимо
4. Сравни предложенные фиксы
5. Оставь подход с самым сильным evidence

Cursor может подсказать «лучший» вариант, но оценивай reasoning, не только итоговый патч. Попроси модель отдельно верифицировать свой фикс.

Неси runtime data в loop

Agent иногда находит perf-проблемы одним чтением кода. Но с runtime evidence копает глубже.

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

Иногда этого хватает — agent находит N+1 или тяжёлый query прямо в коде.

Корми evidence

Когда анализа кода мало — кидай реальные данные: terminal output, query plans, профили.

Seq Scan on orders ... Filter: (user_id = 'usr_abc123')
Rows Removed by Filter: 2341856
Execution Time: 1203.298 ms

Тот же паттерн работает для app logs, profiling data, output тестов и билдов.

Browser для фронта

Встроенный browser даёт agent’у доступ к приложению: console, network, DOM. Можно попросить открыть страницу, воспроизвести баг и проследить путь до исходников — без ручного копипаста из DevTools.

MCP к monitoring

MCP подключает Sentry, Datadog, БД, Linear/GitHub Issues. Вместо ручной вставки данных agent сам тянет нужное.

Можно даже выстроить workflow, где алерт сам заводит тикет и запускает agent-расследование — иногда баг чинят до того, как его заметили пользователи.

Частый fail: принять фикс, который не понимаешь

Не понял фикс — не можешь валидировать. Agent мог воткнуть null-check: ошибка пропала, а data inconsistency осталась.

Спрашивай, пока не станет ясно: почему значение null? что изменилось? это root cause или маскируем симптом? Помни foundations: модели умеют правдоподобно hallucinate объяснения. Сверяй их рассказ с данными расследования.

Что дальше

Баги ловить научились. Дальше — ревью и системное тестирование, чтобы изменения не притащили регрессии.