Це свого роду доповнення / побічний квест до останньої серії. Воно не вписалося чітко в основний допис, тому публікую його окремо. Про це коротко згадується в Чому програмні фабрики зазнають невдач, частина 2: Увімкнення світла знову.
Пошук важеля
Ще до AI лише 25–50% часу на випуск функції йшло на написання самого коду. Решта припадала на узгодження/планування, перевірку коду/переробку, а також тестування/верифікацію рішення.
Якщо ви використовуєте AI лише для написання коду, то скорочуєте 2–4 години кодування до 10–20 хвилин, але нічого іншого не прискорюєте.
Але якщо ви використовуєте AI для допомоги в плануванні та узгодженні, то насправді досягаєте пришвидшення приблизно в 2–3 рази.
Правило 80/20 у важелі AI-кодування
Припустімо, ви навмання вкидаєте дворядковий запит у свою фабрику. Імовірність отримати повністю готовий до злиття результат — близько 50%, а ймовірність того, що доведеться переробляти, — також 50%.
Тепер уявіть, що ви провідний інженер із 10-річним досвідом. У голові тримаєте всю кодову базу зі 100 репозиторіїв. Тому витрачаєте день на написання ідеально детальної специфікації вручну. Ваші шанси кращі, але, ймовірно, все одно залишається 10% ризику, що доведеться переробляти щось суттєве.
А на крайньому полюсі: пишете кожен рядок самі. Агенту не залишається нічого, у чому він міг би помилитися, тож імовірність переробки зводиться до нуля.
Зауважте: для цього прикладу я збираюся «розмити»
«ймовірність, що доведеться щось змінити», зважену на «наскільки болючою буде ця зміна»
в одну відсоткову цифру, але очевидно, що це дві окремі змінні. Якщо модель із 50% імовірністю неправильно обере стиль кнопки, але виправлення — це один дешевий запит, то наш сукупний «очікуваний біль» невеликий.
очікуваний біль = P(вам доведеться це змінити) × наскільки болючою є зміна
Якщо це намалювати, то між зусиллями, вкладеними на початку, та очікуваним болем існує обернена залежність.
Чого ви не хочете робити — це витратити 6 годин на планування завдання, для якого можна було усунути 80% очікуваного болю за перші 10 хвилин.
Потрібно робити це, не надмірно зосереджуючись на запитаннях, на які ви не зможете відповісти, не спустившись на рівень нижче. Наприклад, якщо ви виконали певну роботу на рівні «продукту» й досі не відповіли на всі відкриті запитання, можливо, варто зупинитися на досягнутому та спуститися на рівень технічних деталей, щоб зрозуміти, що взагалі можливо. Ідеального процесу для цього не існує.
Саме це ми маємо на увазі під важелем — і це вимагає прагматизму. Якщо ви виконуєте кілька етапів планування, поступово наближуючись від огляду з висоти 50 000 футів до огляду з 10 000 футів, варто на кожному етапі трохи коригувати напрямок, щоб усунути якомога більше очікуваного болю.
Бажаю успіху.
