Финальная часть серии. Мы собрали harness по слоям: инструменты, верификация, контекст, ограничения, наблюдаемость. Разобрались, кто это строит. Остался вопрос, который задаст любой руководитель, и его же я задаю себе: а как понять, что всё это работает? Не «агенты пишут много кода», а именно окупается.
Плохие новости: привычные способы измерения тут врут. Хорошие: рабочих метрик немного, и собираются они из того, что у вас и так есть. И дорожная карта внедрения умещается в девяносто дней — без революций и остановки разработки.
Сначала baseline, потом агенты
Главная ошибка измерения начинается до всяких метрик: эффект считают от внедрения, не зафиксировав точку «до». Через полгода на вопрос «что вам дали агенты» команда отвечает «ну, субъективно быстрее». Субъективно быстрее не защищается ни перед финансистами, ни перед собственной совестью.
Поэтому первое действие — до расширения агентов — снять baseline по четырём простым вещам: сколько стоит один смёрдженный PR (время людей плюс расходы на агентов, сейчас оно почти нулевое), сколько времени PR живёт от открытия до мёрджа, как долго ревьюятся изменения разного размера и сколько вычислительных ресурсов уходит на одного разработчика. Плюс две качественные метрики: доля откаченных или полностью переписанных правок и доля задач, у которых через пару недель после релиза подтвердился бизнес-результат. Всё это берётся из трекера, CI и системы контроля версий. Без магии, но с датой фиксации.
Что измерять: четыре рабочие метрики
После внедрения те же четыре метрики становятся основными. Стоимость смёрдженного PR — честная экономика агента: токены, инфраструктура, время ревью и доработок. Если она растёт при росте объёма — что-то не так с обвязкой, обычно с верификацией: агент много генерирует и мало попадает. Время жизни PR — главный индикатор того, где теперь узкое место. Почти у всех оно оказывается в ревью: генерация ускорилась, очередь на проверку выросла, итоговая скорость не изменилась. Это сигнал вкладываться не в «ещё агентов», а в проверки и формат результата из четвёртой части.
Скорость ревью относительно размера PR показывает, не раздувает ли агент изменения. У меня правило из прошлых заметок — минимальный diff — тут превращается в наблюдаемую величину: агентные PR должны быть маленькими и ревьюиться быстро. Если агентный PR в среднем в три раза больше человеческого, ревью утонет. И расход ресурсов на разработчика — предохранитель от тихого разгона затрат: токены имеют свойство расти линейно и незаметно, пока не придёт счёт.
Отдельно держу долю откаченных правок. Это метрика здоровья всей системы: растёт — деградирует либо обвязка, либо постановка задач. И раз в квартал считаю честную, неудобную вещь: куда ушло освободившееся время. Если агенты сэкономили команде двадцать процентов времени, а оно растворилось в том же объёме работы — эффекта для бизнеса нет, есть иллюзия занятости. Экономия должна куда-то перенаправляться: в исследования, архитектуру, качество. Иначе вы просто ускорили конвейер по производству того же самого.
Метрики-ловушки
Теперь про то, что измерять не надо, хотя рука тянется.
Строки кода и число PR. Агент производит объём бесплатно, поэтому объём ничего не значит. Команда, которую оценивают по строкам с агентами, получит много строк и много проблем. Я видел, как это называют зомби-продуктивностью: рапорты красивые, проекту плохо.
Скорость генерации. Сама по себе она бессмысленна и становится вредной без темпа проверки. Здоровая система — это когда валидация поспевает за генерацией, с небольшим запасом. Генерация, обогнавшая проверку втрое, — это не скорость, это отложенный инцидент.
И осторожнее с «процентом кода, написанного AI». Метрика провоцирует гнаться за процентом, а не за результатом. Задача — не написать агентом побольше, а поставлять быстрее при той же надёжности. Иногда правильный ответ на задачу — не использовать агента вообще, и метрика должна это разрешать.
Финальный плейбук серии
Вся серия задумывалась как плейбук, и чеклисты из частей складываются в один маршрут. Проверить, что вам вообще нужен harness, — чеклист первой части. Найти дыры по слоям — второй. Заложить переносимый слой — третий. Настроить доверие к результату — четвёртый. Закрыть риски — пятый. Перестроить команду — шестой. Измерить эффект и пройти девяносто дней — этот. Если пройти их по порядку, получится не коллекция советов, а рабочая система.
Главный вывод
Harness окупается там, где его измеряют честно: baseline до внедрения, стоимость и скорость смёрдженного PR после, здоровье ревью, доля откатов и судьба сэкономленного времени. И не окупается там, где меряют объём: строки, PR, процент кода от AI.
Вся серия сводится к одной мысли, и я повторю её напоследок. Агент — это модель плюс harness. Модель меняется каждые пару месяцев и всё меньше отличает одну команду от другой. Обвязка строится месяцами и отличает всё сильнее. Инвестируйте в то, что остаётся с вами.
Практический чеклист
Зафиксируйте baseline до расширения агентов: стоимость и время жизни PR, скорость ревью, расход ресурсов на разработчика.
Считайте эффект от той же точки, а не от настроения.
Следите, чтобы темп проверки поспевал за темпом генерации.
Раз в квартал отвечайте на вопрос, куда ушло сэкономленное время. Нет ответа — нет эффекта.
Уберите из отчётности строки кода и «процент AI». Замените на подтверждённые результаты.
Пройдите девяносто дней по плану: фундамент, проверки и контроль, система.
Серия закончена. Если дошли до этого места — у вас теперь есть и карта, и маршрут. Осталось пройти. Расскажите потом, что получилось: какие слои дались легко, на каких споткнулись. Я на этих историях учусь не меньше, чем на своих.
Обсуждение
Комментариев пока нет — начните тему.