Как чинить баги вместе с ИИ — 5 шагов, чтобы он помог, а не угадывал

Самый частый способ просить ИИ починить баг — написать «не работает, почини». И самый бесполезный. ИИ не сидит у тебя за спиной: он не видит твой экран, не знает, что ты ждал, и не читает мысли. Дай ему то, что дал бы живому коллеге, — и он чинит баги отлично. Вот пять шагов, как именно.

Шаг 1. Воспроизведи баг и скопируй ошибку дословно

Сначала добейся, чтобы баг повторялся стабильно. Потом найди текст ошибки и скопируй его целиком: сообщение, путь к файлу, номер строки. Не пересказывай «там что-то про undefined» — давай дословно.

TypeError: Cannot read properties of undefined (reading 'name')
    at UserCard (UserCard.jsx:14)

Что получится: уже по этой строке ИИ часто называет причину — UserCard.jsx, строка 14, что-то стало undefined. Точный текст экономит весь следующий разговор.

Шаг 2. Дай контекст: код, что ждал и что получил

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

Вот компонент UserCard (код ниже).
Ожидал: показывает имя пользователя.
Получил: падает с TypeError выше, когда пользователь ещё не загрузился.

Чем точнее «ожидал → получил», тем меньше ИИ гадает. Это тот же навык, что и хороший промпт: не «помоги», а чёткое ТЗ. Что получится: ответ про твой случай, а не общий совет из учебника.

Шаг 3. Попроси сначала гипотезу, а не сразу фикс

Не проси «перепиши мне код». Попроси объяснить причину — и только потом чинить.

Объясни простыми словами, почему это падает.
Дай 1–2 вероятные причины. Код пока не переписывай.

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

Шаг 4. Меняй по одному и проверяй после каждого

Когда дошло до правок — вноси их по одной. ИИ любит предложить три изменения разом; применишь всё и заработало — не знаешь, что именно помогло, а сломалось сильнее — не знаешь, что виновато.

Давай по одному. Применим только первую правку — я проверю и вернусь.

Что получится: ты всегда знаешь, какое изменение что сделало. Это разница между «починил» и «случайно перестало падать».

Шаг 5. Застрял? Дай минимальный пример

Если баг не сдаётся, не вали на ИИ весь проект. Вырежи самый маленький кусок, который всё ещё воспроизводит проблему, и покажи только его. Половину времени, пока ты его вырезаешь, причина всплывает сама (программисты зовут это «эффект резиновой уточки»: объясняешь вслух — и понимаешь).

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

Что в итоге

Отладка с ИИ — это не «почини за меня», а нормальное расследование вдвоём: воспроизвёл → дал ошибку и контекст → понял причину → правишь по одному. Этот навык важнее любого языка: код от ИИ почти всегда выходит с багами с первого раза, и побеждает не тот, кто пишет без ошибок, а тот, кто умеет быстро их выбивать. Если только осваиваешься, глянь что такое вайб-кодинг — отладка там половина дела.

Вопрос: какой ИИ лучше для отладки?

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

Вопрос: стоит ли просто вставлять ошибку и жать «фикс»?

Для мелочи — почему нет, часто срабатывает. Но на чём-то сложнее ты копишь заплатки, не понимая системы, и баги возвращаются. Привычка спрашивать «почему» окупается: через месяц ты чинишь вдвое быстрее, потому что понимаешь свой код, а не только латаешь его.