Про метрики

В умовах перебудови SDLC під тиском агентної розробки, питання метрик насправді дуже проблемне зараз у багатьох. Але я завжди раджу не потрапити в пастку tokenmaxxing, бо як тільки розробників починають ранжувати за обсягом спалених токенів, то будь-якому розумному розробнику треба буквально 5 хвилин, щоб навантажити своїх AI агентів на максимальне спалювання токенів. І я не говорю про якусь абстрактну роботу, це може бути щось "умовно корисне", наприклад, усунення технічного боргу чи ще краще - робота над якоюсь фічею в циклі. Для прикладу, я імплементував Фабрику проєктів з купою різних верифікацій і якщо її запустити над якоюсь задачею і поставити ціль довести до досконалості, то вона нон-стоп буде спалювати $1000 тис. в токенах на добу дуже легко :)А що тоді по метрикам? А тут не треба винаходити велосипед - треба виміряти і зафіксувати звичайні проєктні метрики, наприклад, DORA: частота деплойментів, lead time від коміту до продакшена, відсоток невдалих змін (change failure rate) та час відновлення після інциденту. До них можна додати cycle time по задачах, escaped defects (скільки багів долетіло до продакшена), і головне - реальний throughput бізнес-цінності: скільки фіч чи задач з беклогу фактично закрито і прийнято. Але токени тежє варто міряти, однак це витрати, а не результат. Тому їм місце в знаменнику, а не в чисельнику. Цікава метрика не "скільки токенів спалив розробник", а "скільки коштує в токенах одна доставлена фіча" або "одна закрита задача". І тоді ми і adoption поміряємо, і delivery, бо роздування витрат без росту результату одразу видно. А розробник, який за $20 в токенах закриває те, на що в іншого йде $500, виглядає саме тим, ким він і є - ефективнішим.