Баги вайб-кодинга: что проверять, если вы не читаете код

Почему баги вайб-кодинга группируются

Агент оптимизирует тот путь, который вы описали. Вы описываете то, что должно происходить, поэтому основной сценарий собирается тщательно, а всё вокруг него — правдоподобно. Ключевое слово здесь «правдоподобно»: код компилируется, экран отрисовывается, а предположения никто не сверял с реальностью.

Именно поэтому сбои предсказуемы. Они всегда на границах описания.

Четыре группы багов — в том порядке, в каком они дают о себе знать

• Сохранение данных. Экран обновляется, база данных — нет. Перезагрузка выявляет это мгновенно. Перезагружайте страницу после каждой записи, прежде чем чему-либо верить.

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

• Второй аккаунт. Владение, права доступа и видимость выведены из той единственной сессии, в которой приложение и создавалось. Войдите под другим пользователем раньше, чем это сделает кто-то ещё.

Четвёртая группа тоньше: вчерашние функции. Каждая новая инструкция может незаметно сломать то, что уже работало, и старое поведение никто не проверяет, потому что разговор ушёл дальше.

Проверка, которая масштабируется вместе с промптингом

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

Настройка передаёт это в руки агента, поэтому проверка идёт рядом с разработкой, а не превращается в отдельную рутину.

Ничего из этого не требует терминала. Создайте проект в панели TestSprite, опишите проверку обычным языком и укажите на своё приложение. Разработчики в вашей команде при желании могут делать то же самое из командной строки — это описано в репозитории CLI.

Десять минут, которые находят большую часть багов

• Зарегистрируйтесь, выйдите, войдите снова. Самый частый полный отказ — и первое, что делает настоящий пользователь.

• Создайте запись, перезагрузите страницу, убедитесь, что она осталась. Сразу закрывает группу с сохранением данных.

• Отправьте заведомо некорректные данные. Вы проверяете, что операция явно завершается ошибкой, а не проходит молча как успешная.

• Пройдите основной сценарий под совершенно новым аккаунтом. Закрывает группу с правами доступа.

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

Почему один и тот же баг возвращается

Самая частая претензия к такому способу разработки — не в том, что что-то ломается, а в том, что исправление одного снова и снова ломает другое. Это не ошибка модели. Это отсутствие записи.

Каждая инструкция трактуется только относительно текущего состояния кода — и больше ничего. Нет списка поведений, которые уже обязаны продолжать работать, поэтому агент никак не может узнать, что запрошенное изменение противоречит тому, что вы зафиксировали в прошлый вторник. С его точки зрения противоречия нет, потому что прошлого вторника в комнате нет.

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

Прежде чем это выйдет в реальную среду

Как только приложением начнут пользоваться другие люди, проверки должны запускаться на каждое изменение, а не тогда, когда вы о них вспомните.

• GitHub App — это вебхук, который вы настраиваете в панели TestSprite. Он слушает событие деплоя, которое ваш пайплайн и так генерирует, поэтому в репозитории ничего менять не нужно.

• GitHub Actions встраивает этот шаг в ваш собственный workflow и настраивается из терминала.

Пусть проверки запускаются сами

TestSprite — это способ перестать выполнять описанные здесь десять минут проверок вручную. Вы один раз описываете каждый сценарий обычным языком, а TestSprite прогоняет их по вашему приложению после каждого изменения.

Это напрямую снимает то, что больше всего раздражает людей в такой разработке. Записанные проверки — это запись того, что уже обязано продолжать работать, поэтому новая инструкция сверяется с ними, а не трактуется в отрыве от всего. Цикл, в котором исправление одного ломает другое, перестаёт быть нормой.

Здесь не нужен ни терминал, ни файл с тестами. Создайте проект в панели, укажите своё приложение и опишите четыре проверки выше. Разработчики в вашей команде при желании могут делать то же самое из командной строки.