Точность вайб-кодинга — это измерение, а не свойство модели
Две команды на одной и той же модели получают совершенно разные результаты, потому что точность на том уровне, который вас волнует, определяется тем, что происходит после генерации. Кто-нибудь вообще проверил результат? По какому эталону? Как быстро неверный результат вернулся на исправление?
При такой постановке вопрос «какая модель точнее» превращается в вопрос «как устроена моя обратная связь» — а это уже то, чем вы управляете.
Что стоит измерять
Происходит ли описанное поведение
Единственное определение «правильно», которое переживает встречу с пользователем.
Измеряется прогоном сценария, а не чтением кода.
Работает ли ещё вчерашнее
После первой недели частота регрессий важнее, чем точность с первой попытки.
Примерно одно из пяти изменений функциональности ломает то, что раньше работало.
Сколько времени уходит до верного результата
Число попыток до зелёного полезнее, чем «прошло или не прошло» с первого раза.
Оно отражает то, что вы реально ощущаете: сколько занимает один круг цикла.
Ловушка: тесты, написанные тем же автором
Очевидный способ измерить точность — попросить агента написать тесты и посмотреть, проходят ли они. Получается число, которое почти всегда высокое и почти ничего не значит. Тест, выросший из тех же предпосылок, что и реализация, согласуется с ней по построению — в том числе там, где оба ошибаются.
Измерению точности нужна независимая проверка. Нечто, что прогоняет продукт по задуманному поведению, а не по тому, как код представляет сам себя.
Как настроить измерение
Опишите обычным языком сценарии, которые задают «правильно» для вашего продукта, — до следующей порции изменений. Прогоните их на развёрнутом приложении. Первый прогон даёт базовую линию, каждый следующий — сигнал о регрессиях.
Терминал для этого не нужен. Создайте проект в панели TestSprite, опишите проверку обычным языком и укажите на своё приложение. Разработчики в вашей команде при желании могут делать то же самое из командной строки — подробности в репозитории CLI.
Факт, который стоит знать
В публичном рейтинге, где кодовые агенты собирали одно и то же приложение, самая дешёвая модель в подборке выдала самое корректное приложение — при наличии цикла проверки и вдвое дешевле самого дорогого участника. Интересен здесь не сам рейтинг. Интересно, что цикл оказался важнее модели, — а это прямо противоположно тому, как обычно идёт разговор о точности.
Зачем на самом деле нужно это число
Цифры точности обычно собирают, чтобы ответить на вопрос, которого никто не задавал: хороша ли модель. Полезный вопрос куда уже: можно ли влить это изменение.
Это меняет и само измерение. Вам не нужна оценка по всему продукту — вам нужно знать, сломало ли это изменение что-то, что работало до него. Несколько проверок по важным сценариям, прогнанных на развёрнутой сборке, отвечают на это за минуты. Полноценный бенчмарк отвечает на другой вопрос и за неделю.
Меняется и смысл плохого числа. Падающая точность в бенчмарке — это любопытно. Конкретный сценарий, который вчера работал, а сегодня нет, — это повод действовать, и именно второе не даёт проблеме дойти до пользователей.
Сделайте измерение непрерывным
Разовое измерение рассказывает об одном моменте. Точность — свойство непрерывного процесса, поэтому проверки должны идти на каждое изменение.
Путей два, и выбор по сути сводится к тому, чей это пайплайн. Подключение GitHub App из панели не требует вообще никаких правок в репозитории, потому что он реагирует на деплой, который ваша сборка и так выдаёт. А добавленный GitHub Actions -шаг помещает проверку в репозиторий, где её ревьюят наравне с остальной сборкой.
Как превратить точность в то, что вы измеряете
TestSprite — это та самая независимая проверка, которой требует измерение. Он прогоняет ваш развёрнутый продукт по описанному вами поведению, а не по тому, как код представляет сам себя, — именно это делает число осмысленным, когда и реализация, и тесты к ней пришли от одного агента.
На практике вы один раз описываете сценарии, которые задают «правильно» для вашего продукта, и дальше они запускаются на каждое изменение. Первый прогон — ваша базовая линия. Каждый следующий отвечает на вопрос, который у вас действительно есть: сломало ли это изменение то, что работало вчера.
Так у вас появляются два числа, которые стоит отслеживать: частота регрессий на изменение и число попыток до возврата к зелёному. Оба сдвигаются, когда цикл становится короче, и ни одно нельзя накрутить, написав больше тестов.
Какая модель точнее всего для вайб-кодинга?
Для большинства команд это неверный вопрос. Разброс, который вносит сам факт проверки, больше разброса между актуальными передовыми моделями.
Можно ли измерять точность, не написав ни одного теста?
Да. Опишите сценарии обычным языком и запускайте их на приложении. Вы измеряете поведение, а чтобы наблюдать поведение, тестовый код не нужен.
Какое число точности считать хорошим?
Единого полезного ориентира для разных продуктов нет. Следите за собственной динамикой: частота регрессий на изменение и число попыток до верного результата. Оба показателя должны снижаться по мере того, как цикл становится короче.
Означает ли большее покрытие большую точность?
Не обязательно. Покрытие считает, что было затронуто, а не то, верными ли были ожидания. Большой набор сгенерированных тестов может показывать высокое покрытие поверх неверных предпосылок.
Как часто повторять измерение?
На каждое изменение, автоматически. Точность, измеренная по расписанию, рассказывает о расписании, а не об изменении, которое что-то сломало.
Точность — это ваш цикл, а не ваша модель.
Точность вайб-кодинга — то, что вы измеряете на собственном продукте: происходит ли описанное поведение, работает ли ещё вчерашнее, сколько времени уходит до верного результата. Используйте независимую проверку вместо тестов, написанных тем же автором, и измеряйте на каждом изменении.