Розділ 2. Закон необхідного різноманіття¶
Що ми робимо після відповіді моделі? Прочитали, оцінили, попросили переробити; знаходимо ще щось — підправили руками; далі знову. Кожен крок — реакція на згенероване.
Уявіть пастуха, який намагається контролювати отару сам: біжить за однією вівцею, повертає її — а поки повертав, п’ять інших вже розбрелися. Він не лінивий, але впоратися не може. У нього просто одна пара ніг проти сотні. Отара овець генерує різноманіття швидше і більше за можливі реакції пастуха, він завжди буде наздоганяти.
Повернімося від отари до сесії з моделлю. Хто в цій парі — ви і модель — ким керує? Питання ніби риторичне — людина пише промпти, значить керує. Але глянемо детальніше. У попередньому розділі я запропонував вважати одиницею аналізу не модель, а зв’язку: людина + модель + контекст + інструменти. Цей розділ — саме про закон керування, який визначає хто ким керує. Цікаво, що керування в основі — питання арифметики, а не зусиль і навичок.
Тільки різноманіття поглинає різноманіття¶
У 1956 році Вільям Росс Ешбі сформулював закон, який кібернетики вважають своїм аналогом закону збереження енергії. Звучить він так: регулятор може втримати систему в цільовому стані лише тоді, коли його власне різноманіття не менше за різноманіття збурень, з якими він має справу. Коротка форма: тільки різноманіття поглинає різноманіття.
Різноманіття — це кількість станів, які система може прийняти. І тут одна тонкість, яку зазвичай пропускають: рахуються не всі стани, а ті, які ви здатні розрізнити. Різноманіття завжди міряється відносно спостерігача.
Термостат керує котлом: у котла є внутрішня температура, і на кожне значення термостат має числову відповідь з певною точністю. Чи вийде доручити термостатові моніторинг системи обігріву всього будинку? У неї станів більше: можливе замерзання в трубі, повітряна пробка в батареї, протікання в з’єднанні. Щоб керувати такою системою, потрібно розрізняти більше станів, ніж просто температуру — а термостат бачить лише її. Він фізично не здатний до виконання цієї задачі — лиш відреагувати на певну частину збурень, а саме температуру.
Тепер повернімося до нашої пари. Модель може віддати тисячі істотно різних відповідей на те саме звертання — різних за архітектурою рішень, з прихованими припущеннями, з додуманими фактами, з тим, що вона вирішила «не бачити». Скільки з цих відмінностей ви розрізняєте? А на скільки з розрізнених у вас є окрема, заздалегідь готова реакція?
Ось і вся арифметика. Якщо різноманіття машини, спрямоване на вас, більше за ваше, спрямоване на неї, — керує машина. Не тому, що в неї є намір. Просто ваша діяльність починає структуруватися її виходами: ви правите те, що вона вирішила написати, у порядку, в якому вона це написала.
Чотири ролі¶
Цю арифметику зручно розгорнути в шкалу. За співвідношенням вашого різноманіття і різноманіття процесу ви в кожен момент граєте одну з чотирьох ролей.
Капітан. Ваш запас різноманіття істотно більший за складність задачі. Будь-який фрагмент згенерованого ви можете оцінити, переробити або викинути — і знаєте, чим замінити. Ви керуєте аж до повної перебудови рішення.
Стерновий. Ваш запас приблизно дорівнює складності процесу. Рев’ю ледь-ледь встигає за генерацією. Один нештатний поворот, і ви вже наздоганяєте.
Матрос. Ви приймаєте більшість згенерованого, правите дрібниці і вже не завжди можете пояснити, чому рішення саме таке. Напрям руху задаєте не ви.
Пасажир. Ви приймаєте вже не читаючи. Система, яку ви нібито створюєте, диктує вам хід власного розвитку, а вашого ресурсу вистачає тільки обслуговувати її.
Кожна сесія, де ви прийняли нерозібране рішення, трохи зменшує ваше різноманіття щодо вашої кодової бази — і трохи збільшує різноманіття того, чим ви намагаєтеся керувати. Виправити це складніше, ніж не допустити: у процесу, який розігнався, з’являється власна інерція, і зусилля на корекцію, які на старті коштували десять хвилин, тепер можуть коштувати днів.
Звучить безнадійно? Ні! Бо закон Ешбі — не вирок, а умова задачі керування. Він не каже «людина програє». Він каже: щоб керувати, зрівняй різноманіття. А зрівнювати його можна з двох боків.
Пліт і яхта¶
Гарно це видно на воді.
Вітер має колосальне різноманіття: пориви, стишення, зміни напряму, шквали. Людина проти вітру — ніщо: ви фізично не можете дути у відповідь. Пліт із вітрилом-ганчіркою пливе туди, куди дме, — це чат-сесія без системного підходу, і його пасажир щиро вважає себе капітаном, бо тримається за щоглу.
А яхта йде визначеним курсом, незважаючи на напрям вітру. Не тому, що яхтсмен вгадує вітер чи може змінити його за бажанням. Тому, що між ним і вітром вибудувана система. Кіль гасить знесення — забирає у вітру ту частину різноманіття, яка штовхає вбік. Вітрило, налаштоване під кутом, ловить і підсилює ту частину, яка робить корисну роботу. А сам яхтсмен тримає в руках не вітер — він тримає курс, шкот і румпель: три органи керування з розрізнюваними станами, на кожен з яких у нього є готові реакції, відпрацьовані до автоматизму.
Яхтсмен не переконує вітер. Він не пише вітрові довшу інструкцію. Він змінив власну позицію в системі так, що надлишкове різноманіття вітру гаситься конструкцією, а корисне — працює на курс.
Це і є інженерія різноманіття — так її називав Стаффорд Бір, який переніс закон Ешбі з термостатів на фірми. У неї рівно два важелі.
Два важелі¶
Важіль перший: підсилюй своє різноманіття. Усе, що збільшує кількість станів, які ви розрізняєте, і реакцій, які маєте напоготові. Вівчарка при пастухові — це підсилювач: його різноманіття, що бігає швидше за нього.
Декомпозиція. Поділіть задачу на менші частини — і на кожен шматок у вас раптом є готова оцінка: цей тривіальний, цей ризиковий, цей не чіпати. Різноманіття шматка менше за різноманіття цілого, а ваше — нікуди не ділося. Ви щойно виграли в співвідношенні, не додаючи собі різноманіття, — за рахунок меншої складності задачі. Різноманіття самої моделі ми поки не чіпаємо: це робота другого важеля.
Критерії. «Щось тут не те» — це відчуття, а не критерій: на нього не можна спертися. Записаний критерій робить відчуття видимим станом: «якщо код повторює запит, який повторювати не можна, — це неприйнятно». Коли це вже записано як текст, ви перевіряєте його щоразу, а згодом цю перевірку за вас робить тест. Кожен записаний критерій — плюс один стан, який ви розрізняєте.
Нормативна база. Стайлгайд, чеклист, файл пам’яті проєкту — це ваше різноманіття, законсервоване в текст: одного разу знайдена відповідь на цілий клас ситуацій. Ви написали її раз, а спрацьовує вона в кожній сесії. Про це буде окремий розділ.
Варіанти. Попросіть три реалізації замість однієї — і чутливість моделі до формулювань, яка дошкуляла вам як нестабільність, раптом працює на вас: ви порівнюєте, а порівняння — найдешевший спосіб розрізняти. Відбір із варіантів — це акт керування, доступний лише тому, у кого є критерії.
Важіль другий: послаблюй чуже. Усе, що зменшує кількість станів, які машина може вам видати. Паркан на пасовищі — послаблювач: шанс, що вівці самі розбредуться, стає мінімальним.
Межа контексту. Що в сесії — те і в грі: модель бачить лише те, що ви їй дали, — відкриті файли, вставлений код, документ, інструкцію. Усе решта для неї не існує, і це можна використати: дайте їй один файл сервісу замість усього репозиторію — і клас рішень «переписати сусідні модулі» зникає сам, бо цих модулів у її світі немає. Межа — це не те, що ви заборонили, а те, чого ви не показали. Ще один додаток до цього важеля — періодичне очищення агентського контексту.
Формат відповіді. Схема, шаблон, «спершу план, потім код».
Тести й автоматичні перевірки. Тести, крізь які не пройде вигадка моделі. Перевірки в CI — лінтер, схема конфігу, а де мова дозволяє — жорстка валідація типів.
Права. Агент без доступу до продакшн-бази має різноманіття менше рівно на всю продакшн-базу — і жодна його «ініціатива» вас там не наздожене.
У другого важеля є правило: послаблювач працює тоді, коли він структурний. Тест — послаблювач: неприйнятний стан фізично не проходить. Фраза в промпті «будь ласка, не додавай залежностей» — не послаблювач, а побажання: неприйнятний стан як був можливим, так і лишився. Різниця та сама, що між кілем і проханням до вітру дути рівніше.
Залежність свободи і контролю¶
Затискаючи один вимір, ви відпускаєте інший. Зафіксували жорсткий формат виводу — втратили несподівані рішення, які в цей формат не влазять. Обклали генерацію такими обмеженнями, що помилка неможлива, — отримали виконавця, який не запропонує нічого, чого ви не знали. Покрили все тестами до дрібниць — тепер будь-яка зміна архітектури коштує переписування тисячі тестів, і система бетонується.
Це не закон збереження — формули тут немає. Це закономірність із практики.
Обернена взаємозалежність свободи і контролю — не причина відмовитися від обмежень. Їх варто ставити свідомо: вирішувати, в якому вимірі несподівані результати неприйнятні — там додаємо контроль, а в якому різноманіття є цінністю — там залишаємо простір. Контроль — ресурс із обмеженим бюджетом, а не показник, якого що більше, то краще.
Один тиждень, дві сесії¶
Глянемо на цю механіку в реальній задачі: додати ретраї до HTTP-клієнта в старому проєкті.
Сесія перша, понеділок. Я відкрив Claude Code і написав: «додай в такий-то сервіс ретраї». Уууу, скільки тут варіантів: зовнішня бібліотека, саморобний декоратор, ретраї на POST, який не варто повторювати. Однакова для всіх пауза між повторами — і коли сервер падає, тисяча клієнтів стукає до нього знову секунда в секунду, не даючи піднятися. Модель обрала з цього простору рішень одне правдоподібне рішення — правдоподібне, бо її внутрішня тяга саме до цього, про що ще буде розділ шостий. Я витратив час на рев’ю, виловив ретрай неідемпотентного запиту, попросив переробити — і отримав нове рішення з новою проблемою. Друге коло. Третє.
Сесія друга, четвер. Той самий сервіс, ще одна задача з ретраями. Десять хвилин пішло на конструювання промпта: межа, критерії, формат, тести. Межа: файл клієнта, конфіг оточення, рядок «нових залежностей не додаємо». Критерії, списком: ретраїмо тільки ідемпотентні методи; пауза між спробами росте і має випадковий зсув; максимум три спроби. Формат: спочатку план, потім код. План я прочитав за хвилину і одним рядком зняв зайве, поки воно ще не стало кодом.
Що сталося з простором можливих результатів? У понеділок він містив усе правдоподібне. У четвер — кілька прийнятних реалізацій, різниця між якими на рівні смаку. Зауважте: модель та сама, задача та сама, руки ті самі. Змінилася конструкція, в якій працює модель. Мої десять хвилин підготовки — це підсилювачі моєї складності: критеріями я перебив моделі можливість вигадувати рішення, а хвилина над планом — нівелював хибне припущення до того, як воно вросте в код. Межа, формат і тести — послаблювачі: межа прибрала з контексту зайві файли та залежності, формат не дав кодові з’явитися раніше за план, тести не пропустять ретрай не туди. Цілі пласти неприйнятних рішень у моїй системі тепер не проходять.
Результат: дві години танців з бубном у понеділок проти десяти хвилин системного підходу в четвер. І ці десять хвилин — це інвестиція: критерії вже переїхали в чеклист, наступна задача отримає їх безкоштовно.
Мегапромпт — це капітуляція¶
Тепер типова помилка — саме як порушення цього закону, а не як «погана практика».
Виглядає це так. Модель читає системний промпт у чаті, файл CLAUDE.md чи навик в агенті, а часом просто README. Після повторюваного фейлу ця інструкція росте: «не використовуй бібліотеку X», «завжди пиши тести», «ніколи не змінюй сигнатури», «не додавай полів у конфігу»… За місяць це чотири сотні рядків, і інженер щиро вірить, що тримає ситуацію: он скільки правил я написав.
Але разом з ростом кількості інструкцій створюється зона з додатковим різноманіттям, і що довший системний промпт, то більший простір варіантів для його розуміння. Правила починають перетинатися і конфліктувати, модель виконує їх вибірково — і у вас тепер дві погано керовані системи: генерація і сама інструкція. Це спроба поглинути різноманіття машини найслабшим своїм каналом — словами, які нічого не блокують структурно. В аналогії з плотом, він обріс транспарантами до вітру, але від того не став яхтою.
Діагноз за законом Ешбі точний: людина нарощує не своє різноманіття, а обсяг побажань, і не послаблює чуже — жоден із чотирьох сотень рядків фізично нічого не забороняє. Позиція в системі не змінилася.
Лікується це винесенням правил у структуру, а не простим скороченням. Пройдіться по мегапромпту із питанням: що з цього може стати структурою? «Завжди пиши тести» — стає елементом CI. «Не змінюй сигнатури» — автоматичною перевіркою публічного інтерфейсу в пайплайні. «Не вигадуй полів» — схемою конфігу. Формат відповіді — шаблоном. Після такого винесення від чотирьох сотень рядків лишається сторінка — те, що справді має бути текстом: контекст задачі і критерії. У результаті промпт коротшає, керованість росте.
Закон працює на всіх рівнях¶
Бір усе життя доводив: закон Ешбі працює з організаціями так само. Фірма виживає, поки її керівні структури встигають поглинати різноманіття середовища; деградує — коли діапазон з трьох можливих рішень («ріжемо витрати», «наймаємо», «чекаємо») керує ринком із тисячами станів. Дашборд керівника — це послаблювач: тисячі подій стиснуті в три цифри. Розмова з командою — підсилювач: розрізнень стає більше. Плутати ці два інструменти — професійна хвороба керування, і в частині V ми до неї повернемося.
Тут мені важливо зафіксувати одне: закон масштабується. Сесія, агент, команда, компанія — на кожному рівні керує той, чия роздільна здатність і кількість реакцій покривають різноманіття процесу. Тому все, що ви побудуєте для власних сесій у наступних розділах, не пропаде: той самий метод, який потім розгортається на роботу з наборами агентів і керування командами.
У вашому ремеслі¶
Закон не знає, що таке код. Підставте своє ремесло — арифметика та сама.
Текст. Редактор, який пише «зроби текст живішим», сидить на плоту: у цього прохання немає жодного розрізнюваного стану. Добірка зразків, на які рівняємося, і список заборонених зворотів — послаблювачі: ми свідомо вибираємо певний спектр нормального розподілу замість надії на шанс не потрапити на сірість результатів, а на вершини цього розподілу. Стиль, зафіксований у гайді, приклади «так/не так», окремий редакторський навик зі своїм чеклистом — підсилювачі: і в тексті стає більше керованих вами станів.
Аналітика. Аналітик із шаблоном висновку і списком обов’язкових перевірок джерел керує дослідженням. Аналітик із промптом «проаналізуй ринок» отримує найправдоподібніший у світі звіт — і не має жодного способу відрізнити його від правильного. Шаблон і перелік перевірок — це ваші розрізнення, винесені на папір.
Дизайн. «Зроби красиво» програє за різноманіттям навіть плоту. Напрям, три референси і стек обмежень — сітка, палітра, заборонені прийоми — послаблювачі. Додатковий етап відбору з трьох варіантів — підсилювач: обирати може лише той, у кого є критерії.
Наостанок — три питання до вашої практики.
— Згадайте останню робочу сесію: скільки станів ви реально розрізнили у відповіді моделі — і скільки їх там, найімовірніше, було?
— Який один структурний послаблювач ви можете поставити вже завтра — такий, що працюватиме без вашої уваги?
— У котрій з чотирьох ролей ви провели більше часу минулого тижня?