Как проверять код от ИИ: где ошибается нейросеть и как заставить её проверить себя

Можно ли доверять коду ИИ: где нейросеть сильна, а где реально косячит

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

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

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

Почему нейросеть ошибается в коде: галлюцинации и потеря контекста

У ошибок ИИ в коде две системные причины, и обе стоит понимать без математики.

Модель галлюцинирует. Языковая модель предсказывает правдоподобное продолжение, а не проверяет истину. Поэтому она может уверенно сослаться на несуществующую функцию библиотеки или придумать параметр, которого нет. Выглядит убедительно — работает не всегда.

Модель забывает контекст. У агента есть окно контекста — то, что он «видит» прямо сейчас. Пока проект маленький, он держит всё. Как только проект вырастает и сессия становится длинной, агент начинает терять нить: чинит одно, ломая другое, потому что уже не помнит, как связаны куски. Отсюда практическое правило — резать задачу на маленькие шаги и держать постоянный контекст проекта в отдельном файле (в Claude Code это CLAUDE.md), чтобы агент не забывал, что вообще строит.

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

Четыре места, где ломается прод: гонки, дубли оплаты, данные, секреты

Запомните ровно четыре класса ошибок. Их хватает, чтобы закрыть почти всё, что бьёт новичка. Разберём на примере сквозного проекта нашего курса — бота записи к эксперту, где клиент выбирает слот, оплачивает и получает подтверждение.

• Гонка (двое на один слот). Два клиента видят свободный вторник 15:00 и жмут «Записаться» почти одновременно. Сервер для обоих проверяет «слот свободен?» — ещё свободен — и записывает обоих. Одно время, две брони, эксперт в шоке. Щель — между проверкой и записью, и в неё проваливается второй клиент.
• Дубль оплаты. Клиент оплатил, интернет моргнул, платёжка на всякий случай прислала уведомление дважды. Наивный код засчитает две оплаты — спишет повторно или создаст две брони на один платёж. Тут реальные деньги, это самое больное место.
• Утечка данных клиентов. Сервер на запрос «покажи слоты» может заодно вернуть чужие имена и телефоны — просто отдал «всё из строки». Или адрес вида /booking/57 открывается у любого, кто подставит чужой номер, — и видит чужую запись. Данные утекают не через взлом, а через невнимательность.
• Секреты в коде. Пароль базы, ключ платёжки, токен бота агент по умолчанию может вписать прямо в код. Код уходит в git, git — на GitHub, GitHub бывает публичным. Роботы сканируют репозитории и находят такие ключи за минуты.

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

Как заставить нейросеть проверить себя: метод self-check

Главный практический навык — это self-check: вы не ищете дыры глазами, а берёте готовый промпт-чеклист и отдаёте агенту. Нейросеть, которую попросили конкретно, находит своё слабое место сама и тут же чинит. Она отлично знает эти паттерны — просто не применяет их без запроса.

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

• На гонку: «Проверь мой код записи на слот на состояние гонки. Что будет, если два клиента забронируют один слот в одну секунду? Найди щель между проверкой „слот свободен“ и записью брони. Если она есть — почини так, чтобы второй получил понятный отказ, а не вторую бронь.»
• На дубль оплаты: «Проверь обработку оплаты на идемпотентность. Что будет, если платёжка пришлёт уведомление об одной оплате дважды? Сделай так, чтобы повторное уведомление с тем же идентификатором платежа не создавало вторую бронь и не засчитывало оплату дважды.»
• На утечку и секреты: «Проверь два вида утечек: (1) не возвращает ли сервер чужие имена и телефоны; можно ли открыть чужую запись, подставив чужой номер в адрес; (2) нет ли в коде и в git паролей, ключей платёжки, токена бота. Что нашёл — вынеси в переменные окружения, добавь .env в .gitignore.»

Именно так устроен идемпотентный вебхук оплаты в боевом продукте EasyBot: каждому платежу присваивается уникальный ключ, и повторное уведомление с тем же ключом просто игнорируется. Это не магия — это одна проверка «мы это уже обрабатывали?». Но её надо было попросить.

Не верьте «всё ✅»: как проверить ответ нейросети

Есть ловушка, в которую попадают почти все: нейросеть любит отвечать «всё хорошо», не проверив по-настоящему. Ложное «✅» опаснее честного «❌», потому что усыпляет.

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

И второе правило — не чините вслепую. Прежде чем нажать «почини», попросите объяснить простыми словами: что не так, что агент собирается поменять и что от этого может сломаться. За продукт отвечаете вы, а не агент. А перед каждой правкой делайте коммит — это ваша страховка отката: сломалось после починки, откатились к рабочей версии, чините аккуратнее.

Когда что-то сломалось: консоль, баг-репорт и «не паникуй»

Self-check — это работа наперёд, до поломки. Но в проде что-то ломается и без чеклистов: кнопка не реагирует, слот не сохраняется, страница белая. Здесь новичок теряется, потому что непонятно, что случилось и что писать агенту.

Первый инструмент — консоль браузера (клавиша F12). Вкладка Console — сюда приложение пишет ошибки красным, это его «жалобы». Вкладка Network — список запросов от фронта к серверу, тут видно, дошёл ли запрос и что сервер ответил (200 — ок, 404 — виноват запрос, 500 — упал сервер). Вам не нужно понимать ошибку целиком — нужно увидеть её и скопировать. Красный текст читает лучше вас сам агент.

Второй инструмент — баг-репорт из четырёх частей: что делал → что ожидал → что случилось → текст ошибки из консоли целиком. С таким контекстом агент находит причину с первого раза; без него — чинит вслепую и часто мимо.

И главный мета-навык: не паникуй, когда сломалось. Любой продукт ломается, это сама разработка, а не провал. Алгоритм: не переписывай всё заново → если совсем плохо, откатись к рабочему коммиту → покажи агенту текст ошибки → попроси объяснить, что и почему сломалось, прежде чем чинить → чини по одному шагу и проверяй.

Честно про будущее: эти ошибки со временем уменьшатся

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

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