Вайбкодинг (vibe coding) — способ писать ПО, описывая намерение модели: «сделай форму заявки», «добавь вебхук», «почини этот баг», «вынеси конфиг в env». Код появляется быстрее, чем при ручном наборе. Термин закрепился вместе с агентами в IDE, которые не только подсказывают строку, но и сами правят файлы, запускают тесты и итерируют по ошибкам компилятора.

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

Чем вайбкодинг отличается от «просто ChatGPT»

Цикл агента vs фрагмент в чате

Классический чат даёт фрагмент кода, который вы вручную переносите в проект. Вайбкодинг — замкнутый цикл: агент читает репозиторий (или его часть), вносит правки в несколько файлов, запускает npm test / pytest / go test, читает stderr, правит снова. Это ближе к джуниору с доступом к терминалу и git, чем к справочнику по синтаксису.

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

Контекстное окно как скрытое ограничение

Агент «видит» не весь монорепозиторий, а срез. Он может не знать о соглашении в соседнем пакете, о feature flag в конфиге prod-only, о том, что метод process() вызывается из batch-джоба раз в сутки. Вайбкодинг без явного указания контекста (@file, @symbol, ссылка на тикет) — лотерея.

Отличие от low-code

Low-code фиксирует граф и ограничения платформы. Вайбкодинг генерирует произвольный код в вашем стеке. Гибкость выше, предсказуемость ниже. Поэтому low-code иногда безопаснее в узком домене, а вайбкодинг — в кастомной логике при сильном инженерном контуре вокруг.

Где вайбкодинг даёт максимум пользы

Прототипы и spike

Демо для стейкхолдера, проверка гипотезы UX, «оживить» макет за день. Критерий успеха — learn, не maintain. После валидации spike часто выбрасывают или переписывают начисто — и это нормально.

Внутренние инструменты

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

UI-черновики и админки

Таблицы, фильтры, формы на типовых компонентах дизайн-системы. Агент хорошо тянет шаблон, если в репо есть примеры соседних экранов.

Локальные багфиксы с воспроизводимым сценарием

«При пустом поле X падает 500» — при наличии теста или чётких шагов воспроизведения агент часто чинит быстрее, чем человек ищет место падения. Без теста фикс рискован: агент может заглушить симптом.

Слабые зоны метода

Скрытые инварианты домена, которые не записаны в коде: «никогда не списывать остаток ниже резерва», «команда на PLC только из whitelist». Промышленные протоколы, распределённые транзакции, конкурентность, тонкости идемпотентности платежей — агент «додумает» правдоподобно и неверно.

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

Правила, без которых метод опасен

1. Изоляция

Отдельная ветка или git worktree. Не prod-ключи и не копии prod-БД в окружении агента. Для экспериментов — локальный docker-compose с фикстурами. Если агент запускает shell-команды, ограничьте сеть и права на файлы вне проекта.

2. Малый шаг

Одна задача — один дифф, который человек может прочитать за 15–30 минут. Антипаттерн: «сделай целиком модуль оплаты» одним промптом. Разбивайте на контракт API → реализация → тесты → интеграция.

3. Тесты как контракт

Если агент «починил», зелёный CI обязателен. Ещё лучше — test first: вы описываете ожидаемое поведение, агент пишет реализацию. Для UI — хотя бы один e2e на критичный путь.

4. Секреты и персональные данные

Не скармливайте модели то, что нельзя передавать провайдеру по DPA и внутренней политике. Маскируйте дампы, используйте корпоративные endpoints с отключённым обучением, если доступно. Агент любит вставлять «example_key» в реальный конфиг — ловите pre-commit hooks.

5. Архитектурный стоп

Слои, границы модулей, публичные контракты между сервисами, схемы БД с миграциями — решения человека. Агент может набросать обвязку, не принимать решение о безопасности и топологии.

6. Явный контекст в промпте

Указывайте: тикет, ограничения («не трогать пакет billing»), ссылки на аналогичный код («как в UserForm.tsx»), критерий готовности. Шаблон промпта в команде снижает разброс качества.

Фреймворк: можно ли пускать вайбкодинг в продукт

Оцените задачу по пяти осям (1 — низкий риск, 5 — высокий):

Сумма ≤ 12 — вайбкодинг с обычным ревью уместен. 13–18 — только с усиленным ревью (сеньор + security при необходимости). ≥ 19 — агент максимум для черновика spike, в прод идёт ручная разработка по спецификации.

Примеры:

• Лендинг, правка текста кнопки — низкие баллы.
• Внутренний отчёт по CSV — низкие/средние.
• Изменение логики списания со счёта — высокие почти везде.
• Команда на SCADA / станок — максимум на compliance и blast radius.

Рабочий процесс для команды из 5–15 человек

До начала

• Документ AGENTS.md или раздел в CONTRIBUTING: стек, команды тестов, запреты, пример хорошего PR.
• Шаблон промпта в wiki.
• Политика данных: что можно отправлять в облачную модель.

Во время задачи

1. Тикет с acceptance criteria.
2. Ветка feature/JIRA-123-short-name.
3. Промпт с @ на релевантные файлы.
4. Итерации до зелёного CI локально.
5. Self-review по чеклисту (прочитан каждый файл, нет лишних зависимостей).
6. PR с меткой ai-assisted для статистики (не для стыда — для обучения).

На ревью

Ревьюер смотрит не стиль (линтер), а:

• соответствие инвариантам домена;
• граничные случаи и ошибки;
• безопасность (инъекции, authz);
• не сломаны ли соседние сценарии.

Если diff > 400 строк и автор не может объяснить каждую часть — возврат без обсуждения.

После merge

Мониторинг ошибок и метрик 24–48 часов на чувствительных путях. Для критичного — feature flag и канареечный выкат.

Метрики: отслеживать ли «вайб» отдельно

Полезно:

• Доля PR с меткой ai-assisted — не как KPI «больше = лучше», а для корреляции с defect rate.
• Размер диффа и время ревью — если AI-PR в среднем в 2 раза больше и дольше ревьюятся, процесс надо ужимать.
• Revert rate в течение 7 дней после merge.

Бесполезно:

• количество принятых автодополнений;
• «экономия строк» без связи с lead time.

Антипаттерны вайбкодинга

Vibe-driven architecture. «Сделай как знаешь» на новом сервисе — через месяц три несовместимых подхода к ошибкам и логированию.

Prompt chaining без коммитов. Десять итераций в одной сессии без промежуточных коммитов — невозможно понять, что сломалось.

Слепое доверие зелёным тестам. Тесты тоже могли быть сгенерированы тавтологически.

Копирование prod-данных в промпт. «Вот JSON реального заказа, почини» — утечка.

Один агент на весь монорепо. Разбивайте scope; иначе контекст теряется.

Отсутствие парного разбора. Джун вайбкодит solo на платёжке — риск; минимум периодическое pairing с сильным инженером.

Сравнение с классической разработкой

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

Когда начинать не с вайба, а со спецификации

• Интеграции с деньгами, персональными данными, медициной, промышленной безопасностью.
• Изменения схемы БД с невозможностью простого rollback.
• Публичные API с внешними потребителями — сначала контракт и версионирование.
• Performance-critical пути без профилирования.

В этих случаях агент уместен после того, как человек зафиксировал контракт, инварианты и план тестов. Порядок «спека → тесты → вайб-реализация → ревью» часто быстрее, чем «вайб → переделка → снова вайб».

Обучение команды: первые две недели

Неделя 1 — только read-only. Разработчики используют агента для объяснения кода, генерации тест-кейсов, черновиков документации. Без права merge без ревью сеньора. Цель — привыкнуть к верификации, а не к слепому принятию.

Неделя 2 — изолированные задачи. Каждый берёт один тикет из «зелёной зоны» (внутренний скрипт, UI по макету, мелкий баг с тестом). Обязательный разбор на общем созвоне: что сработало в промпте, где агент ошибся.

После двух недель соберите «библиотеку промптов» из удачных примеров — это снижает разброс между сильными и слабыми пользователями агента сильнее, чем смена модели.

Шаблон промпта для команды

Контекст: тикет PROJ-123, ветка feature/PROJ-123
Задача: [одно предложение]
Ограничения: не менять пакеты X, Y; следовать стилю @SimilarFile.ts
Критерий готовности: зелёный `npm test`, нет новых зависимостей

Копируйте блок в описание каждого AI-assisted PR — ревьюеру проще, а через квартал видна статистика по типам задач.

Итог

Вайбкодинг — рабочий метод для прототипов, внутренних инструментов и изолированных фич при сильном контуре: изоляция, малые диффы, тесты, ревью, политика данных. В продукт с высокой ценой ошибки он входит не как свободный диалог с моделью, а как ускоритель реализации уже принятых инженерных решений. Задайте команде один вопрос перед merge: «Я бы поставил это на прод, если бы написал это сам за весь вечер без агента?» Если ответ «нет, я не до конца понимаю diff» — вайб ещё не закончен, работа инженера только начинается.