Самая частая ловушка в вайбкодинге выглядит так: ИИ быстро написал функцию, сайт открылся, кнопка нажимается, и кажется, что всё готово. А потом выясняется, что форма принимает пустые данные, пароль хранится как попало, а после одной правки ломается то, что вчера работало. Вот поэтому вопрос, как тестировать код от ИИ, возникает не у зануд, а у всех, кто не хочет чинить проект ночами.
Нейросеть умеет ускорять работу, но она не несёт ответственность за ваш мини-сервис. Она может уверенно написать кривую логику, забыть про крайние случаи, перепутать обработку ошибок и оставить дыры в безопасности. Это не повод отказываться от ИИ. Это повод сразу работать по нормальной схеме: сначала проверка руками, потом сценарии, потом защита от повторных поломок.
Если вы только входите в тему, сначала полезно понять сам подход к работе с ИИ в проектах. Для этого у меня уже есть материал: вайбкодинг: с чего начать новичку без знания кода. А здесь разберём именно проверку того, что уже было сгенерировано.
Почему код от ИИ нельзя принимать на веру
Нейросеть не думает о проекте как разработчик, который отвечает за результат. Она предсказывает наиболее вероятный следующий фрагмент текста. Иногда это отличный код. Иногда почти рабочий. Иногда красивая ловушка, которая разваливается на первом нестандартном вводе.
Что я вижу чаще всего:
- код выглядит убедительно, но не покрывает реальные сценарии использования;
- обработка ошибок сделана для вида;
- данные валидируются только на клиенте, а на сервере нет;
- после одной доработки ломается старое поведение;
- в проекте появляются лишние зависимости, которые тащат риски и путаницу;
- нейросеть пишет устаревший или небезопасный способ решения.
Особенно опасно доверять ИИ там, где есть платежи, персональные данные, медицина, право, доступы, клиентские базы и всё, что связано с безопасностью. Такие вещи нельзя запускать без проверки специалиста. ИИ здесь может быть помощником, но не последней инстанцией.
С чего начинать проверку: не с тестов, а с чтения задачи
Новичок часто делает наоборот: запускает код, видит, что ошибок в консоли нет, и считает задачу выполненной. Но проверка кода нейросети начинается не с кнопки Run, а с простого вопроса: что именно должно работать?
Если у вас нет короткого списка ожидаемого поведения, вы не тестируете. Вы просто кликаете по интерфейсу в надежде, что ничего не сломается.
Минимум, который нужен перед проверкой
- какая функция или экран проверяется;
- что пользователь вводит;
- что система должна вернуть;
- что должно происходить при ошибке;
- что не должно ломаться рядом.
Простой пример. ИИ сделал форму регистрации. Проверять надо не только успешную отправку. Нужно зафиксировать хотя бы такие сценарии: пустое имя, неверный email, короткий пароль, повторная регистрация с тем же адресом, сбой сервера, странные символы в полях.
Пока это не записано хотя бы в черновике, вы почти наверняка пропустите половину проблем.
Ручная проверка: первый фильтр, который нельзя пропускать
Ручная проверка нужна даже тогда, когда вы потом добавите автоматические тесты. Она помогает быстро отловить очевидные нелепости, которые ИИ любит оставлять в проекте.
Что смотреть руками в первую очередь
- Логика: делает ли код именно то, что нужно, а не что-то похожее.
- Названия и структура: можно ли понять, где основная функция, где вспомогательная, где обработка ошибок.
- Дублирование: не написал ли ИИ три почти одинаковых куска вместо одного нормального.
- Проверки входных данных: что будет, если передать пустое, слишком длинное или странное значение.
- Обработка ошибок: возвращается понятная ошибка или всё падает молча.
- Работа с секретами: нет ли токенов, паролей и ключей прямо в коде.
- Лишние пакеты: не подтянул ли ИИ зависимости, которые вообще не нужны.
Что обычно пропускают новички
Вот здесь новичок обычно ломается: проверяет счастливый сценарий. То есть тот, где всё хорошо. Нажал кнопку, получил результат, пошёл дальше. Но реальный пользователь живёт не в идеальном мире. Он ошибается, обновляет страницу, отправляет форму дважды, вставляет мусор в поля, закрывает вкладку на середине.
Если вы тестируете только успешный путь, вы проверяете рекламную версию проекта, а не реальную.
Проверка по сценариям: самый практичный способ не утонуть
Когда проект маленький, не нужно строить огромную систему тестирования. Достаточно сделать набор сценариев и проходить их после заметных изменений. Это уже резко снижает риск.
Какие сценарии должны быть почти всегда
- Успешный сценарий: всё введено правильно, функция отрабатывает как задумано.
- Пустые значения: поля пустые, параметры отсутствуют, массив пустой.
- Неверный формат: неправильный email, текст вместо числа, слишком длинная строка.
- Крайние случаи: ноль, отрицательное число, очень большое значение, один символ, тысяча символов.
- Повтор действия: двойной клик, повторная отправка, повторный запрос.
- Сбой внешней части: сервер недоступен, ответ пришёл с ошибкой, данные не загрузились.
- Права доступа: нельзя ли увидеть или изменить то, что пользователю не положено.
Для мини-сервиса этого уже хватает, чтобы увидеть основную картину. Не надо усложнять.
Как превратить это в рабочий список
Я обычно советую сделать простую табличку и отмечать статус после каждой правки.
| Что проверяем | Пример | Ожидаемый результат |
|---|---|---|
| Успешная работа | Форма отправлена с корректными данными | Данные сохраняются, пользователь видит понятный ответ |
| Пустой ввод | Нажать отправку без заполнения | Появляется сообщение об ошибке, данные не уходят |
| Неверный формат | Ввести текст вместо числа | Поле не принимается, ошибка объяснимая |
| Сбой сервера | Запрос завершился ошибкой | Интерфейс не зависает, пользователь видит корректное сообщение |
| Повтор действия | Нажать кнопку два раза подряд | Нет дублей, нет двойной записи |
| Права доступа | Открыть чужие данные по прямой ссылке | Доступ запрещён |
Такая схема кажется скучной ровно до первого момента, когда вы одной правкой ломаете старый экран. После этого таблица внезапно становится любимой.
Какие ошибки ИИ пишет чаще всего
Ошибки бывают разного уровня. Есть просто неудобные. Есть дорогие. Есть опасные.
Логические ошибки
Код работает, но результат не тот. Например, скидка считается не от той суммы, сортировка идёт по строке вместо числа, дата сравнивается неправильно, фильтр пропускает лишнее.
Такие ошибки неприятны тем, что приложение не падает. Оно просто врёт.
Ошибки обработки данных
Нейросеть часто недооценивает грязный ввод. Пустые строки, пробелы, null-значения, неожиданный формат, вложенные объекты, очень длинные значения. На красивом примере всё работает, на реальных данных начинается суета.
Ошибки на стыке фронтенда и сервера
Одна часть проекта ждёт число, другая возвращает строку. Клиент ждёт поле status, сервер отдаёт state. При успешном ответе всё похоже, при ошибке интерфейс рассыпается.
Устаревшие и сомнительные решения
ИИ может предложить код, который когда-то был нормальным, а сейчас уже плохая идея. Или добавить пакет с дурной репутацией. Или использовать небезопасный способ работы с пользовательскими данными.
Уязвимости: что проверить, даже если проект маленький
Слово «уязвимости» звучит так, будто речь только про крупный сервис. На деле даже маленький проект может утечь, сломаться или открыть доступ не тому человеку.
Минимальный список проверок такой:
- нет ли секретов, ключей и паролей прямо в коде;
- валидируются ли входные данные не только в интерфейсе, но и на серверной стороне;
- нельзя ли через URL или параметр получить чужие данные;
- нет ли опасной вставки пользовательского текста в HTML или запросы;
- не отдаёт ли сервер слишком подробные ошибки с внутренней информацией;
- не выполняются ли действия без проверки прав доступа.
Если ИИ написал код для авторизации, загрузки файлов, платежей, работы с персональными данными или административной панели, не ограничивайтесь бытовой проверкой. Тут нужен человек с опытом безопасности. Без этого запускать рискованно.
Регресс: как не ломать старое каждой новой правкой
Регресс звучит грозно, но смысл простой: вы исправили или улучшили одну часть, а сломалась другая, которая раньше работала. В проектах с ИИ это встречается постоянно, потому что нейросеть охотно переписывает лишнее.
Почему это так часто происходит
- вы дали слишком широкую задачу, и ИИ полез менять всё подряд;
- в проекте нет списка базовых сценариев;
- после правки никто не прогоняет старые проверки;
- нейросеть дублирует логику в нескольких местах, и они расходятся.
Как снизить риск регресса
- Просите ИИ менять только конкретный файл или функцию, если это возможно.
- Перед правкой фиксируйте, что сейчас работает.
- После правки прогоняйте короткий обязательный список сценариев.
- Сохраняйте версии проекта перед заметными изменениями.
- Не принимайте большой рефакторинг от ИИ без отдельной проверки.
Если говорить совсем по-простому: не давайте помощнику перестраивать полквартиры, когда вам нужно подкрутить одну дверцу.
Когда подключать автоматические тесты
Если проект живёт дольше пары вечеров, автоматические тесты уже имеют смысл. Не потому что так «правильно», а потому что руками каждый раз проверять одно и то же быстро надоедает, и вы начинаете пропускать очевидное.
Что автоматизировать в первую очередь
- критичные функции расчётов;
- валидацию данных;
- основные ответы сервера;
- главный пользовательский путь: вход, отправка формы, сохранение, поиск.
Но здесь есть важный момент: тесты, которые написал ИИ, тоже надо проверять. Нейросеть умеет сочинять тесты, которые проверяют не то, что нужно, или просто повторяют ошибочную логику из основного кода. Автотест не магия. Это тоже код.
Как ставить задачу ИИ, чтобы потом было проще проверять
Качество проверки сильно зависит от качества запроса. Если вы пишете расплывчато, ИИ делает расплывчато. А потом вы часами разбираете, что именно он вообще построил.
Плохо: «Сделай форму регистрации с проверками и нормальной безопасностью».
Лучше: «Сделай форму регистрации с полями имя, email, пароль. Проверь пустые значения, неверный email, пароль короче 8 символов. Ошибки должны показываться пользователю понятным текстом. Не храни пароль в открытом виде. Не меняй остальную структуру проекта. Отдельно перечисли, какие сценарии мне проверить руками после генерации кода».
Второй вариант не делает результат идеальным, но после него хотя бы видно, что и зачем проверять.
Частые ошибки новичков при тестировании кода от ИИ
- Проверили только один успешный сценарий.
- Не посмотрели, что происходит при ошибке сервера.
- Не проверили пустые и кривые данные.
- Приняли красивый код за правильный код.
- Попросили ИИ «исправить всё», а потом не поняли, что именно он сломал.
- Не сохранили предыдущую рабочую версию.
- Не отделили баг в логике от бага в интерфейсе.
- Запустили чувствительный проект без проверки специалиста.
Последний пункт особенно неприятный. Если мини-сервис работает с деньгами, доступами или личными данными, цена ошибки намного выше, чем экономия от быстрой генерации.
Практический порядок проверки после каждого заметного изменения
Если нужен простой рабочий ритм без лишней теории, берите такой:
- Сохраните текущую рабочую версию проекта.
- Попросите ИИ внести узкое изменение, а не переписывать всё подряд.
- Руками прочитайте изменённые места: логика, данные, ошибки, доступы.
- Прогоните успешный сценарий.
- Прогоните 3-5 негативных сценариев: пусто, неверный формат, сбой, повтор действия.
- Проверьте соседние функции, которые могли зацепиться регрессом.
- Посмотрите логи и консоль, даже если снаружи всё выглядит нормально.
- Только после этого двигайтесь дальше.
Эта схема не выглядит героически. Зато она спасает от ситуации, когда вы к вечеру собрали «почти готовый» сервис, а утром обнаружили, что он ломается от первого же нестандартного ввода.
Что сделать прямо сейчас
Возьмите любой кусок кода, который вам недавно написал ИИ, и составьте для него 5 сценариев проверки: один успешный, два с ошибками ввода, один со сбоем, один на регресс соседней функции. Потом прогоните их руками и запишите, что сломалось. Уже после этого просите ИИ исправлять конкретные проблемы по списку, а не абстрактно «улучшить код».
Вопрос-ответ
Нужно ли тестировать каждый кусок кода, который написал ИИ?
Если это одноразовый черновик для себя, глубина проверки может быть минимальной. Но любой код, который влияет на данные, оплату, доступы, регистрацию, отправку форм или работу сервиса, нужно проверять обязательно.
Можно ли доверять, если код запускается без ошибок?
Нет. Отсутствие явной ошибки при запуске не значит, что логика верная, данные обрабатываются безопасно, а соседние части проекта не сломаны.
Что важнее сначала: ручная проверка или автотесты?
Сначала ручная проверка. Она помогает быстро увидеть грубые проблемы и понять, что именно надо закрепить тестами. Потом уже имеет смысл автоматизировать повторяющиеся проверки.
Как понять, что в коде есть риск уязвимости?
Если код работает с авторизацией, файлами, формами, пользовательским вводом, ключами доступа, персональными данными или административными действиями, риск уже есть. В таких местах нужна отдельная проверка безопасности.
Что такое регресс простыми словами?
Это когда вы починили или улучшили одно место, а сломалось другое, которое раньше работало. При работе с ИИ это обычная история, если не проверять старые сценарии после правок.
Какой минимум сценариев нужен для маленького проекта?
Обычно хватает успешного сценария, проверки пустого ввода, неверного формата, сбоя внешней части и повторного действия. Для чувствительных функций список должен быть шире.
Может ли ИИ сам написать хорошие тесты?
Может помочь, но слепо доверять нельзя. Нейросеть нередко пишет тесты, которые проверяют слишком поверхностно или повторяют ту же ошибочную логику, что и основной код.
Когда без специалиста лучше не запускать проект?
Когда есть платежи, персональные данные, медицина, право, клиентские базы, система ролей и доступов, загрузка файлов или другие чувствительные части. Здесь проверка опытным разработчиком или специалистом по безопасности уже не роскошь.