Augment выпустила на платформе Cosmos инструмент Project Builder, который доводит крупные проекты от проектного документа до слияния кода
Оригинальный заголовок: Accelerating large engineering projects with Cosmos
Augment выпустила на платформе Cosmos инструмент Project Builder — эксперта Cosmos, который превращает описание функции в проектный документ на основе реальной кодовой базы; после ручной проверки он распределяет задачи между рабочими агентами, доводит реализацию до слияния.
Augment официально раскрыла, как в Project Builder устроены проверка проектного документа и распределение задач, а также привела объём кода и сроки запуска трёх продакшн-проектов — по этим данным можно оценить, насколько жизнеспособен подход «сначала проектирование, затем оркестрация ИИ-агентов».
TL;DR. Агенты уже пишут код, ревьюят пул-реквесты и разбираются с инцидентами. Следующее узкое место — сам крупный проект: проектирование, декомпозиция и координация работы вокруг пул-реквестов.
Мы сделали Project Builder — эксперта Cosmos, который превращает высокоуровневую задачу в дизайн-документ в формате Markdown или HTML в Cosmos VFS (общей виртуальной файловой системе), проводит его через ревью людьми, а затем управляет агентами-исполнителями, чтобы довести реализацию до слияния. С момента запуска мы выпускали сложные проекты — например, новые возможности платформы и миграции в продакшене — за считанные дни.
За последние несколько лет разработка ПО сильно изменилась. Код пишут агенты. Ревью кода ведут команды агентов, подключая людей только для решений, где нужно суждение. Даже разбор инцидентов идёт впереди дежурного инженера. Каждая автоматизация убирала одно узкое место и обнажала следующее.
Для нас следующим таким местом стали крупные инженерные проекты. Новая фича, новый сервис, масштабная миграция или раскатка возможности платформы редко буксуют из-за того, что кто-то не может написать код. Всё встаёт на работе вокруг кода: разобраться в существующей системе, зафиксировать дизайн, решить, что и в каком порядке делать, и удерживать работу в русле исходной задачи по мере продвижения. Вот как мы автоматизировали этот слой. Давайте разберёмся.
Большинство инженерных организаций, внедряющих ИИ сегодня, оптимизированы под отдельные изменения: инженер берёт тикет, пишет код, открывает пул-реквест, выпускает. Крупные проекты в эту схему не укладываются. Прежде чем начать реализацию, кто-то должен ответить на сложные вопросы: какие системы меняются, как должна выглядеть архитектура, каков план раскатки, что от чего зависит. Для опытных инженеров это недели или месяцы работы: читать кодовую базу, писать дизайн, согласовывать его с коллегами, а потом координировать выполнение, пока фича не выйдет.
Рабочие процессы, изначально построенные вокруг ИИ, делают этот разрыв заметнее, а не меньше. Когда агенты могут выдать пул-реквест за минуты, проект, который всё ещё требует недель человеческого планирования и координации, упирается именно в планирование и координацию. Эту работу мы и хотели передать эксперту.
Project Builder — эксперт Cosmos, который ведёт крупную фичу от короткого описания до выпуска. Он готовит дизайн с участием человека и организует реализацию через тикеты и эксперта PR Author (о нём мы рассказывали раньше).

Project Builder от Augment на Cosmos: от описания фичи в одну строку до выпущенной фичи, с двумя путями доставки — одним пул-реквестом за раз или прогоном по тикетам, где работа разбивается на один пул-реквест на единицу.
Дизайн: Project Builder сначала пишет дизайн-документ. Это первая часть рабочего процесса. Всё начинается с короткого описания фичи или макета и заканчивается подробным дизайн-документом, основанным на реальной кодовой базе (в одном или нескольких репозиториях). DRI проекта (человек в цикле) ходит туда-сюда по разным деталям дизайна, пока его не устроят все решения. Дизайн-документ охватывает и продуктовую сторону — проблему, цели, нецели, критерии успеха, — и техническую: предложенный подход, архитектуру, затронутые компоненты и файлы, рассмотренные альтернативы, стратегию раскатки и фича-флагов, а также план тестирования.
Ключевая мысль в том, что для сложных проектов важнейший артефакт — это качественный дизайн-документ, все проектные решения в котором проверены человеком. Как только он есть, современные агенты отлично реализуют его от начала до конца — даже в сложных проектах.
Это тот же сдвиг, что и в код-ревью: человек переходит от построчного чтения кода к роли того, кто принимает решения, — только на уровень выше по стеку.
Публикация (для ревью дизайна): Как обычно, перед началом реализации мы хотим, чтобы дизайн проверили коллеги и заинтересованные стороны. Project Builder предлагает здесь два рекомендованных варианта: пул-реквест в GitHub или HTML-документ в VFS. Оба варианта удобны для агентов — доступны без дополнительных интеграций и MCP — и позволяют вносить правки.
- Markdown в пул-реквесте GitHub: лучше подходит для документов с большим объёмом текста и даёт преимущество — все комментарии может автоматически обработать эксперт-автор PR, который ведёт этот пул-реквест.
- HTML-документ в VFS: даёт более широкие возможности для архитектурных диаграмм и аккуратного форматирования. Пример показан на изображении ниже.

Как Cosmos оценивает качество экспертов по код-ревью: единый типизированный конвейер, выключенный по умолчанию, который превращает сигналы по каждому PR в строки, доступные для запросов, и при этом никогда не сохраняет авторский текст или персональные данные.
Другие платформы мы не рекомендуем: они неудобны для агентов. Это замедляет процесс и лишает будущих агентов лёгкого доступа к материалам. Но если вам всё же нужно использовать Notion или Confluence, можно настроить соответствующий MCP, и агент сможет работать с дизайн-документами и там.
Оркестрация: После утверждения дизайна Project Builder организует его реализацию. На этапе оркестрации есть два варианта: одним заходом и по тикетам; о них мы расскажем в следующем разделе.
Уведомления: Наконец, Project Builder продолжает сообщать людям в канале Slack каждый раз, когда новый PR готов к ревью и требует их участия.
Как мы это устроили в Augment
После утверждения дизайна Project Builder поддерживает два пути выпуска: разбить дизайн на упорядоченные тикеты с учётом зависимостей, по одному PR на единицу, или отдать весь дизайн одному исполнителю и выпустить всё одним PR. В Augment мы предпочитаем по возможности делать всё одним заходом. Один исполнитель, держащий в руках весь утверждённый дизайн, даёт более целостное изменение, чем несколько исполнителей, сшивающих вместе фрагменты контекста.
Получающиеся PR большие, часто на тысячи строк, и это нормально: дизайн уже тщательно проверил человек, наши эксперты по код-ревью за минуты анализируют весь дифф на корректность, в том числе проверяют, соответствует ли код дизайн-документу. «Маленькие PR» всегда были костылём из-за ограниченной пропускной способности человеческого ревью; когда это узкое место убрали, мы перестали платить налог на координацию из-за дробления. Мы по-прежнему дробим, когда этого действительно требует безопасность развёртывания, — например, при миграциях с промежуточными состояниями или если проект затрагивает несколько репозиториев.
Но начинать с подхода «одним заходом» в первый же день не обязательно. Тот же эксперт поддерживает и путь с тикетами: он разбивает утверждённый дизайн на упорядоченные рабочие единицы, заводит их в Linear или Jira с указанием зависимостей и организует по одному PR на каждую единицу в порядке зависимостей. Команды с требованиями к аудиту, со смешанным выполнением людьми и агентами или с поэтапными выкатками часто начинают именно с этого: тот же подход «сначала дизайн», тот же эксперт, а затем по мере роста доверия к ревью дизайна переходят к более крупным единицам.
Project Builder позволяет на скорости ИИ выпускать крупные функции и миграции в Augment. Ниже — примеры масштабных проектов Augment, построенных с помощью Project Builder; все они затрагивали продакшен-системы с тысячами активных пользователей и обошлись без сбоев и инцидентов.
Важно помнить: быстрое завершение проекта — заслуга не только эксперта Project Builder. Его нужно использовать вместе с другими экспертами экосистемы Cosmos (в первую очередь с автором PR и экспертами по код-ревью — наш цикл сборки), которые помогают быстро провести функцию через остальные этапы SDLC.
| Проект | Всего новых строк кода | Инженеры | Время до выката в продакшен |
|---|---|---|---|
| Новая функция: интеграция Cosmos с GitLab | 23,962 | 2.5 | 16 дней |
| Миграция: интерфейс чата переведён на серверную потоковую передачу | 16,474 | 1.5 | 14 дней |
| Новая функция: Cosmos Spaces | 5,476 | 1 | 5 дней |
Можно было бы измерить среднее время до завершения до и после Cosmos, но сравнивать три старых крупных проекта до Cosmos с тремя новыми после — бессмысленно из-за большой разницы в сложности проектов.
Если ваши проекты буксуют на планировании и согласованиях, а не на реализации, цель — не просто «быстрее писать код». Нужна система управления проектами, которая масштабируется: агенты готовят дизайн, люди его проверяют, а рабочие агенты доводят реализацию до мержа.
Настроить Project Builder на платформе Cosmos от Augment можно за 10 минут. Просто напишите эксперту Cosmos Advisor на платформе: «Настрой мне эксперта Project Builder» — он сконфигурирует эксперта и поможет адаптировать его под ваши репозитории и рабочий процесс. Внутри Augment используются GitHub, Linear и Slack, но Cosmos Advisor подскажет, как заменить эти интеграции на другой стек — например, GitLab, JIRA или Teams.
Project Builder дополняет экспертов, которые уже ведут наш SDLC на Cosmos: экспертов по код-ревью, которые мержат PR со скоростью, с какой агенты их создают, и экспертов по реагированию на инциденты, которые снижают нагрузку на дежурных, разбирая алерты до того, как подключится человек. Когда крупные проекты автоматизированы от дизайн-документа до выпущенной функции, единица инженерной работы — уже не PR, а проект.
Источник: Augment Code · Blog · augmentcode.com