У меня давно болело одно изменение в Онто — убрать GraphQL из взаимодействия фронтенда и бэкенда.
Фронтенд-агент нашёл 11 точек использования GraphQL.
Мы объединили их в Epic (001), после чего последовательно закрывали Story:
- 002 — ручная реализация
- 003–007 — ручная оркестрация агентов через меня
- 008–011 — автоматическая оркестрация через агента
В какой-то момент я понял, что наблюдаю уже не развитие требования, а развитие самого процесса производства ПО.
Story 002 я реализовывал практически вручную.
Не фиксировал этапы жизненного цикла в контенте объекта, сам синхронизировал агентов, сам передавал контекст между ролями.
Потом появился специальный MCP tool, и аналитический агент начал фиксировать важные события прямо в объектах.
С Story 003 по Story 007 я продолжал выступать оркестратором лично.
По сути, вся синхронизация проходила через меня:
Аналитик → Backend → Frontend → QA
Я вручную переносил контекст между ролями и следил, чтобы никто не потерял важные детали.
И вот тут начинается самое интересное.
Я так работал почти полгода.
Поэтому когда появилось немного времени и воли, я сделал агента-оркестратора, который взял эту работу на себя.
🔻 [схема 1 — старая модель: я в центре]
🔻 [схема 2 — новая модель: агент-оркестратор]
На первой схеме хорошо видно старую модель: я нахожусь в центре и вручную передаю контекст между агентами.
На второй — новую: агент-оркестратор синхронизирует участников сам, а я остаюсь только на контрольных точках и финальной приёмке.
Результат оказался вполне измеримым.
До автоматической оркестрации значительная часть времени уходила не на реализацию требований, а на передачу контекста между ролями.
После появления оркестратора эти паузы практически схлопнулись.
Именно поэтому я постоянно повторяю одну мысль:
Не начинайте с упряжи.
Сначала нужно понять, где именно болит. Пожить внутри процесса. Несколько раз пройти его руками. Научиться измерять потери времени, контекста и качества решений.
И только потом автоматизировать.
Хорошая упряжь появляется не потому, что вышел новый модный фреймворк.
Она появляется тогда, когда вы точно знаете:
— какую боль хотите убрать;
— где возникает потеря эффективности;
— и как будете измерять результат.
Если совсем честно, я не придумал оркестратора потому, что захотелось агентности.
Я сделал его потому, что полгода сам выполнял роль оркестратора.
И мне это надоело 🙂