Разработка

От задачи до pull request, прошедшего ревью

Пять ролей — продакт-менеджер, архитектор, разработчик, тестировщик, ревьюер — доводят задачу до pull request, который вливает человек. Мы знаем, что это работает, потому что так собирается сам Forge.

Валидатор между каждым шагом

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

Работа — это ветка, передачи — это коммиты

Вывод каждой роли — коммит в ветке прогона. Можно сравнивать попытки, читать обоснование решения или вмешаться посреди прогона, закоммитив исправленную передачу самому.

Вливает человек. Всегда.

Прогон открывает pull request. Автослияние существует и ограничено бюджетом автономности, но по умолчанию кнопку нажимает человек.

Один сценарий из нескольких

Это самая зрелая цепочка, которую мы поставляем, но не весь продукт. Тот же движок ведёт команды исследований, контента и эксплуатации — роли разные, механика одна.

Задача

«Бэклог полон правок, которые понятны, малы и никогда не стоят того, чтобы кого-то отвлечь».

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

Что делает Forge

Цепочка, которую узнает любая команда, но с управляющим агентом между шагами:

Задачавход
PMPMпревращает в требования и AC
АрхитекторАрхитекторпроектирует подход
РазработчикРазработчикпишет код и тесты
QAQAсверяет с критериями приёмки
РевьюерРевьюерчитает дифф, подписывает
Pull requestвыход

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

Второе отличие: всё записано. Вывод каждой роли — коммит; обоснования, отклонённые попытки и вердикты лежат в ветке. Читая pull request, вы смотрите не на вывод чёрного ящика — видно, как он к нему пришёл.

Доказательство

Самое сильное наше доказательство — так собирается сам Forge.

Автономный драйвер читает нашу дорожную карту, выбирает следующий применимый пункт, запускает на нём этот процесс, и получившийся pull request вливается в репозитории самой платформы. Этот цикл работает месяцами — включая упавшие прогоны, перезапущенные и предохранители, которые мы добавили после них.

Репозитории самой платформы приватные, поэтому мы не будем делать вид, что вы можете пойти и всё это проверить. Что мы можем — провести вас по реальным прогонам: ветка, коммиты с передачами, вердикты, которые отправляли работу назад, и те, что подняли её до человека. Это тот же код, который будете запускать вы, и мы предпочитаем показать его, а не бенчмарк.

Честные ограничения

  • Вливает человек. Мы не утверждаем, что автослияние по умолчанию — хорошая идея; оно включается явно и ограничено бюджетом.
  • Лучше всего работает на хорошо описанных задачах. Расплывчатая задача даёт расплывчатый PR — шаг PM вскрывает неоднозначность, а не выдумывает ответ. Это правильно, но означает, что вопрос вернётся к вам.
  • Это один сценарий из нескольких. Считать его продуктом целиком — ошибка; движок не заточен под разработку.

Что под капотом

  • Multi-Agent Pipeline — цепочка из пяти ролей подробно
  • Workflow Engine — граф, переходы и валидаторы под ней
  • Compete Mode — две команды над одной задачей, когда подход неочевиден
  • GitHub Issue Automation — метки как точка входа
  • Isolated Stacks — где изменения прогона проверяются до того, как дойдут до вас

Бэклог из правок, на которые ни у кого нет свободного дня?

Дайте нам один репозиторий и одну хорошо описанную задачу. Первый pull request скажет больше любой демонстрации.