Проверка: не верь на слово
Урок 22 из 26 курса «Вайбкодинг: курс с нуля». Бесплатно, с анимациями и тестом.
«Готово» не значит «работает»
Ты попросил агента добавить в трекер тренировок статистику за месяц. Через пару минут: «Готово, всё работает!». Звучит уверенно, но агент мог не запускать код, проверить один случай из многих или не заметить, что сломал соседнюю страницу. Помнишь цикл со схемы: описал, ИИ написал, ты проверил? Последний шаг твой, и пропускать его нельзя.
Прокликай превью
Агент работал в ветке и открыл PR, значит есть превью-ссылка: копия сайта с новой функцией, живой сайт не тронут. Открой её с телефона и с компьютера. Сначала обычный путь: отметил тренировку, открыл статистику. Потом странное: месяц без тренировок, очень длинное название, двойное нажатие на кнопку. Ломается обычно именно на странном.
Автотесты: проверки-роботы
Автотест: маленькая программа, которая проверяет твой код. Пример: «если три тренировки подряд, серия показывает 3». Попроси агента написать тесты для новой функции и запустить их, часто это команда npm test. Польза: когда ИИ в следующий раз что-то поменяет, тесты сразу покажут, что сломалось. Ловушка: тест, который проходит всегда. Читай названия тестов: они должны описывать реальное поведение.
CI: проверка на каждый PR
CI (continuous integration, непрерывная интеграция): GitHub сам запускает тесты и сборку на каждый PR, например через GitHub Actions. Сборка: шаг, который превращает проект в готовые файлы сайта. Результат видно прямо в PR: зелёная галочка или красный крестик, как в карточке на схеме. Красный: не делай merge, открой лог и отдай ошибку агенту. Настроить CI можно попросить самого агента.
Читай дифф перед merge
Галочки зелёные, но дифф всё равно глянь. Что искать: удалённый код, о котором ты не просил, как красная строка «удалена проверка?» на схеме. Ключи и пароли в коде. Новые пакеты с незнакомыми названиями: бери известные, ведь мошенники выкладывают подделки с похожими именами. Правки в файлах, которые к задаче не относятся. Нашёл такое: спроси агента «зачем?» до merge.
Чек-лист перед merge
Короче, перед merge пять пунктов. Превью проверено с телефона и с компьютера. Тесты зелёные. CI зелёный. Дифф прочитан: нет ключей, удалённых проверок и странных пакетов. Коммиты подписаны понятно. Всё сошлось: merge, и хостинг обновит живой сайт. Не сошлось: правка в той же ветке. Правило с карточки на схеме: сначала проверь, потом merge. Потренируйся в симуляторе GitHub.
Проверь себя
- Агент написал «Готово, всё работает». Что дальше?
Правильный ответ: Самому проверить превью и тесты. «Готово» от агента не доказательство. Он мог не запускать код или проверить один случай. Превью и тесты покажут правду. - Что такое CI?
Правильный ответ: GitHub сам запускает тесты на каждый PR. CI (непрерывная интеграция) автоматически прогоняет тесты и сборку на каждый PR и ставит зелёную галочку или красный крестик. - В диффе удалена проверка, о которой ты не просил. Что делаешь?
Правильный ответ: Спрашиваю агента «зачем?» до merge. Зелёные тесты не ловят всё: удалённую проверку они могут и не заметить. Разберись до merge, пока изменение не попало на живой сайт.