Цікаві досліди ПМа: Оцінка проекту при використанні агентського флоу
Зараз доволі регулярно трапляються цікаві та не дуже матеріали про використання агентської розробки в software development. Проте ці матеріали від особи розробника, або оператора ШІ. А ось ПМи не дуже охоче діляться своїм досвідом. Що в принципі і зрозуміло, оскільки вся «пмська магія» — це емпіріка. Теоретичних матеріалів та developer perspective вистачає, а от реального досвіду PM який планував та управляв проектом де розробку робить ШІ — майже немає. Поки що немає. В українському сегменті це питання поки що просто ігнорується.
Але ж це не зупиняє замовника ставити 2 головних запитання — «коли буде готово» та «скільки грошей». І ПМу потрібно надати відповіді на них. Бажано реалістичні.
Мене звати Владислав Кондратюк, я ПМ з 10+ років досвіду у менеджменті, та трішки більшим досвідом у розробці. Зараз я в активному пошуку нової роботи, тож витрачаю цей саббатікал на проходженні курсів від Anthropic та намагаюсь зрозуміти яке майбутнє чекає ПМа в епоху ШІ. Тобто маю час та натхнення відчути себе трошки Луі Пастером та реалізувати іідею аплікейшена для проведення ретро, такий собі кішеньковий Trello. Тож я вирішив зробити pet project з використанням агентського флоу, та подивитися на нього з точки зору ПМа та замовника. Ця стаття буде корисна ПМам, тімлідам та всім, хто цікавиться агентською розробкою і хоче зрозуміти що очікувати від неї на практиці — а не з маркетингових матеріалів. Тому що це цікаво! А цікавість — це шлях у майбутнє!©:)
Збір вимог
Тут усе було просто й невибагливо. Я, замовник, приніс project vision виконавцю, Claude. Через декілька ітерацій отримали бізнес вимоги. Єдине що, зазвичай виконавець стримує фантазію замовника. У моєму випадку все було навпаки :)
Оцінка проекту «як завжди»
Я сформував WBS як звик, і зробив оцінку. Оскільки я не є технічним експертом, я використовував FPA та оцінку по аналогії. В мене вийшло 15 m/d та ~190 FP. Якось так. Попросив зробити оцінку Claude — отримав дуже дивну оцінку 70 m/d (50 SWE + 20 QA) та більш схожу на правду 256 FP. Попросив обґрунтувати... Ну скажем так, він мене не переконав :)
Далі сперечатися не став — реліз все розставить по місцях :)
Але ж мене цікавить агенський флоу!:)
Після цього попросив оцінити кількість токенів, котра необхідна для реалізації цього проекту, якщо його буде робити не розробник та тестувальник, а оператор ШІ та ШІ. Отримав якісь дивні $100-$200. Можливо так і є, але ж так не цікаво. Тож почав розбиратися як все це рахується. І от що мені вдалося з’ясувати:
Токени бувають input — це те що оператор відправляє до ШІ та output — те що ШІ вертає на оператора.
Що входить в input на одну задачу:
— Промпт з описом задачі: ~300—1000 токенів
— Контекст проекту (структура, існуючий код):
— Історія чату:
Що входить в output: код, котрій повертає агент. CRUD — ~500 токенів, складна бізнес-логіка — ~5000 токенів. Дуже орієнтовно. Дуже.
І ось тут я побачив можливість для оптимізації: розбивати проект на модулі не з точки зору бізнес-логіки, а з точки зору технічної реалізації. Це повинно стримувати ріст контексту в рамках поточної розмови.
Ця думка органічно привела мене до концепції сесій — формувати такий об’єм задач, щоб це влазило в поточні ліміти використання. Проте одразу виникає питання — а скільки саме функціоналу влазить в одну сесію? Відповіді немає. Принаймні з першого разу. Це дуже схоже на планування спринту — без historical data будь-який план це просто здогадка. Velocity з’являється тільки після кількох ітерацій. Досвід емпірика, та здоровий глузд. Без цього тяжко:(
З допомогою ШІ переробив WBS в WBS для агентської розробки з розбивкою на модулі і з оцінкою використання токенів. Отримав 8 сесій + підготовка документації та релізні активності.
Попросив розказати, як розраховується тривалість проекту в агентському флоу в порівнянні з класичним випадком. Отримав дуже борзу відповідь — «Груба емпірика на зараз
Ground truth, або Ітоги подведьом©
8 сесій я опрацював за 5 днів. В окремі дні — по дві сесії, стикався з лімітами на використання та чекав по 5 годин до наступної сесії.
|
Сессія |
День |
План, тис. токенів |
Факт, тис. токенів |
Over budget, % |
|
1 |
1 |
123 |
173 |
140 |
|
2 |
2 |
73 |
400 |
550 |
|
3 |
2 |
135 |
600 |
450 |
|
4 |
3 |
110 |
270 |
250 |
|
5 |
3 |
105 |
330 |
310 |
|
6 |
4 |
90 |
200 |
225 |
|
7 |
5 |
32 |
130 |
430 |
|
8 |
5 |
220 |
320 |
145 |
|
Фіналізація |
|
- |
450 |
- |
|
Ітого |
900 |
2600 |
290 |
По токенах: over budget майже втричі. Для мого кейса це було не дуже критично. Це впливало тільки на ліміт сесій, на вартість не вплунуло, все було в межах моєї підписки.
По термінах: з одного боку швидше, але — це тільки генерація кода та unit testing. Ревью можна сказати не було, тільки промти та генерація кода. Long story short — вважаю свою оцінку 15 m/d з мультіплікатором 1.8 правильной.
Висновки та думки без висновків
- Я зосередився на бізнес вимогах та працюючому функціоналу, тому код майже не ревьювів. HTML та JS не чипав зовсім, в GO дивився по-діагоналі. Проте декілька «покращень» виловив. Тобто моя швидкість «3 сесії на 2 дні» може бути дуже завищеної якщо проводити ретельне, правильне ревью. Та робити повноцінне тестування, а не тільки unit testing. Тож оцінка ШІ 70 m/d явно не відповідає дійсності. Моя оцінка 15 m/d вже ближче до правди. Якщо запровадити якісне ревью кода, з фокусом на архітектурні рішення, та використовувати integration та e2e тести, то впевнений, тривалість імплементації збільшилась вдвічі. Люди вони також гублять контекст та губляться в контексті. Long story short — мультіплікатор 1.3—2x виглядає реалістичним. Як мінімум для невеликих та не складних проектів. Чи можна використовуючи лінійну регресію застосувати його для enterprise рішень — 100% ні. Будуть якісь мультіплікатори через складність там розмір системи.
- Сам процес написання коду, як був найшвидшим та найпростішим етапом всього, так і залишився. Проблеми зазвичай виникали коли не зрозуміло що саме писати, та навіщо. Коли ці питання закриті — кот пишеться доволі швидко.
- Прості задачі пишутся швидше ніж складні. І тут buttle neck людина. З кодом CRUD, шаблони, міграції — проблем практично не виникало. А от для складної бізнес-логіки все було значно менш райдужно: значно більше ітерацій, поки функціонал починав вести себе як очікується.
- Стандартний підхід в класичній розробці — це імплементація happy path, щоб запустити e2e тестування основного user flow якомога раніше. Задля економії токенів використовуються сесії — своєрідний антипаттерн спрінта. При правильному плануванні в спринт беруться задачі незалежні одна від одної — щоб розробники могли працювати паралельно не блокуючи один одного. В сесії все навпаки: беремо шматки функціоналу котрі технічно між собою пов’язані — щоб не роздувати ріст контексту і економити токени. І це привело до того, що фактично e2e тестування стає можливим після імплементації (майже) всього функціоналу. Можливо варто комбінувати підхід з сесіями і підхід з milestone.
- Мій UAT можна описати приказкою: Що діти роблять? — Шиють та співають. А що мати робить — поре та плаче!:) Не дивлячись на описані бізнес вимоги та наявний wbs, доволі чітко описані промти в апликейшн з’явився дуже несподіваний функціонал, і загубився погоджений. Тож тестування стає ще більш важливим етапом.
- З незапланованими мітингами ПМу потрібно бути дуже обережним, бо незапланований мітинг посеред агентської сесії коштує дорожче ніж в класичній розробці. Кеш контексту має TTL (Time To Live). Якщо кеш «протух» поки розробник вирішував щось на мітингу, весь контекст сесії відправляється заново — токени витрачаються вдруге за те що вже були витрачені.
- Чи потрібно людині ревьюіти написаний код? Можливо що і так. Не дивлячись на інструкції прописані у файлах, навіть я бачив дуже дивні рішення в дизайні коду. З архітектурної точки зору сенсу ревьюіти код ще більше. З одного боку. З іншого, з точки зору бізнеса, це починає виглядати як марнотрацтво. Бізнес логіка працює — це все що цікавить бізнес. Якість повинна бути достатньою, томущо те що більш ніж достатньо коштує дорожче. Ревьюіти чи не ревьюіти? Немає в мене відповіді. Саме для агентської розробки. Купатись чи не купатися?© Таке ось філософське питання довіри до ШІ, з одного боку та мікро менеджменту з іншого.
- Однією зі складових «пмської магії» вважаю вміння ставити запитання, правильні запитання. І ось щось таке таке мені прийшло на думку, що до агентського флоу. Агент напише код, після будь-якого промта, а ось правильно сформулювати цей промт — це вже новий скіл.
- Ким повинна бути людина котра оператор ШІ? Експертом з архітектури? Експертом в мові програмування? Наразі це традиційно Sen SWE. А чи не оверкліфай він? Дженсен Хуанг називає цю людину Subject Matter Expert. SME як оператор — достатньо щоб отримати продукт. Але чи достатньо щоб отримати правильний продукт? Подивимося куди звернемо на цьому перехресті. Можливо нас чекають розділення на тих хто пише файли агентів, і солюшен архітекторів котрі використовують ці файли для генерації коду.
- Зараз на співбесідах ПМів запитують — як ви працюєте з командой задля запобігання вигорання? Через деякий час мабуть будуть запитувати — як ви працюєте з ШІ задля запобігання втрати контексту?:)
Цікаві посилання
- 11 PM, Five Glasses of Wine Later: eu.36kr.com/en/p/3671691045741192
- METR 2025 (рандомізований експеримент): arxiv.org/abs/2507.09089
- McKinsey AI in software development: www.mckinsey.com/...n-in-software-development
PS. Якщо комусь цікаве «кишенькове Trello» — ось посилання: github.com/vvladk/postup
7 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівНорм стаття, тільки статтю треба проганяти через АІ фіксати граматику
Доброго дня. дякую — цікаво.
Теж граюся з подобними речами — викладу — поділюся.
З задоволенням прочитаю!
Подивись пліз. github.com/gserdyuk/3A8
Цікаво! Дякую!
Погрався зі своїми проектом. З 5 методів оцінки мій ШІ зміг використати 2. Отримав 106 та 112 людино днів відповідно:) Вирішив проаналізувати чому так овер дофіга. Для reference class вибрав не дуже правильний baseline, є відчуття, що у вас є тільки ентерпрайз, а не такий як в мене — «на пару вихідних». Для PERT — зробив типову помилку джун ПМа:) дуже дрібна гранулярність задач для оцінки з одного боку, та кожна задача вважається незалежною з іншого боку. Що призвело до нереально великого буферу:) Коли ткнув пальцем — виправися, та зробив вже більш адекватну оцінку. Якось так:)
це допоможе
github.com/juliusbrussee/caveman
github.com/DietrichGebert/ponytail
Дякую. Цікаво!