Регрессия в вайбкодинге: тест на баг, чтобы ИИ не ломал починенное

Почему ИИ не видит свою же ошибку

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

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

Зачем это знать вайбкодеру

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

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

Разница между «ИИ мне вечно что-то ломает» и «ИИ мне больше это не ломает» - это один маленький автотест, написанный в нужный момент.

Главная ловушка: ИИ проверяет сам себя

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

1. ИИ добавил новое поле в ответ сервера - но забыл попросить его из базы. Сам проверил, ничего не заметил.
2. Попросил из базы - вылезла другая ошибка, в типах. Опять сам всё проверил - и новую беду проглядел.
3. Поправил - но починил только рабочий режим, а про демо-режим забыл. Проверил - снова мимо.
4. Четвёртый заход - и только тест поймал ошибку мгновенно, с первого запуска. Без споров и самоуспокоения.

Как лечится: тест на пойманный баг

Лечение простое и слегка контринтуитивное. Тебе не нужно покрывать тестами весь проект - это долго, дорого и почти бесполезно. Нужно другое.

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

Пиши тест не на код, который работает, а на баг, который уже находили.

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

Самый частый повтор: починил одно, забыл второе

В том реальном проекте 3 бага из 4 были одного сорта. В коде есть два пути: рабочий (с настоящими данными) и демо (с примерными, чтобы быстро показать сайт). ИИ чинит один путь и в упор забывает про второй. Классика. Как забыть второй носок.

Пример из жизни: настройки уведомлений

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

А на самом деле всё проще. ИИ чинит один кусочек и ломает соседний - и сам этого не видит. Проверяет той же головой, что и писала.

Понимающий вайбкодер тут не просит «почини ещё раз» в шестой подход. Он просит поставить сторожа:

Этот баг возвращается уже несколько раз: настройки уведомлений то есть в ответе профиля, то пропадают.
Сделай строго по порядку:

Сначала напиши маленький автотест, который проверяет, что в ответе профиля есть поле настроек уведомлений и оно не пустое. Назови тест по имени бага.
Запусти тест. Он должен упасть - это докажет, что баг реальный, а не выдуманный.
Теперь почини баг. Важно: проверь ОБА режима - и рабочий, и демо. Они должны возвращать одинаковый набор полей.
Снова запусти тест. Теперь он должен пройти.
Перед тем как сказать «готово» - прогони все тесты целиком, чтобы убедиться, что ты не сломал что-то соседнее.

Чек-лист: проверь по-настоящему, не на словах

ИИ радостно заявляет «всё работает, я проверил»? Не верь на слово. Попроси его пройти по порядку: сначала машина, потом глаза.

1. Сначала прогон тестов. Упали - это баг номер один, без всяких рассуждений. Машина не спорит.
2. Потом проверка сборки. Код вообще не собирается - это важнее любого красивого мнения.
3. И только теперь - обзор кода глазами, держа в уме известные слепые зоны (два пути, забытые поля).
4. На каждый найденный баг - новый тест. Чтобы в следующий раз поймалось само, без тебя.

Частые ошибки новичка

• Верить «я проверил, всё работает». Та же голова, те же слепые зоны. Проси прогнать тест.
• Просить «почини ещё раз» по кругу. Без сторожа баг вернётся в шестой раз. Проси тест на баг.
• Покрывать тестами весь проект. Долго и бесполезно. Тест нужен там, где реально ломалось.
• Забывать про второй путь. Починил рабочий режим - сразу проси проверить и демо-режим.
• Делать обзор кода до прогона тестов. Сначала бездушная машина, потом мнение ИИ. Не наоборот.
• Писать тест после починки - или не писать вовсе. Лучше сначала тест (он падает), потом починка (тест проходит).