Один навык, который убил 90% моих проблем с вайбкодингом

Полгода назад я был на грани того, чтобы признать: вайбкодинг — хайп, который не работает.

Каждый проект шёл по одному сценарию. Cursor генерит код, MVP взлетает за вечер, я радуюсь. А через два дня — регрессия за регрессией. Добавляю фичу — отваливается авторизация. Чиню авторизацию — ломается стейт корзины. Чиню корзину — падает то, что работало неделю назад и к чему я вообще не прикасался.

Классический эффект домино в кодовой базе, которую ты не писал и не до конца понимаешь.

Начал грешить на модели. Переключался между Claude и GPT-4. Экспериментировал с температурой, переписывал системные промпты. Добавлял контекст на три страницы, описывал архитектуру, указывал constraints. Помогало слабо.

Кульминация случилась на простом pet-проекте: интернет-магазин — каталог, корзина, чекаут. К концу третьего дня разработки корзина некорректно считала сумму, кнопка сабмита не триггерила хендлер, а половина товаров терялась при ре-рендере. При этом я не трогал ни один из этих компонентов — просто добавлял фильтры в каталог.

Сидел в два ночи и думал: может, все эти истории про «собрал SaaS за выходные» — просто селективная демонстрация успешных кейсов?

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

Какие тесты? Я вайбкодер, а не разработчик. Тесты — это оверхед для команд с CI/CD и код-ревью.

Он объяснил идею, и она оказалась до смешного простой в контексте LLM.

Ты просишь агента генерить не просто имплементацию, а имплементацию + тестовое покрытие ключевых сценариев. Unit-тесты на бизнес-логику, интеграционные на критические флоу. Когда добавляешь фичу и что-то ломается — тесты сразу показывают, какой именно инвариант нарушен. Не ты дебажишь вслепую, а тест-раннер говорит: «calculateTotal() ожидал 500, получил 300, смотри строку 47».

И главное — агент тоже видит этот output. Кидаешь ему failed tests, и он получает точную информацию для фикса. Не галлюцинирует причину, не ломает соседние модули, а чинит конкретный кейс.

Переписал тот же магазин с тестами на ключевые функции: расчёт суммы, валидация стока, создание ордера, флоу авторизации.

Результат меня удивил.

Добавляю фильтры — тесты зелёные, корзина работает. Рефакторю компонент карточки — зелёные, регрессии нет. Один раз тест покраснел на edge case — скинул output агенту, он за минуту пофиксил именно тот метод, который сломал. Без итеративного «попробуй ещё раз», без каскадных поломок.

По сути, тесты стали вторым feedback loop для агента. Первый — мой промпт. Второй — автоматическая проверка того, что уже работало.

Тот навык, которого мне не хватало — автотесты как контракт между мной и агентом.

Это катастрофически недооценённый паттерн в вайбкодинге. Комьюнити обсуждает промпт-инжиниринг, выбор моделей, Cursor Rules, RAG-контексты. Но почти никто не говорит про тесты. Потому что кажется, что это из мира «настоящей» разработки, где есть QA и пайплайны.

А на деле это решает ~90% проблем с регрессиями. Тесты — не оверхед, а страховочная сетка, которая ловит агента каждый раз, когда он нарушает существующие контракты. И сразу даёт ему данные для исправления.

Без тестов ты в позиции «надеюсь, ничего не сломалось». С тестами — у тебя детерминированный фидбек на каждое изменение.

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