Как измерить координационные издержки от ИИ-агентов для разработки
Координационные издержки — это время людей, необходимое, чтобы превратить результат агента в принятую delivery-работу. Для измерения фиксируйте лишние усилия на восстановление контекста, исправление ответственности, сверку состояний, устранение неверных предположений и сбор подтверждений к ревью. Не начинайте со строк кода, числа промптов или pull request. Это показатели активности. Полезный знаменатель — работа, которую ответственный человек проверил и принял.
Что считать координационными издержками
Считайте работу, которая появилась из-за расхождения между исполнением и delivery-записью. Разделите её на пять категорий:
- Восстановление контекста. Повторное объяснение требования, поиск актуального решения или передача следующему агенту информации, которая уже существует в другом месте.
- Исправление ответственности. Поиск владельца, перенаправление результата агента или попытки сдвинуть задачу без активного исполнителя.
- Сверка состояния. Копирование статусов между трекером, чатом и GitHub или выяснение, где хранится актуальная версия.
- Восстановление и переделка. Повторная работа из-за устаревшего brief, пропущенной зависимости или выхода за согласованные границы.
- Сбор подтверждений. Поиск коммитов, pull request, checks и данных приёмки, которые должны были прийти вместе с задачей.
Не записывайте каждое человеческое решение в потери. Продуктовая оценка, архитектурное и security review, решение о релизе — часть delivery. Считайте лишнюю работу, без которой эти решения можно было бы принять так же качественно.
Почему активность агентов — слабая метрика успеха
Команда может создавать больше pull request и выпускать меньше. Типичный сценарий:
- агент начинает с скопированного промпта;
- в задаче нет последнего решения;
- pull request появляется без понятного владельца;
- перед ревью кто-то восстанавливает контекст;
- задача и репозиторий по-разному описывают готовность;
- следующая сессия начинается с нового пересказа.
Активность выросла. Принятый throughput — нет. Разница и есть место накопления координационных издержек.
Проведите двухнедельное измерение
Выберите один реальный процесс на десять рабочих дней. Состав команды, репозиторий и правила ревью должны оставаться достаточно стабильными для сравнения. До начала определите:
- процесс и репозиторий в границах измерения;
- людей и ИИ-клиенты;
- значение «готово к ревью»;
- человека, который принимает результат;
- место авторитетной задачи и решений.
Не меняйте процесс посреди окна ради красивой цифры. Фиксируйте то, что происходит.
Записывайте события, а не впечатления
Добавляйте строку каждый раз, когда человек выполняет лишнюю координацию вокруг агентной работы.
| Поле | Что записывать |
|---|---|
| Дата | Когда произошло событие |
| Работа | Задача, issue или pull request |
| Исполнитель | Человек или ИИ-клиент |
| Категория | Контекст, ответственность, сверка, переделка или подтверждения |
| Минуты | Потраченное человеческое время |
| Причина | Какой информации не хватало или где она противоречила |
| Можно предотвратить | Да, нет или неясно |
| Исправление | Что не даст событию повториться |
Запись должна быть короткой и конкретной: «Ревьюер потратил 18 минут на поиск требования, изменённого в Slack». «Агенту понадобился второй промпт, потому что в задаче не был указан репозиторий». «Задачу закрыли до появления CI и ревью». «Проблема коммуникации» — недостаточно конкретная причина.
Рассчитайте четыре показателя
1. Часы координационных издержек
Часы издержек = минуты предотвратимой координации ÷ 60 Неясные события считайте отдельно. Не улучшайте результат, называя каждое сложное решение предотвратимым.
2. Издержки на принятую задачу
Издержки на принятую задачу = часы координационных издержек ÷ число принятых задач с участием ИИ Это наиболее полезный показатель для сравнения процессов и периодов: стоимость связана с проверенным результатом, а не с активностью агента.
3. Доля переделок
Доля переделок = задачи, возвращённые из-за контекста, границ или подтверждений ÷ задачи, отправленные на ревью Отделяйте дефекты реализации от дефектов delivery-записи. Оба важны, но исправляются по-разному.
4. Доля бесхозных результатов
Доля бесхозных результатов = результаты агентов без текущего владельца или авторитетной задачи ÷ все проверенные результаты агентов Результат бесхозный, если команда не может быстро сказать, какая задача его запросила, кто отвечает за следующий шаг и где фиксируется приёмка.
Пример расчёта
Предположим, за две недели команда зафиксировала 420 минут предотвратимой координации и приняла семь задач с участием ИИ.
- Координационные издержки: 420 ÷ 60 = 7 часов.
- На принятую задачу: 7 ÷ 7 = 1 час.
- Три из десяти задач вернулись из-за отсутствующего контекста или подтверждений.
- Два результата пришли без текущего владельца или задачи.
Это не означает, что ИИ «сэкономил» или «потратил» фиксированное число часов. У команды появился baseline: один человеческий час лишней координации на принятую задачу плюс видимые переделки и бесхозные результаты. После изменения процесса повторите измерение и смотрите на направление всех четырёх показателей.
Найдите системную причину минут
| Повторяющееся событие | Вероятное системное исправление |
|---|---|
| Контекст восстанавливается в каждой сессии | Хранить требование, решение и текущее состояние в одной проектной записи |
| У результата агента нет владельца | Назначать человека или именованный нечеловеческий Principal до начала работы |
| Трекер и GitHub расходятся | Связывать данные репозитория с задачей и определить состояние, управляющее приёмкой |
| Работа возвращается из-за границ | Поместить условия приёмки и зависимости в назначенную задачу |
| Ревью начинается со сбора подтверждений | Требовать ветку, pull request, checks и открытые вопросы при передаче |
| Зависшие задачи приходится преследовать вручную | Назначить владельца follow-up или постоянный delivery-процесс |
Обычно нужен не более длинный промпт, а более качественная delivery-запись и ясный рабочий контракт.
Как TAM меняет измерение
TAM даёт людям и агентам одно состояние проекта:
- Principals и сервисные аккаунты делают исполнителя и назначение видимыми;
- MCP позволяет клиентам читать и обновлять живой проект вместо скопированного brief;
- TAM Skills задают процессы контекста, исполнения, подтверждений и передачи;
- GitHub-интеграция сохраняет данные репозитория у задачи;
- `@tam` координирует ответственность, follow-up, блокеры и готовность.
Эти механизмы должны снижать издержки. Измерение покажет, происходит ли это в вашей команде.
Как выглядит полезное изменение
Не задавайте универсальную цель: регулируемая команда и небольшой стартап несут разную стоимость ревью. Сравнивайте команду с ней самой. Изменение полезно, если:
- издержки на принятую задачу снижаются;
- переделки из-за контекста или подтверждений сокращаются;
- бесхозных результатов становится меньше;
- принятый throughput сохраняется или растёт;
- необходимая человеческая оценка и safety review остаются.
Если цифра улучшилась только потому, что команда стала хуже проверять работу, процесс не стал лучше.
Начните с одного процесса
Выберите один репозиторий и одну текущую delivery-цель. Две недели фиксируйте события до изменения системы. Затем повторите измерение с общей задачей, именованными исполнителями и явной передачей подтверждений.
