Как я научил ИИ находить баги за меня за 5 минут

Yevhenii Rozov · 2026-05-18

23:40, пятница. Я закрывал ноутбук с ощущением что потерял не 4 часа, а весь день.

Клиент платит $2 800 в месяц за API который я строил три месяца. И в эту пятницу он падал каждые 20 минут с одной и той же ошибкой. Я читал стек трейс, гуглил, перечитывал код, пил кофе, снова читал. Уже набирал текст извинений за срыв дедлайна.

Потом случайно скопировал весь стек в Claude. Просто написал «что здесь не так?»

Через 40 секунд он указал на race condition в строке 73. Которую я пролистывал семь раз.

---

Как 3 часа в день просто испарялись

До того вечера я думал что дебаг это нормальная часть работы. Ну да, долго. Ну да, больно. Зато когда находишь баг сам - есть это чувство победы.

Потом я посчитал сколько стоит эта «победа».

3,2 часа в день - мой средний дебаг за три месяца до марта. Я вёл заметки по задачам, поэтому цифра точная. При рабочем дне в 8 часов это 40% времени которое я просто сжигал.

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

Ты знаешь что хотел написать. Поэтому читаешь то что хотел написать, а не то что написал на самом деле. Это называется confirmation bias и от него не спасает ни опыт, ни кофе, ни «ещё один раз внимательно».

Я терял клиентов из-за этого. Один контракт на $800 ушёл именно потому что я три дня искал баг который был очевидным со стороны. Клиент не стал ждать. Написал «нашёл другого разработчика» и пропал.

Второй взгляд - это не роскошь. Это инфраструктура. Просто у меня его не было, потому что я работаю один.

Я собрал промпты по этой теме в PDF. Забери бесплатно: https://t.me/airozov_bot

---

Промпт который изменил пятничный вечер

После той ночи я начал экспериментировать целенаправленно. Не просто кидать ошибки в чат, а строить конкретный формат запроса.

Вот что реально работает.

Первое - контекст перед ошибкой. Не просто стек трейс, а три вещи сразу: что должен делать код, что происходит вместо этого, и полный фрагмент с ошибкой. Claude с таким контекстом находит проблему в первом ответе в 80% случаев по моей статистике за три недели.

Промпт выглядит так: «Этот код должен [объяснение]. Вместо этого происходит [поведение]. Вот стек и фрагмент: [код]. Что не так и почему именно это?»

Последнее «почему именно это» - критически важно. Без него получаешь fix. С ним получаешь понимание, и следующий раз видишь такой баг сам.

Второе - итеративный дебаг через гипотезы. Когда ошибка не очевидная, я прошу сгенерировать три самые вероятные причины с объяснением почему каждая возможна. Потом проверяю по порядку.

Это убивает хаотичное «попробую вот это, нет, попробую вот то». Вместо случайных попыток - структура. Время на дебаг сложных багов упало с 2-3 часов до 35-40 минут в среднем.

Третье - ревью кода до коммита. Я добавил шаг которого раньше не было: перед каждым пушем в прод кидаю изменённые файлы с запросом «найди потенциальные проблемы с асинхронностью, обработкой ошибок и edge cases». Это поймало четыре бага за три недели которые я бы нашёл только в проде.

Один из них был в коде который шёл клиенту за $1 400. Нашёл за 2 минуты до отправки.

---

То что я понял не сразу

Я думал что использую Claude как умный поисковик. Вбиваю ошибку - получаю ответ. Быстрее Stack Overflow, окей.

Это была неправильная модель.

Настоящий инсайт пришёл на второй неделе. Я объяснял Claude сложную логику авторизации и в процессе написания промпта сам нашёл баг. Claude ещё не ответил. Я просто описывал проблему достаточно точно чтобы её увидеть.

Rubber duck debugging - это старая техника. Объясняешь код резиновой утке на столе и в процессе объяснения понимаешь где ошибка. Работает потому что переключает режим мышления с «писать» на «объяснять».

Claude - это резиновая утка которая иногда отвечает лучше senior-разработчика.

Но главное не ответы. Главное что я теперь формулирую проблему точно прежде чем начать её искать. Это меняет качество дебага фундаментально.

До марта я тратил 3,2 часа в день. Сейчас - 25 минут. Это не потому что Claude волшебный. Это потому что я перестал искать баги хаотично и начал думать структурно.

Разница в подходе, а не в инструменте.

Хотя инструмент тоже важен. Я пробовал тот же процесс с ChatGPT - он чаще предлагает общие решения и реже попадает точно в контекст. Claude держит длинный контекст лучше и не теряет детали когда код большой. Для дебага это критично.

Каждый день разбираю один такой инструмент в Telegram: https://t.me/yevheniirozov

---

Прямо сейчас - один конкретный шаг

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

Зайди на claude.ai и напиши вот этот промпт:

«Этот код должен [что делает]. Вместо этого [что происходит]. Вот фрагмент и полный стек ошибки: [вставь код и ошибку]. Найди проблему и объясни почему именно она вызывает такое поведение. Если причин несколько - расставь по вероятности.»

Не сокращай. Не пиши просто стек трейс. Дай контекст.

Посмотри что будет через 40 секунд.

Если найдёт - у тебя будет личная точка отсчёта. Если не найдёт - напиши мне, разберём что пошло не так с промптом. Я серьёзно, такие кейсы мне интересны.