Постановка: что считать «MVP за выходные»
Формат жёсткий: пятница вечер — воскресенье вечер, готовый продукт с одним рабочим сценарием. Не прототип на бумаге, а деплой, до которого может дойти реальный пользователь и пройти путь от регистрации до результата.
Ключевая ошибка, которую совершают почти все новички в вайбкодинге, — начинают с кода. Правильный порядок обратный: сначала письменная постановка на страницу, где зафиксированы (1) один сценарий использования, а не пять, (2) критерий готовности — что именно должно работать в воскресенье вечером, (3) явный список того, что НЕ входит в MVP. Без последнего пункта агенты обычно начинают «улучшать» и тащат в проект авторизацию через соцсети, тёмную тему и экспорт в PDF — то, что не нужно для проверки гипотезы.
Хороший тест постановки: если вы не можете описать сценарий одним предложением вида «пользователь заходит, делает X, получает Y» — рано переходить к разбиению задач.
Разбиение: от постановки к тикетам для агентов
ИИ-агенты хорошо работают с узкими, изолированными задачами и плохо — с расплывчатыми «сделай нормальный бэкенд». Практика, которая обычно даёт результат: разбить продукт на 6–10 вертикальных срезов (не «фронт», «бэк», «база», а «регистрация», «создание записи», «список записей», «оплата-заглушка»), и на каждый срез — отдельный агент или отдельная сессия с чётким контрактом входа/выхода.
Критерии хорошего тикета для агента: - Явный DoD (definition of done) — что проверить руками, чтобы закрыть задачу. - Зафиксированный интерфейс на стыке (формат API-ответа, схема таблицы) — иначе два агента придумают два разных контракта и придётся чинить интеграцию вручную. - Ограничение по стеку и версиям библиотек — агенты любят предлагать «более современный» пакет, который на практике ломает сборку.
Практика, которая обычно окупается: держать один агент «архитектором» — он не пишет код, а только держит общую схему данных и API-контракты, и раздаёт куски остальным. Без такой роли параллельные агенты обычно расходятся: одна и та же сущность в разных модулях называется по-разному, и вечер субботы уходит на согласование имён полей.
Оркестрация: как агенты не мешают друг другу
Три модели работы, которые встречаются на практике:
1. **Последовательная** — один агент за другим, с ревью между шагами. Медленнее, но почти не даёт конфликтов. 2. **Параллельная по файлам** — агенты работают в разных директориях/модулях одновременно, интеграция — отдельным шагом в конце. 3. **Оркестратор + воркеры** — один агент планирует и раздаёт подзадачи, воркеры отчитываются, оркестратор мёрджит.
Для выходного MVP параллельная модель обычно рабочая, если заранее зафиксированы границы файлов и контракты данных. Чек-лист для оркестрации:
- Git-ветка на каждый крупный срез, мёрдж — только после прогона тестов/ручной проверки.
- Единый файл с решениями (какой стек, какие библиотеки, какие соглашения по именованию) — агенты его читают перед стартом задачи, иначе один поставит одну версию фреймворка, второй — другую.
- Контрольная точка в середине субботы: ручная проверка, что интеграция вообще возможна, а не откладывание всего на воскресный вечер.
- Явный человек-ревьюер на границах модулей — агент не видит общей картины и может пропустить, что поле уже занято под другой смысл.
Результат и выводы
Обычно за такой выходной удаётся получить рабочий сценарий «от и до», но с заметным техническим долгом: отсутствие обработки ошибок, дублирование логики между модулями, минимальные тесты. Это нормально для MVP — цель была не эталонный код, а проверка гипотезы на реальных пользователях.
Практические выводы:
- Время, потраченное на постановку в пятницу вечером, окупается — час на письменное ТЗ обычно экономит несколько часов на субботние переделки.
- Агенты — не замена архитектурному решению, а исполнители при нём; чем расплывчатее контракт, тем больше ручной интеграции в конце.
- Закладывайте явный бюджет времени на интеграцию (обычно порядка 20–30% от общего времени) — это не потерянное время, а неизбежная часть параллельной разработки.
- Фиксируйте, что осталось за скобками MVP, отдельным списком — на понедельник, а не тащите в спринт выходного дня.
Итог: скорость даёт не количество агентов, а качество разбиения задачи до того, как агенты вообще начали писать код.
