Один из авторов, которых я читаю, точно описал то, что я сам замечал, но не формулировал: вайбкодинг с AI-агентами ускорил разработку и одновременно сделал её менее управляемой. Запускаешь агента на задачу, пока он работает — открываешь второй терминал, замечаешь ещё пару вещей, которые тоже неплохо бы поправить. Через час — десяток открытых терминалов, несколько проектов в воздухе, а законченной работы почти нет. Это и есть главная ловушка параллельных задач при вайбкодинге.
Я два месяца работал со сложным проектом, где эта ловушка могла бы меня накрыть. Не накрыла — потому что нашёл рабочую схему. Ниже разберу, что именно изменилось и почему это работает.
Что происходит, когда узкое место смещается
Раньше скорость разработки ограничивал сам программист. Написать, проверить, отладить — это занимало время, и это время автоматически ограничивало, сколько задач можно держать в параллели.
С Claude Code, Codex и другими агентами это ограничение исчезло. Агент пишет код быстро. Пока он пишет — кажется логичным использовать это время и запустить ещё одного агента на соседнюю задачу. Потом ещё одного. Продуктивность как будто растёт: столько всего запущено.
Но узкое место никуда не делось — оно переехало. Теперь это не скорость написания кода, а внимание. Агент может генерировать изменения быстрее, чем ты успеваешь их осмыслить, проверить и принять решение о следующем шаге. Десять открытых терминалов — это не десять параллельных прогрессов. Это десять точек, каждая из которых ждёт твоего решения, и ни одна не доведена до конца.
Автор, которого я упомянул, назвал это точно: раньше узким местом был программист, теперь им становится внимание.
Как план перед реализацией меняет картину
Решение, которое у меня сработало, звучит банально: никакой реализации без утверждённого плана. Не «примерного понимания», не «разберёмся по ходу», а конкретного документа, который лежит в репозитории и к которому можно вернуться в любой момент.
Схема такая. Сначала с агентом прорабатываем план фичи или задачи — задаём вопросы, снимаем неясности, доводим до состояния, когда ни одного открытого вопроса не осталось. Финальный план записываем в документацию проекта. После этого — реализация строго по плану, поэтапно.
Почему это помогает от хаоса с параллельными задачами? Потому что план — это точка остановки. Пока план не готов, следующую задачу не начинаем. Это возвращает то самое ограничение, которое раньше создавала скорость разработки: нельзя бесконтрольно плодить задачи, потому что каждая требует сначала думать, а не сразу делать.
Без плана вайбкодинг похож на ремонт без дизайн-проекта: хочу розетку здесь, нет — чуть правее, а давайте вообще перенесём стену. Розетки появляются, стены двигаются, но квартиры нет.
Связка «мощная модель — рабочая модель»
Отдельный момент, который сильно влияет на качество плана, — выбор модели для каждого этапа.
Планирование я делаю самой мощной и дорогой моделью. На момент написания этой статьи у Claude это Fable 5 на уровне extra high. Дорого? Да. Оправданно? Полностью: план определяет всё, что будет после. Ошибка в плане стоит дороже, чем разница в цене между моделями.
Реализацию делаю моделью попроще — например, Opus 5, тоже на extra high. Она хорошо справляется с задачей, когда задача чётко сформулирована. Именно поэтому порядок важен: сначала думаем дорого, потом делаем эффективно.
За два месяца в сложном проекте с этой связкой серьёзных сбоев не было. Это не значит, что агенты не ошибались — ошибались. Но ошибки оставались в рамках шага, а не разваливали всю конструкцию, потому что конструкция была описана заранее.
Что бы я сделал иначе
Первые недели я работал без этой системы. Запускал агентов по ситуации, правил по ходу, держал несколько веток в голове. Работа шла, но с постоянным ощущением, что что-то важное ускользает.
Потерял время на переделки, которых не было бы с нормальным планом. Несколько раз агент уходил в сторону, потому что задача была сформулирована размыто — и я это замечал только по результату, а не заранее. Каждый такой случай — это час-два на откат и переформулировку.
Если бы начинал сначала, ввёл бы правило «план в документации» с первого дня. Не потому что это какая-то сложная методология — а потому что это буквально то, как работает любой нормальный проект. AI-агенты не отменили базовую логику: сначала думаем, потом делаем. Они просто сделали цену пропуска этого шага выше.
Что с этим делать
Если ты работаешь с AI-агентами и замечаешь, что задач начато много, а закончено мало — скорее всего, проблема не в инструментах.
Несколько вещей, которые можно попробовать сегодня:
- Перед каждой новой задачей делай план в письменном виде. Не в голове — именно в файле, который останется в проекте.
- Не начинай реализацию, пока в плане есть открытые вопросы. Вопрос «разберёмся по ходу» — это скрытая переделка.
- Используй самую мощную модель на этапе планирования, а не реализации. Это контринтуитивно, но именно там она нужна.
- Ограничь количество одновременно активных задач. Один агент в работе — это нормально. Пять параллельных — это уже управление хаосом, а не разработка.
- Фиксируй план в документации проекта, а не в чате с агентом. Чат исчезает, документ остаётся.
Вайбкодинг — мощный инструмент. Но мощность инструмента без управления превращается в хаос быстрее, чем кажется.