Разработка

От тикета до отревьюенного 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 скажет больше любой демонстрации.