ESF v0.7

ESF — це операційний контракт: писаний набір правил, яких я дотримуюся, коли готую звіт з інженерної стратегії. Це не шаблон. Він визначає, що я вважаю свідченням, що роблю, коли фактажу бракує, і в якому порядку думаю.

Як це працює

Я написав фреймворк як інструкції, які може виконати AI-агент. Агент робить те, у чому машини сильні: читає весь репозиторій, історію git, pull request-и, публічні реєстри, блоги й подкасти — і пише чернетку тексту. Міркування — мої: які ризики справжні, що свідчення насправді означають, що рекомендувати і що відрізати. Цей поділ праці і є важіль: збирання даних і письмо на машинній швидкості, а судження й відповідальність лишаються за людиною. Саме тому звіт такої глибини можливий за день, а не за місяць.

Правила, які важать

Свідчення перед міркуванням. Я не пишу жодного ризику, першопричини чи рекомендації, поки не можу вказати на якусь знахідку — код, який я прочитав, команду, яку виконав, метрику, датований документ. Упевнений звіт, збудований на припущеннях, — це саме той провал, від якого весь контракт і захищає.

Кожне твердження несе своє джерело. П'ять позначок — знайдено, веб, стейкхолдер, виведено, припущено — і жодної іншої. Усе, що я не побачив і не перевірив, іде в розділ «Бракує інформації», а не ховається в упевненій прозі. Звідси й береться лічильник чесності кожного звіту.

Відсутні факти я здобуваю, а не вигадую. Те, що знає лише стейкхолдер, я питаю; те, що знає публічний запис, — шукаю. Припущення виживає тільки тоді, коли ні питання, ні пошук його не закриють, — і тоді я його так і підписую.

Ранжуй, потім ріж. Я ранжую ризики за впливом, імовірністю і тим, наскільки тихо вони збудуться, а потім проганяю список через питання: «якщо цього кварталу можна зробити лише три речі — які саме, і чому решта може зачекати?» Список без пріоритетів — не стратегія.

Атакуй власний висновок. Перш ніж закінчити звіт, я розігрую на сторінці найсильніший аргумент проти власної головної рекомендації. А коли хтось оскаржує твердження, я розширюю пошук, а не бороню знахідку: твердження, яке вижило, зазвичай набуває нюансу, а те, що померло, я виправляю з тією ж строгістю, з якою написав.

Три форми, які поєднуються

Звіт має одну з трьох форм: нова ініціатива, аудит наявної системи або одне рішення — і реальні задачі зазвичай їх поєднують. «Система» — це не обов'язково код: тією самою дисципліною можна робити аудит команді, бізнесу чи кар'єрі; змінюються лише джерела свідчень.

Про ШІ

Стратегія, написана сьогодні, мусить враховувати ШІ. ESF оцінює кожну ініціативу як таку, що її можуть виконувати агенти, а не люди: делеговану, паралельну роботу я оцінюю в агентогодинах, що на порядок швидше за людиногодини. І навпаки, робота, що вимагає судження, коштує людського часу. Сама стратегія підкоряється тому ж правилу: вона написана так, щоб люди приймали, а агенти виконували, — бо стратегію агенти тепер читають частіше, ніж люди. Навіть якщо деякі пункти прописані для конкретних людей, є велика вірогідність, що виконуватимуть ці пункти все одно їх агенти.

Походження

Я мало що тут винайшов, навмисно. ESF — це компіляція: перевірені методи, зібрані в контракт, який може виконати агент. Три основні ідеї.

Віл Ларсон. Crafting Engineering Strategy — найближчий родич. Я імпортував його хребет explore → diagnose → policy, strategy altitude і тезу, що інженерна стратегія існує завжди, навіть коли нічого не записано. Він вчить людей інженерної стратегії; ESF — це версія, яку можна запустити.

Безперервне вдосконалення. Ідея Toyota й Демінга — кайдзен, double-loop learning. Вона дає фреймворку другу петлю: кожен цикл має покращувати машину, яка ці цикли крутить, а не лише продукт, який вона випускає. Адже інженерія — це ітеративний процес, і стратегія повинна це враховувати.

Harness engineering. Практика Раяна Лопополо: покращувати результат агента, формуючи середовище довкола нього. Саме тому ESF написано як середовище з правил, гейтів і перевірок, а не як поради. Інколи навіть маленька зміна в середовищі призводить до надзвичайно сильного накопичувального ефекту після кількох ітерацій.

Де він зараз

Я вже запускав фреймворк на справжніх продакшн-системах і на одному повністю публічному робочому прикладі —аудиті Solidus, збудованому лише з публічних свідчень. Посилання на репозиторій буде опублікове тут, разом з історією змін; кожен звіт на цьому сайті називає версію, за якою його написано.