Как проверить код от ИИ, если не умеешь читать код: 7 проверок для непрограммиста в 2026

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

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

И это не паранойя. Anthropic разобрала 400 000 сессий в Claude Code: за семь месяцев доля работы, которая уходит на починку сломанного кода, упала с 33% до 19%. Упала - но не исчезла. Каждая пятая сессия всё ещё про «почини то, что ИИ сломал».

А Борис Черни, который создал Claude Code, прямо предупреждает: писать код на 100% через ИИ, не проверяя, - опасно. Само написание кода перестало быть узким местом. Теперь всё решает то, насколько хорошо ты понимаешь задачу и умеешь проверить результат.

Каждый день в Telegram-канале - что нового в вайб-кодинге: инструменты, примеры, ошибки, на которых я учусь сам. Подпишись, чтобы ничего не пропустить.

Зачем проверять код от ИИ, если он и так работает?

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

Цифры это подтверждают. Бенчмарк FrontierCode в июне 2026 проверял, насколько ИИ-код готов к реальной работе без доработок. Даже у лучших моделей на самых сложных задачах эта доля - около 13%. То есть на серьёзных задачах большую часть кода от ИИ приходится доводить руками, прежде чем на него можно положиться.

Хорошая новость в том, что проверять может кто угодно. Вот что Anthropic вынесла из тех самых 400 000 сессий:

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

Что вообще может пойти не так с кодом от ИИ?

Прежде чем проверять, полезно знать, что именно ищешь. У кода от ИИ пять типовых проблем, и все пять видно без чтения кода - по тому, как проект себя ведёт.

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

Проверка 1: заставь ИИ объяснить свой код простым языком

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

Объясни простым языком, без кода, что именно ты сейчас сделал:

какую задачу решает этот код

что произойдёт, когда пользователь нажмёт кнопку или отправит форму

где хранятся данные и кто к ним имеет доступ

что может сломаться и в каком случае

Пиши так, будто объясняешь человеку, который никогда не программировал. Если в каком-то месте ты сам не уверен, что всё правильно, - прямо скажи об этом.

Читаешь ответ и сверяешь с тем, что было у тебя в голове. Сходится - двигаешься дальше. ИИ «плавает», путается в собственном объяснении или описывает не то, что ты просил, - значит, он сам не до конца понимает, что построил. Возвращаешь на доработку с уточнением, а не принимаешь на веру.

Кстати, если ИИ регулярно делает не то, что ты просил, - дело часто в постановке задачи, а не в самой модели. Про это у меня есть отдельный разбор: почему Claude делает не то, что ты просил.

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

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 14–16 июля  ·  2 000 ₽

Записаться →

Проверка 2: пройди по сценариям, как настоящий пользователь

Демо, которое показывает ИИ, всегда идёт по счастливому пути: правильные данные, один клик, всё складывается. Живой пользователь так себя не ведёт. Он ошибается, тыкает не туда, вводит эмодзи в поле телефона. Твоя задача - пройти проект как он.

1. Пройди главный сценарий целиком

   Сделай то, ради чего проект существует: зарегистрируйся, оформи заказ, отправь заявку. Дойди до самого конца, а не до середины.

2. Проверь оплату отдельно и по-настоящему

   Если есть приём денег - оплати сам минимальной суммой в тестовом режиме. Убедись, что заказ создался, статус сменился, а тебе и клиенту ушло письмо. Оплата, которая «проходит», но не создаёт заказ, - классическая тихая поломка.

3. Специально сломай

   Оставь поля пустыми. Введи буквы туда, где ждут цифры. Нажми «Отправить» дважды подряд. Загрузи файл не того формата. Хороший проект вежливо скажет «так нельзя», плохой - упадёт или молча съест данные.

4. Открой на телефоне

   Половина твоих людей придёт с телефона. Проверь, что там не разъехалась вёрстка и работают те же кнопки.

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

Проверка 3: спроси у ИИ про безопасность - вот промпт

Сломанную кнопку видно сразу. Дыру в безопасности - нет: проект работает как ни в чём не бывало, пока кто-то ей не воспользуется. Самые частые беды у вайб-проектов - секретные ключи прямо в коде, база данных, открытая наружу, и формы, через которые можно передать вредоносный ввод. Всё это ИИ найдёт сам, если прямо попросить.

Проведи аудит безопасности этого проекта и объясни каждую находку простым языком, без жаргона. Пройди по списку:

Нет ли секретных ключей, паролей и токенов прямо в коде. Они должны лежать в файле .env, а сам .env - в .gitignore, чтобы не попасть в публичный репозиторий.

Открыта ли база данных наружу и кто к ней имеет доступ.

Можно ли сломать формы вводом: инъекции в запросы к базе, лишний код в текстовых полях.

Что произойдёт, если пользователь отправит вредоносные данные.

Не выставлены ли наружу служебные страницы и админка без пароля.

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

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

Тема глубокая, и одним промптом её не закрыть до конца. Если проект работает с деньгами или личными данными клиентов - прочитай отдельный разбор: безопасность вайб-кодинга.

Проверка 4: не выдумал ли ИИ библиотеки и данные?

ИИ уверенно пишет то, чего не существует. Он может подключить библиотеку с правдоподобным именем, которой на самом деле нет. Может оставить в проекте тестовые заглушки: товар «Пример», адрес почты example@example.com, текст-рыбу вместо настоящего. На демо это незаметно, а у живого пользователя - позор или поломка.

Ловится двумя движениями. Первое - прямой вопрос:

Пройди по проекту и проверь честно:

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

Не осталось ли где-то тестовых заглушек, примеров и текста-рыбы вместо настоящих данных?

Все ли ссылки, адреса и контакты в проекте - реальные, а не заглушки?

Выпиши списком, что нашёл, и предложи, чем заменить.

Второе - просто запусти проект и пройди по нему глазами. Выдуманная библиотека почти всегда даёт ошибку при запуске. А заглушки видно сразу: если на странице «Товар 1» по цене 100 рублей - ты их не заменил.

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

Проверка 5: пусть вторая модель проверит первую

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

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

1. Открой чистую сессию или другую модель

   Подойдёт вторая модель или та же, но в новом окне без истории задачи.

2. Дай проект и правильную рамку

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

3. Сравни два мнения

   Совпало у обоих - скорее всего, так и есть. Разошлось - копай именно туда, там самое интересное.

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

Проверка 6: как откатиться, если правка что-то сломала?

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

Читать код для этого не нужно. Достаточно попросить ИИ: «сохрани текущую рабочую версию в git с понятной подписью, перед тем как что-то менять». А если после правок всё поехало - «верни проект к прошлой сохранённой версии».

Если git для тебя пока тёмный лес, у меня есть два разбора под руку: как откатить изменения в Claude Code и что делать, если ИИ удалил твою базу данных. Второй - на случай, когда откатываться уже поздно, но всё ещё можно спастись.

Проверка 7: что проверить в последнюю очередь перед публикацией?

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

1. Оплата: тест на бой

   Если принимаешь деньги - убедись, что подключён боевой ключ платёжной системы, а не тестовый. Проведи один реальный платёж на минимальную сумму и верни его себе.

2. Секреты на месте

   Спроси ИИ: «все ключи и пароли лежат в .env, а не в коде? .env точно в .gitignore?». Это защищает тебя от утечки доступов в публичный репозиторий.

3. Резервная копия данных

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

4. Публикация работает не только у тебя

   Открой проект с телефона по внешней ссылке, а не только на своём компьютере. То, что работает локально, не всегда работает после публикации.

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

А если проверять слишком долго - может, просто довериться ИИ?

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

Про это честно говорит Саймон Уиллисон, один из самых заметных голосов в ИИ-разработке: выкладывать на живых пользователей код, который ты сам не проверил, безответственно, потому что проследить, кто виноват, потом будет не по кому.

А создатель Claude Code смотрит на это ещё шире:

Писать код перестало быть узким местом - его закрыл ИИ. Теперь ценность в другом: понять задачу и проверить, что получилось. А это твоя сильная сторона - ты знаешь, каким должен быть результат для твоего клиента, лучше любого стороннего разработчика.

Почему проверка - это навык, а не разовое действие?

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

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

Полная схема по вайб-кодингу за вечер: ИИ-клон, Второй мозг и Контекст-инжиниринг. Три эфира, готовые промпты и проверки остаются у тебя.

Практикум по вайб-кодингу

+Твой второй мозг

3 вечера - стек, метод, первый проект

Старт 14–16 июля  ·  2 000 ₽

Записаться →

Новые материалы - дайджестом, без спама

Гайды выходят регулярно. Подпишись, чтобы не пропускать: пришлю подборку в Telegram или на email. Раз в неделю или каждый день - выбираешь сам.

Подписаться в Telegramили на email