Метрики користі 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*"    # цільові тести по зоні змін

Ці три команди не скажуть вам усе на світі, але кістяк дають: темп роботи, масштаб і вартість 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 рядків
rework_after_merge: 0
cost_signal: medium
verdict: advanced workflow виправданий

Добре тут те, що файл короткий і не намагається здаватися науковою статтею: він відповідає на одне питання — «Чи вартував цей 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

Дата: 2026-05-19
Треки:
  1) feature/checkout-refactor -> злито
  2) feature/promo-discount    -> відхилено
  3) chore/dep-bump-spring     -> злито
Конфлікти:
  - 1 semantic: checkout vs promo
Контрольні точки: L1 x3, L2 x3, L3 x2
Метрики:
  checkout-refactor -> виправдано
  promo-discount    -> чистий мінус
  dep-bump-spring   -> виправдано

Цей файл гарний тим, що пов’язує все разом — і в ньому видно не тільки успіхи, а й відхилені треки. Дуже часто команди за звичкою документують тільки те, що потрапило в 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-режим, а інструмент, який ви тепер умієте не лише запускати, а й вимірювати. Увімкнете його там, де числа кажуть «так».