Я руководитель проектов и у меня есть команда разработки продуктов. Аналитики исследуют и анализируют новые фичи, пишут спецификации. Есть разработчики и тестировщики. Есть DevOps, который чинит CI и выкатывает релизы. И даже есть технический писатель анализирует изменения и обновляет документацию.

Обычная продуктовая команда разработки.

Только людей в этой команде нет.

Все исполнители — AI-агенты…

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

Современные AI-агенты способны выполнять работу разных инженерных ролей, так почему бы не управлять ими как полноценной командой? А для управления использовать те же подходы, которыми мы давно управляем человеческими командами: Kanban, Scrum, Agile, Definition of Done, декомпозиция, pipeline, review, escalation.

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

Контекст: Реальный продукт, а не упражнение на todo-list

Эксперимент родился не в вакууме. Я работал над продуктом meetwise.ru — сервис для обработки встреч: запись или загрузка встречи, транскрипция, AI-анализ, протокол, задачи, решения, экспорт в документы, видео встречи и дальнейшее развитие в сторону project memory и управления результатами встреч.

Но в этой статье сам продукт не главный герой.

Нам сейчас важен масштаб контекста: это был не учебный todo-list и не демо «сделай мне landing page». В проекте одновременно велась работа по нескольким направлениям:

• backend;

• frontend;

• auth;

• S3 upload;

• обработка видео;

• AI pipeline;

• очереди;

• биллинг минут;

• анонимные пользователи;

• LiveKit-видеовстречи;

• CI/CD;

• мотниторинг;

• документация;

• админка;

• мобильный UI.

То есть всё то, что быстро превращает одиночный AI-чат в хаос, потерю контекста, несвязанность модулей и архитектурных решений.

Агент может написать код, но:

• не понять исторический контекст решения;

• не учесть существующий инвариант;

• забыть про тесты;

• сломать соседний сценарий;

• не обновить документацию;

• создать diff без нормального объяснения;

• оставить человека разбирать CI failure вручную;

• потерять нить после нескольких follow-up сообщений.

В какой-то момент я понял: проблема уже не в том, умеет ли агент писать код. Проблема в том, что у него нет нормального инженерного процесса вокруг.

Идея: относиться к AI-агентам как к проектной команде

Я руководитель проектов и архитектор. Поэтому мне естественно мыслить не только кодом, но и системой работы.

Для работы в реальной человеческой команде разработки я никогда не управлял процессом через один длинный Telegram-чат.

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

• заводил backlog;

• договаривался с командой о стадиях;

• описывал Definition of Done;

• разделял discovery и implementation;

• обязательный review;

• все изменения шли только через PR;

• подключал CI;

• отдельно контролировал документацию;

• договаривался об escalation path для проблемных задач.

Вопрос: почему с AI-агентами должно быть иначе? Так я пришёл к идее AI-команды на Kanban-доске. Не в смысле «у меня есть виртуальный Вася-разработчик и виртуальная Маша-тестировщик». А в смысле:

• каждая стадия работы имеет свою цель,

• свой prompt,

• свой контекст,

• свой критерий завершения,

• свой следующий шаг.

На уровне процесса это действительно начинает напоминать команду:

РП / архитектор      → ставит задачу, принимает решения, вмешивается при сбоях
AI-аналитик          → исследует код и формулирует change
AI-архитектор        → оформляет design/spec
AI-разработчик       → реализует
AI-тестировщик       → запускает проверки и чинит тесты
AI-DevOps            → разбирает CI/deploy failures
AI-документатор      → обновляет документацию по diff

Технически всё это выполняют AI coding agents. Но организационно они встроены в pipeline.

Vibe Kanban как диспетчерская

Для визуального и операционного слоя я использовал Vibe Kanban.

Мне были важны несколько возможностей:

• задачи на Kanban-доске;

• запуск coding agents из карточек;

• отдельные git worktrees;

• streaming logs;

• follow-up сообщения агенту;

• связь задачи с workspace;

• возможность параллельной работы;

• UI, где видно, что происходит.

Ключевой момент — worktrees.

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

Снаружи это выглядит как доска:

Backlog → To do → Spec → Apply → Verify → Test → Archive → Ship → Done
                                      ↘ Need Attention

Но смысл колонок отличается от классического «To do / In progress / Done». Каждая колонка — это стадия автоматизированного engineering pipeline. Карточка на доске — это не напоминание человеку. Это активный процесс.

Когда карточка попадает в определённую колонку, оркестратор понимает, какую работу должен запустить.

Почему Vibe Kanban не решал все вопросы

Vibe Kanban дал мне важные примитивы:

task, workspace, session, process, follow-up, worktree

Но мне нужен был более конкретный процесс:

issue → stage → agent run → validation → next stage → PR → CI → merge → docs

То есть Vibe Kanban был хорошей диспетчерской, но не готовым workflow engine под мой проект. Поэтому поверх него я написал Python-оркестратор. Его задача — не писать код. Его задача — управлять состоянием:

• читать карточки на доске;

• понимать текущую колонку;

• запускать нужную команду агенту;

• отслеживать выполнение;

• двигать карточку дальше;

• ждать CI;

• возвращать ошибки агенту;

• ограничивать retries;

• отправлять задачу в Need Attention, если автоматика не справилась.

Именно этот слой превратил Kanban-доску из визуального списка задач в процесс управления AI-командой.

Архитектура процесса

Упрощённо компоненты системы выглядят так:

Vibe Kanban Remote: доски, issues, statuses, PostgreSQL
Vibe Kanban Local: workspaces, sessions, execution processes, local API
Meetwise Orchestrator: Python asyncio daemon, polling, управление стадиями
OpenSpec Runtime: proposal, specs, design, tasks, archive
AI coding agents: исполнение стадий: explore, spec, apply, verify, test, ship, docs
GitHub Actions: CI, quality gates, merge policy

Vibe Kanban отвечает за доску, задачи, workspace и запуск агентских процессов. Оркестратор отвечает за lifecycle. OpenSpec отвечает за формализацию изменений. AI-агенты выполняют работу. GitHub Actions выступает внешним quality gate. Человек остаётся владельцем процесса.

Стадии pipeline

Backlog

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

To do / Explore

Это первая важная отличие от «просто попросить агента сделать». В To do агент не реализует задачу. Он исследует её.

Его цель:

• прочитать описание;

• найти релевантные места в коде;

• проверить существующие docs/specs;

• понять ограничения;

• предложить имя change;

• сказать, готова ли задача к спецификации.

Я специально разделил exploration и implementation. Почему?

Потому что в реальном проекте описание issue почти всегда неполное. Человек описывает намерение, а не все технические детали.

Например:

Нужно улучшить обработку больших video uploads, чтобы пользователь видел корректный статус, а backend не держал тяжелые временные файлы.

Человек понимает, что за этим стоят S3, CORS, frontend polling, статусы, Safari fallback, обработка ошибок. Агент без exploration может полезть не туда. Поэтому сначала он должен разобраться и вернуть что-то вроде:

[CHANGE RECOMMENDATION]
change_name: improve-video-upload-normalization
spec_ready: yes
[/CHANGE RECOMMENDATION]

Это похоже на работу аналитика или архитектора перед постановкой задачи в разработку.

Spec

На стадии Spec создаются OpenSpec-артефакты:

• proposal — зачем изменение;

• specs — какие требования меняются;

• design — какие решения и риски;

• tasks — что нужно сделать.

Зачем это нужно?

Потому что контекст не должен жить только в чате. Если один agent run исследовал задачу, второй пишет реализацию, третий чинит тесты, а четвёртый обновляет документацию, им нужен общий контракт. OpenSpec стал таким контрактом.

Да, это добавляет бюрократии. Но на сложных задачах эта бюрократия дешевле, чем хаотичная реализация без понимания цели.

Apply

На стадии Apply агент реализует изменение. Он уже не действует изолированно по короткому промпту.

У него есть:

• описание задачи;

• результаты exploration;

• OpenSpec proposal;

• design;

• список tasks;

• существующие проектные правила;

• кодовая база в отдельном worktree.

Задача агента — внести изменения, но не превращать стадию в бесконечный цикл «и реализуй, и протестируй, и смержи». Чем чётче разделены стадии, тем проще понять, где именно что-то пошло не так.

Verify

Verify — это стадия проверки соответствия результата требованиям. Здесь важно не просто «код скомпилировался».

Нужно проверить:

• все ли tasks закрыты;

• не противоречит ли реализация design;

• не пропущены ли edge cases;

• не появились ли очевидные нарушения инвариантов;

• нужно ли что-то доработать перед тестами.

Это похоже на внутреннее self-review перед полноценным тестированием.

Test

На стадии Test агент запускает проверки. В зависимости от scope это могут быть:

• backend unit tests;

• frontend tests;

• typecheck;

• lint;

• e2e smoke;

• targeted tests по изменённой области.

Если тесты падают, агент должен исправить падения в рамках этой же стадии. Важный принцип: тесты не должны быть необязательной рекомендацией. Они часть lifecycle.

Archive

Если задача шла через OpenSpec, после реализации change нужно архивировать. Это фиксирует, что изменение прошло путь от proposal до реализации и больше не является активным change. В обычной ручной разработке такие вещи часто забываются. В pipeline это отдельная стадия.

Ship

Ship — одна из самых важных стадий. Здесь агент создаёт PR, а дальше оркестратор начинает работать как control plane:

1. Находит PR.

2. Ждёт GitHub Actions.

3. Если CI зелёный — мержит.

4. Если CI красный — достаёт failure details.

5. Возвращает ошибку агенту follow-up сообщением.

6. Даёт агенту исправить проблему.

7. Повторяет до лимита retries.

8. Если не получилось — отправляет карточку в Need Attention.

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

Done

Задача завершена. Но это ещё не всегда конец процесса, потому что после merge может потребоваться документация. Об этом ниже.

Need Attention

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

• агент не смог корректно завершить стадию;

• CI падает после нескольких попыток;

• возник конфликт;

• workspace сломался;

• не хватает данных;

• требуется архитектурное решение;

• человек вручную остановил задачу.

Need Attention — это не провал. Это нормальная часть процесса. В человеческой команде тоже есть blocked/escalation. Для AI-команды это ещё важнее.

Короткий pipeline для мелких задач

Полный pipeline полезен для feature-задач, но слишком тяжёл для мелких правок. Если нужно поправить текст, небольшой regression, документацию или простой script, OpenSpec proposal/design/tasks могут быть лишними.

Поэтому я ввёл короткий pipeline по тегам: fix / documentation / enhancement

Для таких задач путь короче: To do → Apply → Test → Ship → Done

Но здесь есть важный нюанс. Обычный /opsx:apply ожидает, что OpenSpec-артефакты уже существуют. В коротком pipeline их нет. Поэтому оркестратор формирует отдельный direct prompt, куда явно вставляет описание issue.Без этого агент видел бы только заголовок и мог бы сделать слишком общую или неправильную правку.

Это хороший пример того, что AI-процесс — это не один промпт на все случаи. Разным типам задач нужны разные маршруты.

Параллельность: несколько AI-исполнителей одновременно

Один из главных смыслов Vibe Kanban — параллельная работа. В обычном чате у меня один поток:

задача → ответ → уточнение → исправление → следующая задача

На Kanban-доске можно вести несколько потоков:

задача A: frontend UX → Apply
задача B: backend billing → Test
задача C: docs → Ship
задача D: LiveKit bug → Need Attention
задача E: S3 upload → Spec

Каждая задача работает в своём worktree. Оркестратор хранит активные задачи примерно в такой модели:

_active_tasks: dict[str, tuple[asyncio.Task, str]]

То есть он знает:

• какая issue сейчас обрабатывается;

• для какой колонки была запущена обработка;

• не надо ли запустить её повторно;

• не передвинул ли человек карточку вручную.

Это превращает процесс из «я общаюсь с одним агентом» в «у меня несколько независимых рабочих потоков». И именно здесь Kanban начинает работать по-настоящему.

Документация как отдельный pipeline

После merge часто нужно обновить документацию:

• README;

• runbook;

• архитектурные заметки;

• описание API;

• инструкции по deploy;

• AGENTS/project rules;

• changelog;

• OpenSpec archive.

Если надеяться, что человек будет помнить об этом после каждого PR, документация быстро устареет. Если заставлять основную feature-задачу всегда обновлять документацию до merge, pipeline становится тяжелее и медленнее.

Я выбрал промежуточный вариант: отдельная merge/docs-доска. После успешного merge основной задачи создаётся связанная задача на документацию. Её pipeline проще:

Queue → Process → Merge → Done
             ↘ Need Attention

На стадии Process агент смотрит diff смерженного PR и определяет, какие документы нужно обновить. Если нужны изменения, он создаёт docs PR.

На стадии Merge оркестратор ждёт CI и мержит docs PR.

Это оказалось очень полезно:

• основной feature flow не блокируется документацией;

• документация не забывается;

• post-merge review становится отдельной стадией;

• видно, какие изменения ещё не отражены в docs;

• техническое знание не остаётся только в diff или истории чата.

Для меня это один из главных выводов: если документация не встроена в pipeline, она почти всегда будет отставать.

Что в итоге получилось

Снаружи это выглядит как Kanban-доска. Внутри — workflow engine для AI-разработки

Самое важное: карточка стала не просто задачей, а управляемым процессом. Она может пройти путь:

идея → exploration → spec → implementation → verification → tests → PR → CI → merge → docs

И на каждом этапе понятно:

• что должно произойти;

• кто это выполняет;

• какой контекст нужен;

• что делать при ошибке;

• когда вмешивается человек.

Главные грабли

1. AI-агенту нельзя сразу отдавать сложную задачу «в разработку»

Если задача нетривиальная, сначала нужен exploration. Агент должен понять кодовую базу, существующие решения и ограничения. Иначе он начнёт уверенно реализовывать неправильное решение.

2. Контекст должен жить вне чата

История переписки — плохой единственный источник требований. Нужны артефакты:

• specs;

• design;

• tasks;

• docs;

• tests;

• comments;

• runbooks.

Иначе следующий agent run не понимает, почему система устроена именно так.

3. Один универсальный pipeline не подходит для всех задач

Feature-задачам нужен полный путь через spec и verify. Мелким fix/documentation задачам нужен короткий путь. Если заставить все задачи идти по тяжёлому процессу, процесс станет слишком дорогим. Если все задачи пустить по короткому пути, сложные изменения будут разваливаться.

4. CI failure должен видеть агент

Если ошибку CI разбирает только человек, автоматизация неполная. Агент должен получать failure details и пытаться исправить свой PR.

5. Worktrees дают параллельность, но требуют дисциплины

Изолированные worktrees удобны, но нужно контролировать:

• зависимости;

• .env;

• git hooks;

• права пользователя;

• cleanup;

• ветки;

• временные артефакты.

Иначе инфраструктурные мелочи начнут ломать весь процесс.

6. Автоматизация должна уметь останавливаться

Бесконечный retry — это не надёжность. Нужен лимит попыток и понятная колонка Need Attention.

7. Человек должен оставаться владельцем доски

AI-оркестратор не должен спорить с ручными действиями. Если человек передвинул карточку, автоматизация должна это учитывать.

8. Документация не обновляется сама

Даже если AI умеет писать документацию, её нужно встроить в процесс. Иначе она будет забываться точно так же, как забывалась до AI.

9. Управлять AI-агентами легче, если вы уже умеете управлять проектами

Для меня это был неожиданный плюс. Навыки РП оказались очень применимы:

• декомпозиция;

• постановка задач;

• контроль статусов;

• управление блокерами;

• Definition of Done;

• работа с рисками;

• приоритизация;

• коммуникация через артефакты.

AI не отменил эти навыки. Он сделал их ещё важнее.

Финальные выводы

Главный вывод моего эксперимента такой:

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

Один агент в чате — это удобный помощник. Агент в pipeline — это исполнитель. Несколько агентов, работающих через Kanban-доску, worktrees, specs, CI, retry policy и docs pipeline — это уже похоже на маленькую инженерную команду. Не автономную, не магическую, не заменяющую человека. Но команду, которой можно управлять и с которой можно эффективно работать и создавать реальные сложные продукты.

Для меня как руководителя проектов это оказалось самым интересным открытием. Я не пытался стать самым быстрым программистом в проекте. Вместо этого я начал строить систему, где задачи проходят путь от идеи до релиза, а AI-агенты становятся исполнителями внутри понятного процесса.

И чем дальше я в это погружаюсь, тем сильнее кажется, что будущее AI-разработки — не в одном идеальном промпте. Будущее в том, чтобы научиться проектировать процессы, в которых AI-агенты работают так же дисциплинированно, как хорошая инженерная команда.

Ирония в том, что для этого нам нужны не только новые модели. Нам снова нужны старые добрые навыки управления проектами.