Чому агентам для програмування, таким як Claude Code, потрібен шар управління, а не кращі запити

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

Запит формує обмін інформацією перед вами. Він не може керувати всім, що оточує цей обмін.

Codex та Claude Code вже містять багато корисних елементів. Що бракує — це повноцінної, портативної системи, яка вирішуватиме, які правила застосовуються, який контекст має значення, що може робити агент для програмування, як розподіляється робота та що вважається доказом. Хтось мусить створити цей шар навколо середовища виконання. Однією з назв такого шару є ядро — це шар управління, який знаходиться під вашим контролем та передає роботу від наміру людини аж до отримання доказу. У ньому немає внутрішньої моделі, і воно саме по собі нічого не виконує.

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

Контекст був лише симптомом

Першою помітною проблемою є втрата контексту. Нова сесія часто не має уявлення про архітектуру, нещодавні зміни чи причини виконання завдання, тому перед тим, як можна буде продовжити корисну роботу, потрібно провести ще одну перевірку. Таке повторення витрачає час, ресурси та терпіння.

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

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

Один принцип залишається ключовим: спочатку визначте, що означає „завершено“, перед виконанням, а потім вимагайте доказів наприкінці.

Усунення повторень ніколи не було головною метою. Штучний інтелект перетворився з епізодичного експерименту на щоденну необхідність, і цікавим питанням залишалося, скільки користі може принести середовище, створене з використанням звичайних методів проектування програмного забезпечення. Штучний інтелект увійшов у наше життя кількома шляхами одночасно: через редактори, такі як Xcode та VS Code, а також через інструменти на кшталт Codex та Claude Code. Кожен з цих інструментів полегшував використання потужних моделей, але простіший доступ нічим не допомагав у організації процесів, які відбувалися під час їх використання.

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

Контекст відповідає на першу частину цього питання, адже надає агенту відповідні знання. Решта стосується того, як ці знання використовуються. «Управління» — це доречне слово для всієї цієї системи: практичний зв’язок між наміром, надійними знаннями, правилами, авторитетом, виконанням та доведенням. Воно залишається практичним, коли ключові етапи робочого процесу є достатньо чіткими для перевірки, корекції та повторного використання.

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

Що може та чого не може зробити bootstrap

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

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

Розміщення цього матеріалу у файлі AGENTS.md або CLAUDE.md значно здешевлює процес інтеграції. Слово “bootstrap” позначає межу та не є скаргою: хороший документ визначає мінімальні умови співпраці та вказує агенту, де знаходиться надійна інформація. Документи Codex містять файли AGENTS.md певного рівня, загальний розмір яких є обмеженим, а Claude Code пропонує короткі інструкції до проектів, причому процедури, які потрібні рідко, виводяться у окремі навички. Обидва аспекти описані у документації постачальників: посібник Claude Code щодо пам’яті та гід Codex AGENTS.md. Навичка об’єднує повторювану процедуру, щоб вона могла використовуватися в різних проектах, а хуки дозволяють змусити систему діяти певним чином щоразу. Проте якийсь інший елемент має вирішувати, коли застосовувати кожен механізм та як перевіряти його результати.

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

Тож bootstrap має пропонувати шлях до системи, а не намагатися бути самою системою.

Від bootstrap до карти

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

У ядрі немає нічого складного. Його цінність полягає у тому, як файли розділяються, поєднуються, вибираються та підтримуються протягом різних сесій та часів виконання.

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

У міру досконалішання конфігурації вона починає охоплювати політику керування пам’яттю, складність завдань, обсяг необхідних зусиль для мислення та вибір відповідної моделі, швидкі способи виконання завдань, безперервність між сеансами, перевірку та координацію дій кількох агентів. Повний перелік елементів приховає сутність архітектури. Важливо те, що агент може поступово відкривати для себе ці елементи в залежності від вимог роботи. За цією „картою“ стоять чотири основні обов’язки, які не описують кожен механізм, але пояснюють, чому вони пов’язані між собою.

Деякі знання мають залишатися після завершення чату

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

Завантажуйте те, що потрібно завданню

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

Знаходження чогось — це не дозвіл

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

Для завершення потрібні докази

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

Організація як аналогія

Уявіть собі компанію з будівлею, комп’ютерами та відмінним обладнанням, але без спільного способу роботи. У неї є потенціал, проте вона не є цілісною. Людям все ще потрібні загальні знання, процедури, право приймати рішення, чіткі обов’язки та контроль якості. Це порівняння є приблизним, адже агент — це не співробітник, а середовище виконання виконує більше, ніж просто розміщує людей за столами. Воно все ж демонструє, як взаємопов’язані ці елементи: агенти виконують визначені ролі, інструменти — це обладнання, а середовище виконання — це місце, де відбувається виконання завдань. Ядро — це спільний шар правил, знань, методів та контролю, який дозволяє їм співпрацювати. Кращі моделі не автоматично створюють кращу систему.

Де розташований цей шар

Ядро не конкурує з Codex, Claude Code, Gemini чи будь-яким іншим середовищем виконання, яке з’явиться надалі. Ці інструменти забезпечують живе середовище: моделі, інструменти, сеанси, налаштування міркувань та все більший набір власних підагентів, підключень та навичок. Шар управління працює в межах цього середовища та вирішує три питання: що має зберігатися, що дозволено агенту робити та які докази вважаються підтвердженням виконання завдання.

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

Управління не гарантує впевненості

Запис правила не гарантує, що агент його прочитає, зрозуміє чи застосує у правильний час. Bootstrap може вказувати на правильний протокол, але все одно залишатися проігнорованим. Канонічне рішення може зберігатися ідеально, тоді як його зміст поступово стає застарілим. Hook може сумлінно дотримуватися правила ще довго після того, як воно вже втратило свою корисність.

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

Така система ніколи не є завершеною чи універсальною. Це особиста налаштування, яка протягом місяців проходить тестування, виправляється та коригується. Вона покращує вашу здатність стежити та коригувати поведінку агентів, проте жодне правило, протокол, скорочення чи механізм пам’яті не дотримується ідеально. Управління може полегшити перевірку та виправлення поведінки, але не може зробити ймовірнісного агента детермінованим.

Три запитання, які потрібно поставити спочатку

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

То чи можна довести, що робота завершена? Лише тоді, коли поняття „завершення“ було визначене ще до початку виконання, а результат містить докази, що відповідають завданню. Без цього те, що у вас є, — це лише твердження, а твердження — не доказ.

Вам не потрібна така система, щоб почати мислити таким чином. Перш ніж додати ще один запит або файл, запитайте себе:

1. Які джерела мають право визначати, що є істиною?
2. Які рішення та дії потребують людського схвалення?
3. Які докази покажуть, що робота завершена?

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