SaaS в одно лицо за 48 часов - полный боевой пайплайн вайбкодинга

Когда Андрей Карпатый запустил термин "вайбкодинг", интернет разделился на два лагеря. Одни решили, что теперь любой человек с улицы может надиктовать голосом сложный сервис, а вторые - что индустрия утонет в неработающем коде.

SaaS в одно лицо за 48 часов - полный боевой пайплайн вайбкодинга

Правы оказались и те, и другие.

Если открыть чат и написать "сделай мне аналог Notion с авторизацией и платежами", вы получите сломанную поделку, которая рассыплется на третьем файле. Модель забудет, что писала утром, сотрет половину базы данных и разведет зоопарк несовместимых библиотек.

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

Мы обкатали этот пайплайн на живом проекте. Разбираем инструменты, рабочий файл правил и пошаговый цикл без магии и воды.

Кстати, если вы хотите протестировать все самые свежие модели уровня Claude Sonnet 5, GPT-5.6 или Gemini 3 в одном удобном месте и сравнить их ответы без костылей с иностранными картами - на платформе SYNTX.AI это можно сделать за пару кликов.

По промокоду NEIROSKUF дадут 15% скидку на все тарифы.

Смена ролей или почему вы больше не пишете код

Раньше восемьдесят процентов времени уходило на моторику: вспомнить синтаксис, полистать документацию к чужому API, написать типичный CRUD и настроить миграции.

В боевом вайбкодинге человек не набирает код руками. Человек делает три вещи:

  1. Пишет архитектурные спецификации и граничные условия.
  2. Проверяет готовые диффы в Git перед фиксацией.
  3. Задает правила автоматического контроля (тесты и линтеры).

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

Файл CLAUDE.md / .cursorrules, который спасает проект

Без этого файла любой агент (Cursor, Windsurf или консольный Claude Code) превратит репозиторий в кашу за три итерации.

Вот рабочий конфиг, который мы кладем в корень проекта на стеке FastAPI, PostgreSQL и TypeScript:

# Инженерные правила проекта ## 1. Архитектурный каркас - Архитектура строго слоистая: API (роутеры) -> Сервисы (бизнес-логика) -> Репозитории (доступ к данным). - Запрещено дергать базу данных напрямую из роутеров API. - Все входящие и исходящие данные валидируются через Pydantic v2. - Использование типа Any запрещено. ## 2. Контроль зависимостей - Запрещено добавлять новые пакеты в requirements.txt без прямого запроса пользователя. - Использовать только инструменты из уже установленного стека. ## 3. Правило TDD (Test-Driven Development) - Перед написанием любой фичи ОБЯЗАТЕЛЬНО создать падающий тест в tests/. - Задача считается сданной только тогда, когда команда pytest tests/ возвращает 100% успеха. - Изменение схемы базы ОБЯЗАНО сопровождаться миграцией Alembic. ## 4. Дисциплина правок - Не переписывать файлы целиком, если меняется одна функция. - Не удалять существующие комментарии и тесты. - Перед правками вывести список файлов, которые будут затронуты.

Этот файл работает как строгий сеньор: агент перечитывает его перед каждым действием и физически не может применить несогласованный костыль.

Боевой цикл: фича за двадцать минут

Любая задача - от авторизации до биллинга - прогоняется по четырехшаговому кругу.

1. Спецификация вместо слепого кода

Пишем в чат бизнес-требование:

"Нужно добавить суточные лимиты на вызовы API в зависимости от тарифа пользователя."

Первое правило: запретить модели сразу лезть в код. Требуем создать файл SPEC.md:

  • Структура таблиц и новые поля.
  • Схемы входных и выходных JSON-ответов.
  • Поведение на границах (что делать, если лимит кончился ровно в 23:59).

Вычитка текста спецификации занимает две минуты. Если логика кривая - правим текст, а не переписываем три тысячи строк кода.

2. Тесты до реализации

Команда агенту:

"По файлу SPEC.md напиши интеграционные тесты для эндпоинта проверки лимитов. Код реализации пока не пиши."

Агент создает tests/test_rate_limits.py. Запускаем pytest в терминале - тесты закономерно падают с кодом 404. Точка проверки готова.

3. Автономная реализация через консольного агента

Даем команду консольному агенту (Claude Code или Aider):

"Реализуй логику по SPEC.md так, чтобы все тесты в tests/test_rate_limits.py стали зелеными."

Агент работает автономно:

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

4. Контроль диффа и коммит

Человек открывает git diff. Наша задача - не выискивать пропущенные запятые, а убедиться, что агент не зацепил соседние модули и не нарушил структуру слоев.

Дифф чистый - делаем коммит:

git commit -m "feat(billing): rate limits and tier quotas"

Следующая задача.

Три грабли, на которых спотыкаются новички

  • Если проект запустился и не упал в консоли, это не значит, что он работает. Без тестов каждая вторая правка незаметно ломает то, что вы написали утром.
  • Агенту проще подключить чужой пакет на три мегабайта, чем написать функцию из десяти строк. Жесткий запрет на новые зависимости в файле правил спасает от раздувания проекта.
  • Если вы перестаете понимать, что именно агент запушил в репозиторий, через 48 часов проект превратится в неуправляемого монстра.

Вайбкодинг - это не отказ от программирования.

Это перенос центра тяжести. От механического набора текста в редакторе к формулированию архитектурных правил, контролю спецификаций и верификации результата.

SaaS в одно лицо за 48 часов - полный боевой пайплайн вайбкодинга
10