Метрики пользы AI-workflow

1. Ощущение «стало быстрее» обманывает

Запустив первый серьёзный AI-workflow, вы легко влюбитесь в процесс: что-то бежит параллельно, капают логи, агент бодро рапортует о прогрессе. Но ощущение скорости и реальная польза — разные вещи. Получили за два часа красивый diff, а потом день разгребали последствия? Ускорения нет.

Поэтому полезно держать в голове очень простую схему:

flowchart LR
    A[Сигнал] --> B[Метрика]
    B --> C[Интерпретация]
    C --> D[Действие]

Сигнал сам по себе ничего не значит. Метрика без интерпретации — просто число. Интерпретация без действия — маленький музей бесполезной аналитики. Система начинается там, где вы говорите: «Выросло число semantic conflicts — режем параллельность и делим ownership мельче».

Здесь и появляется понятие наблюдаемости workflow. После трека вы не тянете «ну вроде удобно было», а перечисляете: сколько ушло времени до первого плана, сколько было итераций, насколько вырос diff, сколько ручных правок внесли за агентом, были ли конфликты, пришлось ли переделывать после merge. Есть ответы — управляете системой; нет — обсуждаете впечатления.

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

2. Четыре оси: скорость, качество, цена, rework

Чтобы не утонуть в десятках случайных чисел, полезно смотреть на workflow по четырём главным осям. Стоит одной поехать — красивый pipeline начинает жрать время, нервы и репутацию.

Вот карта:

Со скоростью всё кажется очевидным, но именно она обманывает чаще всех. Первый план родился за пять минут — а до рабочего diff вы ползли два часа через четыре раунда. Меряйте её не одной точкой, а тремя: time to first plan, time to working diff, time to PR-ready state.

Качество — это не только «все тесты зелёные»: агент быстро написал код, а reviewer вычистил половину — работу просто отложили на потом. Стоимость тоже нельзя понимать слишком узко — есть ещё шум в диалогах, лишние плагины и агенты, поддержка артефактов; завели ради одного изменения трёх агентов, два плагина и четыре файла handoff ради пяти минут — переусложнили.

И, наконец, переделка. Это, пожалуй, самая честная ось из всех. Откатили в пятницу кусок, который во вторник считали быстрым успехом? Это не «естественная цена эксперимента», а диагноз плохого процесса. Rework — повторная работа после merge — читайте внимательнее всего.

3. Источники сигналов вместо памяти

Когда речь заходит о метриках, первая ошибка обычно очень человеческая: люди вспоминают, как оно «примерно было». Но после насыщенного дня вы запомните яркое, а не точное. Источники должны быть приземлёнными.

Самые полезные сигналы лежат в четырёх местах. Первое — логи сессий и handoff-артефакты: когда появился первый план, сколько было итераций, какие stop conditions срабатывали, сколько раз workflow возвращали назад. Второе — Git: commits, diff size, число изменённых файлов, частота cherry-pick или revert. Третье — тесты и CI: зелёный ли пайплайн, сколько падений и на каком шаге. Четвёртое — review notes: сколько замечаний оказалось существенными, сколько правили вручную, сколько вернуло трек на доработку.

Как собрать базовые сигналы по одному треку:

git log --oneline main..HEAD           # какие коммиты появились в треке
git diff --stat main                   # размер diff и изменённые файлы
./gradlew test --tests "*Checkout*"    # targeted tests по зоне изменений

Эти три команды не скажут вам всё на свете, но костяк дают: темп работы, масштаб и стоимость review, качество именно этой зоны, а не всего проекта в абстрактном вакууме.

Очень важно снимать сигналы по одному workstream, а не пытаться оценить сразу неделю целиком: один трек был отличным, второй провальным, а средняя температура по больнице ничего не объяснит. Один трек — один набор чисел — один verdict — один вывод для Workflow Kit.

Здесь же хорошо видно, зачем вам были нужны предыдущие лекции. Артефакты из pipeline дают материал для наблюдаемости, а checkpoints и quality gates — опорные точки для стабильного снятия сигналов. Метрики не из воздуха — они вырастают из уже внедрённой дисциплины.

4. Артефакт metrics.md и его поля

Если метрики не фиксировать письменно, они очень быстро превращаются в мифологию команды: кто-то скажет, что «тот трек был идеальный», хотя там было три итерации и один semantic conflict. Держите для каждого трека короткий артефакт с числами и verdict. Как и остальные артефакты уровня, шаблон живёт в Workflow Kit, а сам metrics.md — рядом с треком.

Например, так:

# metrics.md

Track: feature/checkout-refactor
time_to_first_plan: 12m
time_to_working_diff: 1h45m
iterations: 4
tests_pass: 27/27
ci_pass: yes
diff_size: 184 LOC
conflicts: 1 semantic, resolved via cherry-pick
manual_corrections: 6 lines
rework_after_merge: 0
cost_signal: medium
verdict: advanced workflow justified

Хорошо здесь то, что файл короткий и не пытается казаться научной статьёй: он отвечает на один вопрос — «Стоил ли этот advanced workflow усилий?» — и не словами, а наблюдаемыми фактами.

Поле time_to_first_plan показывает, насколько быстро система вообще среагировала. time_to_working_diff полезнее, чем time_to_first_plan: отделяет быстрый красивый план от реальной работы. Много iterations — либо слабый task spec, либо плохо нарезанный ownership, либо слишком широкая свобода инструментов. diff_size помогает понять стоимость review: даже хороший код тяжело проверять, если он разросся до нечитаемого масштаба.

manual_corrections возвращает человека в картину: агент сделал 95% работы, но оставшиеся 5% могут оказаться самыми рискованными. А cost_signal лучше держать в грубых корзинах low, medium, high: высокая стоимость при низкой пользе — плохо, умеренная при сильном выигрыше — допустимо.

Самое важное поле здесь — verdict. Оно кажется почти субъективным, но на самом деле опирается на всё записанное выше. Это не настроение автора, а инженерное решение: да, паттерн можно повторять; нет, этот способ параллельности лишний; да, рабочий, но после донастройки reviewer-agent.

5. Связка «метрика → действие»

Самая скучная судьба метрики — быть записанной и забытой. Спасает короткая связка «что означает сигнал и что делаем дальше». Это metric → action logic — не теория, а набор правил против споров по кругу.

Хороший стартовый шаблон:

# metric_to_action.md

too_many_conflicts          -> reduce parallelism / re-split ownership
huge_diff                   -> decompose task / split PR
repeated_iteration_failures -> improve task spec / start fresh session
high_cost_low_value         -> fewer agents / less context / drop plugin
many_false_positives        -> tune reviewer checklist
missed_issues_post_merge    -> strengthen tests and review gates

Эта запись кажется почти банальной, но в ней скрыта взрослая мысль: метрика не живёт сама по себе. Много конфликтов чинится не ещё одним merge tool, а уменьшением параллельности; огромный diff требует не reviewer-agent, а мелкой декомпозиции.

Особенно полезно смотреть на несколько типовых ситуаций. Число само не скажет, что сломалось, — но подскажет, куда смотреть. Резко вырос manual_corrections? Может, reviewer стал строже, а может, task spec расплылся, и агент начал делать лишнее. time_to_first_plan маленький, а time_to_working_diff и iterations большие? Workflow красиво стартует, но плохо доезжает: AI обещает в начале, а стоимость проявляется позже.

И тонкий момент: high cost иногда лечат, выкидывая агентную часть целиком. Но если rework нулевой, качество высокое, а скорость реально выигрывает — проблема, возможно, не в агентах, а в лишнем плагине или тяжёлом reviewer stage. Metric → action logic — не грубая дубинка, а набор маршрутов: симптом — круг причин — одна поменянная часть — новое измерение.

6. Сводный журнал parallel-session-log.md

Отдельный metrics.md полезен для каждого трека, но история на нём не кончается. До этого у нас уже были stage outputs внутри трека и parallel-session-log.md как рабочий лог. Треков несколько — нужна сводная секция.

Такой журнал выглядит так:

# parallel-session-log.md

Date: 2026-05-19
Треки:
  1) feature/checkout-refactor -> merged
  2) feature/promo-discount    -> rejected
  3) chore/dep-bump-spring     -> merged
Конфликты:
  - 1 semantic: checkout vs promo
Checkpoints: L1 x3, L2 x3, L3 x2
Метрики:
  checkout-refactor -> justified
  promo-discount    -> net negative
  dep-bump-spring   -> justified

Этот файл хорош тем, что связывает всё вместе — и в нём видны не только успехи, но и отклонённые треки. Очень часто команды по привычке документируют только то, что вошло в main, и забывают: отклонённый трек тоже произвёл знания. Он мог доказать, что ownership нарезан неудачно, или что dependency bump нельзя вести параллельно с refactor в том же модуле. Не попадёт такое в журнал — потеряете половину пользы от эксперимента.

Именно на этом уровне становится особенно видно, почему rework after merge считают самой честной метрикой. Трек feature/promo-discount мог выглядеть красиво сам по себе: хороший план, симпатичный diff, часть тестов прошла. Но net negative по итогам — система честно признаёт: путь стоил дороже, чем дал. Без этой честности сложная оркестрация живёт по принципу «раз уже сделали, значит, надо считать успехом».

Полезно также помнить, что метрики надо читать в связке, а не по одной оси. Быстрое время до diff не отменяет провал по rework, низкая стоимость не оправдывает плохое качество. И наоборот: умеренно высокая стоимость приемлема при нулевой переделке, небольшом diff и реальном росте скорости и качества. Формулы нет — есть вкус: не жертвовать всей системой ради одной цифры.

И вот к чему сводится весь уровень. Четыре оси, metrics.md с честным verdict, связка «метрика → действие» превращают вопрос «нравится ли мне этот workflow» в проверяемый ответ «окупился он или нет». Журнал показывает нулевой rework, растущую скорость и оправданный verdict — паттерн можно повторять и дошлифовывать. Показывает слабый выигрыш, высокий rework и лишние конфликты — это не провал эксперимента, а его результат: конкретную задачу дешевле вести обычным ходом — одна issue, один plan, маленький diff, тесты и review. Параллельность, worktrees и agent pipelines — не default-режим, а инструмент, который вы теперь умеете не только запустить, но и измерить. Включаете его там, где числа говорят «да».