За год в шести направлениях собран 51 продукт: от мультиагентного отдела маркетинга Marqly и контроля качества звонков VoiceIQ до социальной инфраструктуры BIOM и ИИ-куратора для онлайн-школ «Ясно». Вопрос, который задают чаще всего: как один человек с небольшой командой выпускает продукты в таком темпе.
Ответ не в скорости печати. Он в том, что разработка перестала быть последовательной цепочкой и стала параллельным конвейером агентов, у каждого из которых узкая зона ответственности и проверяемый результат.
Что ломается в обычном подходе
Классический маршрут «идея → ТЗ → дизайн → разработка → тест → релиз» имеет одно свойство: каждая стадия ждёт предыдущую. Пока пишется ТЗ, разработчик простаивает. Пока верстается макет, тестировщику нечего делать. На дистанции в 51 продукт это не масштабируется - не хватит ни людей, ни календаря.
Второе свойство ещё неприятнее: ошибка, допущенная на первой стадии, всплывает на последней. Неверно понятая бизнес-задача обнаруживается на приёмке, когда переделывать дорого.
Архитектура мультиагентного пайплайна
Рабочая схема, к которой мы пришли на MVP-Factory - фабрике из девяти агентов и оркестратора:
- Оркестратор. Единственный компонент, который держит цель целиком. Разбивает задачу, раздаёт подзадачи, принимает результаты и решает, что переделать.
- Агент-аналитик. Превращает сырую формулировку заказчика в измеримые требования: кто пользователь, какое действие считается успехом, какие данные нужны.
- Агент-архитектор. Выбирает стек и рисует границы модулей. Его главный вклад - сказать «этого делать не нужно».
- Агенты-исполнители. Несколько параллельных потоков: интерфейс, серверная логика, интеграции, данные. Работают одновременно, потому что архитектор заранее развёл зоны.
- Агент-критик. Отдельная роль, задача которой - опровергнуть результат. Не «проверить», а именно попытаться сломать. Это ключевая деталь: проверяющий с установкой «найди подтверждение» пропускает почти всё.
- Агент-интегратор. Собирает куски, гоняет сквозной сценарий и отдаёт человеку то, что уже работает.
Один агент, который «умеет всё», всегда проигрывает пяти агентам с узкими ролями и жёсткой приёмкой между ними
Вайб-кодинг - это не «код без чтения»
Термин многих смущает. На практике вайб-кодинг - это работа на уровне смысла и результата, а не синтаксиса: вы формулируете, что должно происходить и как проверить, что это происходит. Код становится расходным материалом.
Условия, при которых это действительно работает:
- Есть проверяемый критерий готовности. Не «сделай красиво», а «форма отправляет заявку в CRM, при ошибке показывает текст ошибки, поля валидируются».
- Каждый шаг запускается. Прототип, который нельзя открыть в браузере через двадцать минут работы, - это не прототип.
- Ревью остаётся за человеком в трёх точках: модель данных, работа с деньгами и всё, что касается персональных данных. Здесь цена ошибки не измеряется временем.
Путь от идеи до прототипа за 2-3 часа
Разложенный по часам маршрут, который повторяется от продукта к продукту:
| Отрезок | Что происходит | Результат на выходе |
|---|---|---|
| 0:00-0:30 | Разбор задачи, один пользовательский сценарий, критерий успеха | Одна страница требований |
| 0:30-1:00 | Схема данных и границы модулей | Список сущностей и экранов |
| 1:00-2:00 | Параллельная сборка интерфейса и логики | Кликабельный прототип на реальных данных |
| 2:00-2:30 | Прогон агента-критика, правки | Список найденных дыр и закрытых из них |
| 2:30-3:00 | Деплой на статику или платформу | Рабочая ссылка, которую можно показать |
Важная оговорка: за три часа получается прототип, а не продукт. Разница между ними - нагрузка, безопасность, поддержка и всё то, что делает систему пригодной для боевой эксплуатации. Но прототип за три часа меняет экономику проверки гипотез: становится не страшно выбросить.
Что мы поняли на дистанции в 51 продукт
- Узкое место - приёмка, а не генерация. Сгенерировать можно сколько угодно. Тормозит проверка, поэтому в неё и вкладываются агенты-критики.
- Спецификация дороже кода. Хорошо сформулированные требования переживают три смены стека. Код - нет.
- Параллелить нужно по данным, а не по задачам. Если два агента правят одну сущность, вы получите конфликт, который дороже последовательной работы.
- Логи агентов - это актив. По ним видно, где формулировка была двусмысленной, и следующая задача ставится точнее.
- Из 51 продукта в боевую эксплуатацию уходит меньшинство - и это нормально. Смысл конвейера в том, чтобы дешёво отсеивать, а не в том, чтобы всё довести до релиза.
С чего начать у себя
Возьмите одну задачу, которую откладываете третий месяц. Сформулируйте критерий готовности одной фразой, разбейте на четыре роли - аналитик, исполнитель, критик, интегратор - и пройдите цикл целиком за один вечер. Первый прогон покажет, где именно у вас теряется время: почти всегда это неточная постановка, а не техника.