Надёжнее всего код, созданный ИИ, проверяется так: заранее записываешь, что приложение должно делать в каждом случае, а потом намеренно пробуешь ситуации, в которых что-то может пойти не так. Один работающий пример мало что доказывает. Он показывает лишь, что срабатывает именно этот путь.
Новичку это может показаться задачей для программиста. По большей части это не так. Чтобы проверить, делает ли код то, что должен, не обязательно читать его строка за строкой. Нужны чёткие ожидания, несколько неудобных тестовых случаев и привычка самостоятельно перепроверять каждый результат.
Почему одного удачного примера мало
Представь, что ты просишь ИИ-агента, например Claude Code или Codex, добавить в твой список контактов форму для новых записей. Ты вводишь имя и адрес электронной почты, нажимаешь «Сохранить», и контакт появляется в списке. Выглядит готовым.
Но многое остаётся неясным:
- Что произойдёт, если поле имени пустое?
- Примет ли форма «max@» как адрес электронной почты?
- Сохранится ли контакт после перезагрузки страницы?
- Не появится ли уже существующий контакт дважды?
ИИ построил тот путь, который ты описал. Развилки, о которых ты не упомянул, он мог учесть, а мог и не учесть. Код выглядит аккуратно, ответ звучит уверенно, поэтому пробел часто обнаруживается только тогда, когда приложением начинают пользоваться по-настоящему. Обычный сценарий редко бывает проблемой. Ошибки чаще всего прячутся на краях.
Заранее определить, что считается правильным
Прежде чем проверять, нужен эталон. Для этого подходят приёмочные сценарии: короткие предложения, которые описывают ситуацию и ожидаемый результат. Для смены статуса в приложении для follow-up это может выглядеть так:
- Если я меняю статус контакта с «новый» на «связались», список сразу показывает новый статус.
- Если я фильтрую по статусу, отображаются только контакты с этим статусом.
- Если дата follow-up уже в прошлом, контакт помечен как просроченный.
Такие предложения помогают дважды. Их можно отдать ИИ как задание вместо «сделай какой-нибудь фильтр». А потом можно отметить каждое предложение по отдельности. То, что ты не сформулировал, проверить тоже не получится. Поэтому о неприятных случаях стоит думать уже тогда, когда пишешь задание.
Что тесты дают и чего не дают
Автоматический тест это небольшая программа, которая воспроизводит приёмочный сценарий и сообщает, наступает ли ожидаемый результат. Вместо того чтобы каждый раз кликать вручную, ты запускаешь команду и видишь, какие проверки пройдены, а какие нет.
Главное, что дают тесты:
- Они фиксируют, что считается правильным, независимо от того, насколько убедительно звучит объяснение ИИ.
- Они срабатывают, если более позднее изменение ломает то, что раньше работало. При работе с ИИ-агентом такое случается легко: переделывая одно место, он иногда заодно меняет другое.
- Они делают проверку повторяемой. Ты проверяешь не на ощущениях, а каждый раз одинаково.
При этом у тестов есть границы. Тест проверяет только то, что в нём написано. Если попросить ИИ написать код и тесты одновременно, в обоих может оказаться одна и та же ошибка в рассуждениях. Тогда всё зелёное, но всё равно неверно. Поэтому хотя бы прочитай, что должен проверять тест, и сравни это со своими приёмочными сценариями. А если тест не проходит, не позволяй ИИ просто подправлять тест, пока он не пройдёт. Сначала выясни, что неверно: код или тест.
Намеренно проверять нештатные случаи
Нештатные случаи это ситуации, которые отклоняются от идеального сценария. Тот, кто вызывает их намеренно, находит большинство слабых мест. Для простого приложения четыре группы уже охватывают многое.
Недостающие данные
Оставь обязательные поля пустыми. Сохрани контакт без имени, создай follow-up без даты. Обрати внимание, показывает ли приложение понятное сообщение или в списке оказывается пустая запись. Проверь и поля, в которых только пробелы: для многих программ пробел считается допустимым вводом.
Некорректный ввод
Введи данные, которые не соответствуют ожидаемому формату: адрес почты без домена, дату вроде 31 февраля, очень длинный текст. Попробуй также спецсимволы и умлауты в имени. Хорошая проверка данных отклоняет бессмыслицу и пропускает корректный ввод вроде «Müller-Zürcher». Тестировать нужно и то и другое.
Интерфейс недоступен или отвечает не так, как ожидалось
Как только приложение получает данные через интерфейс (API), появляются новые источники ошибок. Проверь как минимум такие случаи:
- Ответ пустой. Показывает ли приложение осмысленную подсказку или пустую, сбивающую с толку область?
- Интерфейс сообщает об ошибке. Приложение падает или им по-прежнему можно пользоваться?
- Ответ приходит долго. Видно ли, что идёт загрузка, или приложение кажется зависшим? Можно ли за это время нажать дважды и создать дублирующиеся записи?
С настоящим интерфейсом такие случаи вызвать трудно, потому что он обычно работает. Гораздо удобнее симулированный интерфейс, который по запросу отвечает пусто, с ошибкой или медленно.
Доступ и секреты
Об этой области часто забывают. Спроси себя, кто какие данные может видеть или менять, и проверь, так ли это реализовано. Также убедись, что ключи доступа и пароли не записаны прямо в коде. Бывает, что сгенерированный код вписывает такие значения прямо в файл, если в задании не сказано иначе.
Чек-лист для каждого изменения от ИИ
Этот короткий список можно проходить после каждого крупного шага:
- Я заранее одним предложением записал, чего должно добиться изменение.
- Я сам проверил обычный сценарий и не полагался на резюме от ИИ.
- Я протестировал хотя бы один случай с недостающими и один с некорректными данными.
- Если задействован интерфейс: проверены пустой ответ, ошибка и ожидание.
- Все автоматические тесты проходят, в том числе те, что проходили и раньше.
- Я знаю, какие файлы изменил ИИ, и могу примерно объяснить почему.
- В коде нет паролей и ключей.
Если какой-то пункт не выполнен, дай ИИ конкретную подсказку: какой случай, какой результат ты ожидал, что произошло вместо этого. Чем точнее описание, тем точнее исправление.
Прозрачная работа с ИИ-протоколом
Проверять значит также помнить потом, что происходило. Помогает простой протокол: о чём ты спрашивал ИИ, что он предложил, что ты сам изменил или отбросил? Звучит как лишняя работа, но окупается, как только появляется ошибка. Тогда можно сузить круг и понять, на каком шаге она появилась. А если вдобавок сохранять небольшие промежуточные версии в Git, неудачное изменение можно откатить, вместо того чтобы перекрывать его новыми заданиями.
Протокол помогает и при объяснении. Кто может описать своё решение и назвать его границы, тот его проверил. Кто может сказать только «ИИ так сделал», тот ему доверился.
Как с этим связан курс Vibe Coding Foundation
В программе Vibe Coding Foundation ты с помощью Claude Code или Codex создаёшь приложение для контактов и follow-up для небольшой фирмы, с примерными данными. Проверка проходит через все миссии. У каждой миссии есть цель, критерии в виде тестов и подсказки трёх уровней. На твоём компьютере команда проверяет, соответствует ли решение критериям. Засчитывается проверка на сервере академии, в изолированной среде без доступа к сети. Так ты на практике видишь, что «у меня работает» и «проходит критерии» это две разные вещи.
Нештатные случаи из этой статьи встречаются в курсе конкретно:
- В миссии 3 ты проверяешь ввод и добавляешь смену статуса и фильтры.
- В миссии 4 ты на симулированном интерфейсе учишься обрабатывать ответы, ошибки и ожидание.
- В миссии 5 ты локализуешь подготовленные ошибки, устраняешь их и проверяешь базовые случаи доступа.
- В миссии 7 ты добавляешь в приложение CSV-экспорт просроченных follow-up и проверяешь новую функцию.
На протяжении всего курса ты ведёшь ИИ-протокол. В письменном проектном экзамене ты объясняешь своё решение и его границы; как идёт оценка, показывает рубрика экзамена. Все миссии с плановым временем есть в обзоре курса, а миссия 0 по настройке инструментов открыта для чтения. Обе страницы на немецком. Учебный проект хранит данные в браузере и предназначен для учебных данных, а не для реальных данных фирмы. Сколько стоит курс и что в него входит, смотри в разделе Цена и услуги.