У меня за плечами шесть лет в IT, я понимаю, как работает команда разработки, знаю, что такое спринт, DoD и зачем нужен бизнес-аналитик, но всё равно не устояла перед вайбкодингом на “дурачка”.

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

Момент, когда всё сломалось

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

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

А потом подумала: что, если я просто делала это неправильно? И что если я применю свой опыт продакта, не зря же я «ела стекло» с человеческой командой.

Я села и вспомнила, что у нас было: роли, артефакты, приёмки, спринты, а не вот это вот всё: «сделай мне красиво».

Карта проблем: как не надо и как надо

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

  1. Дизайн

👎 Делать дизайн в Cursor, промтами вперемешку с кодом

👍 Использовать отдельные ИИ-инструменты для генерации дизайна — например, Stitch от Google или Claude Design

  1. Разработка

👎 Делать монолитом, просто промтами: «сделай продукт»

👍 Строить слоистую архитектуру:

  • Дизайн
  • Логика
  • Модель данных
  1. Документация

👎 Держать всё «в голове чата» и не фиксировать решения

👍 Вести документы:

  • Продуктовая концепция
  • Архитектура
  • Контракты взаимодействия с описаниями
  • Ридми и внутренние доки
  1. Ревью

👎 Верить Cursor на слово, не проверять, не вовлекаться в проблему

👍 Кросс-ревью: код одного ИИ проверяют ChatGPT и Gemini

  1. Пайплайн — вы точно узнаете это слово 😅 — Cursor любит пайплайны.

👎 Поточная разработка сплошным потоком промтов — такое невозможно дорабатывать и поддерживать

👍 Работа по спринтам:

  • У спринта есть цель, скоуп и DoD
  • Каждый спринт заканчивается приёмкой

Имитация настоящей команды

Каждый специалист — агент с должностной инструкцией.

В настоящей команде никто не нанимает человека «просто делать продукт». У каждого есть роль, требования и зона ответственности. Я сделала то же самое с ИИ: для каждой роли прописала инструкцию, как будто нанимаю сотрудника.

В инструкции агента четыре вещи:

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

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

Кто был в моей команде

Сначала — продакт. Бизнес-контекст, цели, проблемы, ценностное предложение, CJM. Артефакт — продуктовая концепция.

Бизнес-аналитик. Бизнес-логика, пользовательские сценарии, доменная модель. Артефакт — набор пользовательских сценариев.

Архитектор: какие сервисы нужны и как они взаимодействуют. Артефакт — ADR. Следом системный аналитик: контракты взаимодействия, системная логика, модель данных. Артефакт — системная спека.

И только после этого — разработчики, по одному на слой:

  • пользовательский (UX, UI, фронт),
  • логический (бэк),
  • доменный (модель данных).

Также был процесс кросс-ревью со стороны — ChatGPT и Gemini, которые проверяли работу «коллеги» свежим взглядом.

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

Чат с Cursor был моей таск-бордой. Структура папок — базой знаний проекта: инструкции агентов лежали там же, где спеки.

Спринты, приёмка и ретро

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

Но приёмка проверяет продукт, а не процесс. Поэтому в конце каждого спринта я проводила ретро — как в настоящей команде, только человек в ней один.

Инциденты и расследования

Если баг просачивался через приёмку и вылезал позже, я не бросалась его молча чинить. Я заводила инцидент и проводила расследование:

  • Симптом: что сломалось и как это заметили.
  • Локализация: в каком слое проблема. Слоистая архитектура превращает этот вопрос из гадания в проверку по карте.
  • Корневая причина: почему баг вообще появился. Дырка в спеке? Агент вылез за зону влияния? Приёмка не покрыла сценарий?
  • Изменение процесса: что правим, чтобы такой класс багов больше не проходил.

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

Самый неожиданный эффект: инциденты перестали быть стрессом. В хаотичном вайбкодинге каждый баг — лотерея и паника. В процессе с зонами ответственности баг — задача с понятным адресом.

Зачем так заморачиваться?

Можно и не заморачиваться, но если вам нужны:

  • Управляемость Когда что-то идёт не так в монолите, вы начинаете фиксить — и в одном месте исправляется, а в другом падает. Вы не понимаете, где именно проблема, потому что всё связано со всем. Чёткая архитектура и слоистая структура дают вам карту системы. Вы точно знаете, в каком слое копать, что трогать можно, а что нет. Баг перестаёт быть лотереей и становится задачей с понятным адресом.
  • Масштабируемость Любой живой продукт растёт: новые фичи, новые пользователи, новые требования. Монолит под это не заточен — расширить его, не сломав то, что уже работает, почти невозможно. Модульная система с чёткими границами между слоями позволяет развивать продукт без страха. Новый модуль добавляется в свой слой и не тянет за собой остальное. Продукт можно растить итерационно — именно так, как и должен жить живой продукт.

Лучше заморочиться на старте и настроить как надо, чем потом морочиться в процессе, в итоге выгореть и сказать «не работает ваш вайбкодинг».

Сколько процесса нужно вашей задаче

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

  • Сколько это будет жить? Поделка на выходные или продукт на месяцы?
  • Кто этим пользуется? Только я — или чужие люди?
  • Есть ли внутри данные и логика?
  • Что будет, если оно сломается?
  • Будет ли оно расти?

Чем больше ответов «второе», тем больше процесса нужно. У меня получилось три уровня.

Уровень: Elementary

Лендинг, бот-визитка, скрипт для себя, прототип. Можно ограничиться концептуальными доками и риалтайм-кодингом: открыл агента — наговорил задачу — принял — закрыл агента.

Уровень: Intermediate

Продукт для себя или узкого круга, MVP с настоящей логикой. Здесь уже должен появиться минимальный набор документов:

  • Концепция: что делаем, зачем и какую проблему решаем. Хватит одной страницы.
  • Профиль пользователя: кто и в какой ситуации будет этим пользоваться.
  • Логика: если сценарий один и простой — это просто один документ с логикой.
  • Модель данных: что храним и где.
  • Интеграции: если есть — какие и как устроены.

Ролей и спринтов ещё нет, но дисциплина маленьких задач с проверкой после каждой — уже есть.

Уровень: Upper-Intermediate

Система: несколько слоёв, модель данных, чужие пользователи, долгая жизнь и планы на развитие. Вот здесь — всё из этой статьи: команда агентов с зонами влияния, спека как источник правды, спринты с приёмкой, ретро, инциденты. Моя платформа — этот случай, поэтому и процесс такой.

Уровни перетекают друг в друга, и это нормально. Можно навайбкодить прототип на уровне 1, чтобы нащупать, что вообще нужно, — а когда идея затвердела, формализовать её в концепцию и строить дальше по процессу. Главное — заметить момент перехода: как только у поделки появились данные, пользователи и завтрашний день, она стала системой. У вайб-кода без процесса есть документированный потолок: через несколько месяцев жизни проекта техдолг съедает всю скорость, которую вы выиграли на старте.

Best practices

Есть базовые принципы, которые использует хорошая разработка:

  • Spec-driven development — это когда источник правды — не код, а спецификации. У нас в разработке это называлось: «точить ножи» — когда мы сначала думаем, а потом делаем. Даже если кажется: «что думать, делать надо!»
  • Divide and conquer: чтобы хорошо управлять, нужно хорошо разделить. Anthropic в гайде по агентному кодингу советует разделять исследование, планирование и исполнение — иначе агент быстро и уверенно решает не ту задачу.
  • Atomic tasks — маленькие задачи вместо «сделай фичу», атомарность — это значит неделимая. Это повышает управляемость.
  • Cross review — решает проблему «замыленности решения», да и у ИИ она есть. Он зацикливается на своих убеждениях и прошлых решениях.

К 2026 году около 41% кода в мире генерируется ИИ. Выигрывают не те, кто делает больше, а те кто делает умнее. Та что давайте смарткодить 😉, чтобы наши дети потом нам не сказали “навайбкодили тут, а нам разбтраться”.

А если хотите вместе повайбкодить, у меня есть индивидуальная программа по вайбкодингу, почитать можно тут.