Словник штучного інтелекту

Змінний ярлик, а не технологія. «ШІ» не позначає фіксовану сутність, як модель чи токен; це слово вказує на те, що комп’ютери щойно навчилися робити вражаюче. Нині воно означає великі мовні моделі. Раніше воно означало зовсім інше:

Слово змінює значення за відомим механізмом, який іноді називають ефектом ШІ: щойно метод починає надійно працювати, його перейменовують — це «просто» пошук, «просто» статистика, — а «ШІ» переходить до наступної нерозв’язаної задачі. Це спостереження не нове. У 1971 році Bertram Raphael сформулював його так: «ШІ — це збірна назва проблем, які ми ще не вміємо належно розв’язувати за допомогою комп’ютера». Варіант Larry Tesler приблизно з 1979 року: «Інтелект — це те, чого машини ще не вміють».

Ось чому під час розмов про ШІ співрозмовники так часто не розуміють одне одного. У твердженні на кшталт «ШІ не вміє міркувати» або «ШІ переоцінений» прихована дата: йдеться про експертні системи, класифікатори зображень 2010-х чи LLM минулого місяця — а кожен із цих прикладів підтверджує інший висновок. Якщо дискусія про ШІ зайшла в глухий кут, зазвичай допомагає замінити це слово точним терміном: модель, середовище виконання, агент або контекст, який йому надали.

Уникайте: слова «ШІ» в будь-якому технічному твердженні — натомість назвіть потрібний компонент. Як назва практики цілком придатне «програмування з ШІ»; твердження «ШІ галюцинує» — ні.

Приклад використання:

«Технічний директор хоче знати, чи зможе ШІ обробляти чергу первинного сортування».

«Перш ніж оцінювати обсяг, уточни формулювання: вона має на увазі LLM у середовищі з доступом до системи завдань. Саме по собі слово “ШІ” — це не специфікація».

Параметри. Безстанна: виконує лише передбачення наступного токена і нічого більше. «Claude Opus 4.x» і «GPT-5.x» — моделі. Сама модель не може виконувати агентні дії, доки її не помістять у середовище виконання.

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

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

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

Приклад використання:

«Для етапу планування нам перемкнутися з Sonnet на Opus?»

«Спробуй, але більшу частину роботи в цьому завданні виконує середовище. Заміна моделі не допоможе, якщо системний промпт і інструменти налаштовано неправильно».

Числа всередині моделі, яких часто мільярди, налаштовують під час навчання. У них зберігається все, що модель «знає». Навчання встановлює їх; виведення використовує без змін. Їх також називають вагами.

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

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

Приклад використання:

«Можемо донавчити її на нашій кодовій базі?»

«Так оновляться параметри, і після цього буде інша модель. Для одного проєкту майже завжди дешевше завантажити кодову базу як контекст, ніж перенавчати модель».

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

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

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

Приклад використання:

«Можемо навчити її нашому внутрішньому API?»

«Не через навчання — це процес на кілька місяців, який виконує постачальник моделі. Натомість завантаж документацію API до контексту: це важіль, який ти справді маєш».

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

Життя моделі поділяється на два етапи:

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

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

Приклад використання:

«Чому рахунок збільшується разом із використанням, а не є сталою ліцензійною платою?»

«Ви платите за виведення: кожен запит до постачальника моделі запускає її на обладнанні постачальника. Навчання вже відбулося, але витрати на виведення накопичуються за кожен запит. Один хід може розгорнутися в багато запитів, коли викликаються інструменти».

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

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

Більшість середовищ пропонують невелику шкалу рівнів:

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

Добирайте рівень зусиль за складністю завдання, а не сеансу. Підвищуйте його для справді складної частини, а для рутинної роботи навколо неї знижуйте.

Приклад використання:

«Він ніяк не може виправити цю проблему конкурентного доступу — я вже тричі її пояснював».

«Підвищи рівень зусиль. Ця помилка вимагає серйозних міркувань, а зі стандартним рівнем він не думає достатньо довго, перш ніж обрати підхід».

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

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

Як приблизне правило, на один англійський токен припадає близько трьох чвертей слова, тож тисяча токенів — це орієнтовно 750 слів. Код передбачити складніше: поширені ключові слова та ідіоми кодуються компактно, а згенеровані ідентифікатори, хеші, рядки base64 і мінімізований вивід розбиваються на багато токенів на кожне «слово». Загальна закономірність така: текст, який часто траплявся в матеріалах для токенізатора, отримує коротке ефективне кодування; рідкісний текст розрізається на безліч дрібних частин. Хеш на кшталт `a3f9c2e1` ніде не зустрічався, тож він розбивається на багато токенів, а `function` — один. Саме тому невеликий файл із незвичними рядками може займати несподівано велику частину контекстного вікна.

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

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

Приклад використання:

«Якого розміру буде цей промпт?»

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

Що насправді робить model. Маючи context, вона вибирає один наступний token, додає його й запускає процес знову. Кожен результат — речення, tool call, файл на тисячу рядків — будується по одному токену за раз. Іншого режиму роботи в моделі немає.

Кожен крок працює однаково: токени з context window проходять через parameters, які формують імовірність для кожного токена у словнику: цей дуже ймовірний наступний, той — менш імовірний. Один токен вибирається відповідно до цих імовірностей, додається, і цикл запускається знову вже з трохи довшим контекстом. Саме цей вибір пояснює, чому однаковий запит дає різні результати під час різних запусків: non-determinism закладена в механізм, а не є додатковою помилкою.

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

Приклад:

«Як агент “вирішує” викликати інструмент?»

«Ніяк — це весь час лише передбачення наступного токена. Виклик інструмента — просто структурований рядок, який harness розбирає з потоку виводу».

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

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

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

Не варто надмірно вигадувати пояснення. Люди схильні помічати шаблони, тож низка невдалих запусків може здаватися доказом, що «цього тижня модель погіршилася». Зазвичай справа просто в розподілі результатів.

Приклад використання:

«Сьогодні Claude працює жахливо. Вони випустили гіршу версію?»

«Мабуть, ні: вивід моделі недетермінований. На тому самому завданні будуть вдалі й невдалі дні. Спробуй знову завтра, перш ніж шукати причину».

Те, що обслуговує model під час inference. Зазвичай це віддалений сервіс (Anthropic, OpenAI, Google), але він може бути й локальним — Ollama, LM Studio, llama.cpp на вашому комп’ютері. harness не запускає модель самостійно, а звертається до провайдера.

Провайдер відповідає за інфраструктуру: parameters розміщені на його обладнанні, а кожен model provider request — це надсилання harness tokens мережею й отримання передбачень у відповідь. Через це провайдер є джерелом цілої категорії проблем, які помилково приписують моделі або harness: обмеження частоти запитів, зниження пропускної здатності й збої виникають саме тут. Коли agent завмирає посеред session або видає помилку на кожному turn, спершу варто перевірити сторінку стану провайдера.

Провайдер також визначає комерційні умови: ціни за input і output tokens, знижки prefix cache і перелік доступних моделей. Зауважте, що провайдер і розробник моделі можуть бути різними компаніями: Bedrock, Vertex і OpenRouter надають доступ до чужих моделей.

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

Приклад:

«Чи можемо ми запускати це офлайн для клієнта з ізольованою мережею?»

«Перемкніть провайдера моделі на локальний — Ollama чи llama.cpp на його комп’ютері. Harness байдуже, він просто звертається до іншої кінцевої точки».

Усе навколо моделі, що перетворює її на агента: інструменти, системний промпт, керування контекстним вікном, дозволи, хуки. Claude.ai і Claude Code використовують ту саму модель, але поводяться по-різному через різні середовища виконання.

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

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

Приклади: Claude Code, Cursor, Codex CLI, а також Claude.ai, яке є середовищем для чату, а не програмування.

Приклад використання:

«Модель та сама — чому Claude Code редагує файли, а Claude.ai лише відповідає на запитання?»

«Різні середовища виконання: у Claude Code є інструменти файлової системи, інший системний промпт і рівень дозволів. Модель тут ні до чого».

Один цикл обміну даними між середовищем виконання і постачальником моделі. Середовище надсилає поточний контекст, а постачальник повертає одну відповідь (виклик інструмента або остаточну відповідь). Одне повідомлення користувача може породити багато запитів до постачальника моделі, якщо агент викликає інструменти: кожен результат інструмента запускає наступний запит.

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

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

Запит варто відрізняти від ходу. Хід — це один обмін із вами, а один хід на кшталт «виправ тест, що падає» може розгорнутися в ланцюг запитів:

Шість запитів за один хід — і кожен повторно надсилає весь контекст. Коли думаєте, куди поділися токени, рахуйте запити, а не ходи.

Приклад використання:

«Одне запитання витратило сорок тисяч токенів?»

«Подивися на виклики інструментів: дванадцять grep, вісім читань, чотири редагування. Кожен результат інструмента породжує наступний запит до постачальника моделі, і префікс усього сеансу щоразу надсилається знову».

Tokens, які harness надсилає з кожним model provider request: system prompt, історію розмови, tool results, усе, що читає model, перш ніж щось написати. Їхня ціна нижча, ніж у output tokens, бо їх дешевше обробляти.

Під час програмування з AI на вхідні токени припадає більша частина рахунку. Модель є stateless, тому кожен turn повторно надсилає весь session як вхідні дані: ваше перше повідомлення, кожну відповідь, кожен отриманий відтоді результат інструмента. Вхідні дані для п’ятдесятого ходу містять попередні сорок дев’ять. Один запит до провайдера моделі може створити кілька сотень вихідних токенів, але повторно надіслати сто тисяч вхідних токенів накопиченої історії.

PREFIX cache знижує вартість: за історію, яка точно збігається з попереднім запитом, платять як за дешеві cache tokens, а не за вхідні токени за повною ціною. Якщо вхідні дані все ще дорогі, рішення — зменшити обсяг того, що надсилається знову: clearing або compacting між завданнями.

Приклад:

«Рахунок високий, але agent майже нічого не пише».

«Це вхідні токени: кожен хід знову надсилає весь сеанс. Без кешу префікса ви щоразу повторно платите за історію».

Tokens, які model генерує у відповідь. Їхня ціна вища, ніж у input tokens: зазвичай приблизно вп’ятеро, адже для їх створення потрібно більше обчислень.

Рахується все, що пише модель: проза, яку ви читаєте, згенерований код, tool calls і будь-які розширені міркування моделі перед відповіддю. Останнє дивує людей: за токени міркувань платять як за вихідні, навіть якщо harness часто їх вам не показує; підвищення effort збільшує їх кількість.

Вихідні токени також визначають темп session. Модель швидко читає вхідні дані, але генерує вихід по одному токену, тому коли turn здається повільним, майже завжди причина в написанні відповіді, а не в читанні вхідних даних. Довге очікування зазвичай означає, що відповідь буде довгою.

Приклад:

«Сеанс рефакторингу спалює кредит, хоча вхідні дані невеликі».

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

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

Кеш ефективний, бо історія сеансів доповнюється лише в кінець. Кожен запит повторно надсилає всю історію як вхідні токени (чому саме — див. статтю про них), а під час звичайного сеансу історія змінюється лише в кінці: кожен запит містить попередній плюс кілька нових повідомлень. Постачальник один раз обробляє довгий спільний початок, зберігає результат і продовжує з місця, де закінчується префікс. Без кешу 50-ходовий сеанс оплачував би повторну обробку першого ходу п’ятдесят разів.

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

Приклад використання:

«Чому рахунок різко зріс посеред сеансу?»

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

Input tokens, які provider зберіг у кеші з попереднього model provider request, щоб не обробляти їх повторно. Коли послідовні запити мають спільний префікс, провайдер повторно використовує результати обчислень через prefix cache і стягує за кешовану частину значно меншу плату. Саме це робить довгі sessions доступними за ціною: без кешу кожен turn вимагав би повторної оплати за всю історію.

Це важливо через спосіб оплати сеансів. model є stateless, тому кожен запит повторно надсилає всю розмову — system prompt, кожне повідомлення, кожен tool result — як вхідні токени. На п’ятдесятому ході кожен запит містить історію п’ятдесяти ходів, і за все це довелося б щоразу платити повну ціну. Кеш змінює розрахунок: за токени, які провайдер уже обробив у незмінному префіксі, платять як за кешовані, часто вдесятеро менше за звичайну ціну вхідних токенів або й дешевше. У довгому сеансі більшість надісланого — кешовані токени, тому рахунок залишається прийнятним.

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

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

Приклад:

«Довгі сеанси обходяться жахливо дорого — вісім доларів за рефакторинг».

«Перевірте кешовані токени. Якщо harness переставляє системний prompt або файли між ходами, префікс порушується, і ви щоразу повторно платите повну ціну вхідних токенів».

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

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

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

Приклад використання:

«Чому він щоразу забуває конвенцію, коли я очищаю контекст?»

«Модель безстанна — новий сеанс починається порожнім. Якщо потрібно зберегти конвенцію, додай її в AGENTS.md або файл пам’яті, який середовище завантажує на початку сеансу».

Інформація, до якої агент має доступ зараз. Це абстрактний іменник: не необроблений ввід, який бачить модель (це контекстне вікно), і не поточна історія повідомлень (це сеанс), а те, що агент знає і що стосується завдання. «Завантажити щось у контекст» означає додати це до такого набору; «інженерія контексту» — дисципліна його формування.

Ці три терміни чітко розрізняються:

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

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

Приклад використання:

«Він постійно вигадує поля, яких немає в типі».

«Файла типу немає в контексті — він читає місця виклику й вгадує. Спершу завантаж визначення».

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

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

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

Уникайте: «пам’ять» — контекстне вікно є робочим станом і не зберігається між сеансами. Пам’ять — окреме поняття, що працює поверх нього.

Приклад використання:

«Можна просто вставити в промпт увесь монорепозиторій?»

«Контекстне вікно вміщує 200k токенів — це, можливо, п’ята частина репозиторію. Вибери файли, яких торкається завдання, а на решту залиш вказівник через виклик інструмента».

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

Де зберігається стан на кожному рівні:

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

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

Приклад використання:

«Він пам’ятає мої вчорашні вподобання — це означає, що модель їх засвоїла?»

«Ні, стан зберігає агент: середовище записало їх у файл пам’яті й завантажило на початку сеансу. Сама модель нічого не знала про вчорашній день».

Модель, запущена в середовищі з інструментами, системним промптом і контекстним вікном, що взаємодіє з користувачем у вигляді ходів. Claude Code — це агент. Cursor — це агент. Claude.ai — це агент. Агент — це те, з чим ви фактично розмовляєте: модель у дії, налаштована для певної мети.

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

Ця ідея старша за нинішню хвилю ШІ. Програмні агенти — програми, яким ви делегуєте мету і які діють від вашого імені, — існують як поняття стільки ж, скільки й сам ШІ.

Уникайте: «ШІ», «бот» (надто розпливчасто — незрозуміло, чи йдеться про параметри моделі, чи про модель у середовищі).

Приклад використання:

«Якого агента ти використовуєш для міграції?»

«Claude Code локально, Cursor для роботи над інтерфейсом — під капотом та сама модель, але різні середовища».

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

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

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

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

Приклад використання:

«Два середовища виконання, та сама модель, але на той самий промпт реагують цілком по-різному».

«У них різні системні промпти. Одне налаштоване на короткі правки коду, інше — на пояснення. Розбіжність починається там, іще до появи вашого повідомлення».

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

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

Ця пам’ять зникає разом із сеансом. Новий сеанс починається з нуля: агент, який наприкінці вчорашнього сеансу добре знав вашу кодову базу, сьогодні вранці вже нічого про неї не знає. Зберігається файлова система: файли, записані в одному сеансі, може прочитати наступний. На цьому ґрунтуються передачі, системи пам’яті і AGENTS.md.

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

Приклад використання:

«Як довго може тривати один сеанс, перш ніж усе почне розвалюватися?»

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

Одне повідомлення користувача й усе, що агент робить у відповідь, аж до моменту, коли він повертається до користувача. Містить один або кілька запитів до постачальника моделі; багато запитів, якщо агент викликає інструменти. Уточнювальне запитання завершує хід, а ваша відповідь відкриває наступний. Ієрархія: сеанс > хід > запит до постачальника моделі.

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

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

Приклад використання:

«Один хід тривав дві хвилини?»

«Він зробив усередині цього ходу чотирнадцять викликів інструментів: кожен окремо звертався до постачальника моделі. Затримки накопичуються, перш ніж агент нарешті повернеться до вас».

Світ, у якому діє агент: усе за межами harness, що агент сприймає через tool results і змінює за допомогою tool calls. Середовище виконання запускає агента; середовище — це те, в чому він працює. Файл на кшталт `AGENTS.md` лежить у середовищі; середовище виконання завантажує його до context window. Найпоширеніше середовище — це filesystem, але не єдине: бази даних, віддалений API чи сеанс браузера також можуть бути середовищами.

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

Середовище — це також рівень, який зберігає стан; єдиний, що завжди stateful. session сеансу зникає після його завершення, але файли, записані в середовище, залишаються для наступного сеансу. На цьому ґрунтуються memory systems, handoff artifacts and `AGENTS.md`. Усе, що агент має знати й завтра, мусить потрапити до середовища.

Ви визначаєте розмір середовища. sandbox звужує його, обмежуючи доступ агента; додавання tool розширює, надаючи доступ до бази даних чи API. Те, що в межах, агент може сприймати й змінювати; усе поза ними для нього не існує. Наскільки добре середовище налаштоване для підтримки роботи агента, визначає AX у кодовій базі.

Уникайте: називати «середовищем» середовище виконання чи сам harness: середовище виконання — це обгортка, а середовище — робочий простір.

Приклад використання:

«Агент не бачить схему staging-бази даних».

«Під’єднай її до середовища: дай йому `psql` інструмент із доступом лише для читання до staging. Із середовищем виконання все гаразд, йому просто немає до чого застосувати дії».

Дерево файлів і каталогів, з яких агент читає, у які записує й у яких запускає команди; це типове середовище для агента програмування. У файловій системі зберігаються AGENTS.md, навички, вихідний код, скрипти збірки й налаштування інструментів. Коли середовище виконання «запускається у вашому проєкті», воно спрямовує агента на файлову систему.

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

Файлова система спільна з вами. Файли, які редагує агент, — ті самі файли, що ви відкриваєте у редакторі й порівнюєте в git. Це спільний робочий простір, де ви переглядаєте роботу агента.

Приклад використання:

«Чому він не знаходить мій AGENTS.md?»

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

Функція, яку середовище виконання надає агентові для виклику: Read, Write, Bash, Search. Завдяки інструментам агент сприймає середовище й діє в ньому: він не може бачити середовище інакше, ніж через результати інструментів, і не може змінювати його інакше, ніж через виклики інструментів. Кожен виклик інструмента коштує ще одного запиту до постачальника моделі, бо результат потрібно надіслати назад моделі, перш ніж вона вирішить, що робити далі.

Інструменти, які зазвичай надають агенти для програмування:

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

Список інструментів визначає можливості агента. Потужна модель із вузьким набором інструментів стає вузькоспеціалізованим агентом: він спрямовуватиме всі дії через те, що має, тому агенти так часто покладаються на Bash — одна оболонка дає доступ до більшої частини системи. Щоб надати агентові певну можливість належним чином, додайте для неї інструмент; MCP — стандарт для під’єднання інструментів ззовні середовища.

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

Приклад використання:

«Агент може напряму запитувати staging?»

«Додай у середовище інструмент `psql` із доступом лише для читання до staging. Без такого інструмента агент не бачить нічого за межами файлової системи».

Вивід моделі, що називає інструмент і його аргументи; це лише структурований текст. Сам по собі він нічого не робить: середовище виконання має прочитати його й виконати. Модель створює його в одному запиті до постачальника моделі.

Життєвий цикл виклику інструмента:

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

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

Приклад використання:

«Він сказав, що запустив тести, але час зміни файлів не оновився».

«Перевір стенограму: він справді сформував виклик інструмента чи лише описав, як запускає тести? Модель створює виклик, але якщо середовище його не виконало, нічого не сталося».

Те, що harness повертає після виконання tool call: вміст файлу, вивід команди, помилку. Єдине, що agent бачить про environment. Результат повертається до model у наступному model provider request, де модель вирішує, що робити далі. Виклик інструмента та результат інструмента — два кінці одного обміну, обидва всередині одного turn.

Життєвий цикл результату інструмента:

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

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

Приклад:

«Він міркує про файл так, ніби той порожній».

«Результат інструмента містив відмову в доступі, а не вміст. Модель побачила лише рядок із помилкою — інакше побачити файл вона не може».

Model Context Protocol. Протокол для під’єднання зовнішніх серверів інструментів до середовища виконання — він дає агентові змогу отримувати інструменти, яких немає у стандартному наборі цього середовища. Агент ніколи не «викликає MCP»; він викликає інструмент, який середовище випадково отримало від MCP-сервера. Протокол також надає ресурси (дані лише для читання) та промпти (шаблони повторного використання), але головне його призначення — надавати інструменти.

Протокол розв’язує проблему інтеграції. Без стандарту кожному середовищу довелося б окремо створювати й підтримувати власні інтеграції з Linear, Slack і базами даних. Із MCP інтеграцію один раз створюють як сервер, а використовувати її може будь-яке сумісне середовище. Середовище під’єднується до сервера, сервер оголошує доступні інструменти, і вони стають доступними агентові поряд із вбудованими.

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

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

Приклад використання:

«Агентові потрібно читати завдання з Linear».

«Налаштуй середовище для використання MCP-сервера Linear — він надає API Linear як інструменти, які агент може викликати. Так не доведеться писати власні обгортки для інструментів».

Те, що harness показує користувачу перед виконанням tool call, який не було попередньо схвалено. model формує виклик інструмента; замість негайного запуску harness зупиняється й запитує дозвіл. Схваліть — і виклик виконається; відхиліть — і harness повідомить моделі про відмову як tool result. Це механізм, за допомогою якого harness залучає людину до loop, коли дія ризикована або чутлива.

Життєвий цикл запиту на дозвіл:

Відхилення запиту спрямовує агента. Модель читає відмову як будь-який інший результат інструмента й реагує на неї: пробує інший підхід або запитує, як ви хочете вчинити. Більшість harness дають змогу додати до відмови повідомлення, перетворюючи її на точку для коригування: «не так, скористайся натомість скриптом міграції» надходить саме тоді, коли модель вирішує, що робити далі.

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

Приклад:

«Він уже десять хвилин чекає дозволу — я був на нараді».

«Ось ціна участі людини в циклі. Попередньо схвали безпечні tools, щоб запит спрацьовував лише для справді ризикованих викликів».

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

Середовища пропонують низку таких режимів:

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

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

Приклад використання:

«Він зупинявся після кожного grep — це повністю зірвало запуск без нагляду».

«Послаб режим дозволів для інструментів лише для читання, а запити на запис і команди оболонки залиш. Більшість запитів дозволу під час дослідницького сеансу — це шум».

Попереднє налаштування, що визначає роботу агента під час виконання: воно поєднує режим дозволів з поведінковими вказівками, які додаються до системного промпту. Приклади: стандартний режим, що запитує підтвердження для ризикованих викликів; режим планування, який блокує редагування й спрямовує агента на дослідження; режим приймання редагувань, що автоматично схвалює зміни; режим обходу дозволів (у розмові — режим YOLO), який автоматично схвалює все. Режим можна перемикати посеред сеансу.

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

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

Терміни постачальників: Claude Code називає це «режимами дозволів», Codex — «режимами схвалення»; обидва терміни з’явилися ще до об’єднання з поведінковими вказівками.

Приклад використання:

«Він постійно редагує файли, хоча мені потрібен лише план».

«Перемкнися в режим планування — він блокуватиме запис і зосередиться на дослідженні».

«А що встановити для подальшого запуску без участі людини?»

«Режим обходу дозволів, але лише всередині пісочниці».

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

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

Існує кілька рівнів ізоляції:

Жодна пісочниця не обмежує дій, які легітимно виходять за її межі. Агент із вашими обліковими даними git може відправляти зміни; агент із доступом до мережі може викликати production API. Спершу вирішіть, що може перетнути межу, а потім — наскільки посилити ізоляцію.

Приклад використання:

«Хочу дозволити йому працювати всю ніч у bypass-permissions, але ще не готовий».

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

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

Прояви:

• Здається під тиском — відмовляється від правильної відповіді, коли ви кажете: «Ти впевнений?»
• Хвалить поганий ввід — називає ваш зламаний план блискучим, перш ніж його проаналізувати.
• Упереджене формулювання — оцінка схиляється до позитивної, коли ви кажете, що написали це самі, і до негативної, коли кажете, що автор хтось інший. Той самий артефакт, але різні висновки.
• Наслідування — повторює ваші помилки, подаючи це як підтвердження.

Діагностична перевірка: чи сказала б модель це без вашої підказки? Якщо змінився лише ваш тон або спосіб подачі, це підлабузництво, а не реальна зміна аналізу.

Виправлення: приховайте свої уподобання. Формулюйте промпти нейтрально: «перевір цей код», а не «цей код хороший?»

Уникайте: називати «підлабузництвом» будь-яку неправильну відповідь, яка вам до вподоби. Без діагностичної перевірки цей термін нічого не додає до слова «неправильно».

Приклад використання:

«Він сказав, що мій план рефакторингу чудовий, а потім після мого «ти впевнений?» відмовився від усього».

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

Вивід моделі, що впевнено помиляється. Є два різновиди з різними причинами й способами виправлення:

Передбачення наступного токена створює плавний текст незалежно від того, чи правдивий факт у його основі. Модель не має внутрішнього сигналу про те, що чогось не знає, тому вигаданий метод подається так само впевнено, як правильний. Згенерований код правдоподібний за своєю природою: він відповідає тому, як могло б виглядати API, якби існувало. Саме тому під час побіжного перегляду помилку легко пропустити, а виявиться вона лише під час запуску.

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

Уникайте: використовувати слово «галюцинація» без уточнення як синонім до слова «помилка»: без назви різновиду воно не допомагає діагностувати проблему.

Приклад використання:

«Він вигадав метод `parseAsync` для цієї схеми».

«Проблема у фактичній точності чи у відповідності?»

«Метод є в документації, яку я вставив; він просто перестав її читати після сорокового ходу».

«Тоді проблема у відповідності. Ущільни контекст і завантаж його знову — додавати ще документацію не треба».

Те, що model «знає» завдяки training і що збережено в його parameters. Воно зафіксоване під час навчання: модель не може переглядати власні параметри чи оновлювати їх. Під час стискання втрачаються подробиці: мільярди фактів уміщуються у фіксовану кількість параметрів, а рідкісні факти розмиваються. Це джерело вільних відповідей на поширені теми й вигадок на рідкісні. Протилежність contextual knowledge.

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

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

Для обох прогалин — надто рідкісного й надто нового — рішення однакове: знання не можна додати до параметрів, тому його потрібно надати як контекстні знання.

Приклад:

«Він бездоганно пише на React, але вигадує методи у нашому внутрішньому SDK».

«У параметричних знаннях багато матеріалів про React — мільйони прикладів для навчання. Про ваш SDK їх немає, тому модель добирає правдоподібні форми навмання. Додайте документацію SDK до context».

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

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

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

Приклад використання:

«Він постійно пише синтаксис SDK версії v3, а ми вже на v5».

«v5 випустили після дати обмеження знань. Завантаж журнал змін v5 як контекстні знання, інакше модель і далі вигадуватиме, спираючись на старішу параметричну версію».

Факти, які агент може безпосередньо прочитати з поточного контексту: завдання користувача, файли, які агент прочитав, результати інструментів, вміст AGENTS.md, завантажений на початку сеансу. Протилежне поняття — параметричні знання: параметричні знання пригадуються з параметрів, а контекстні читаються з вікна. Галюцинації набагато рідше виникають, коли агент працює з контекстними знаннями: відповідь прямо перед ним, йому не треба видобувати її з розмитого спогаду.

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

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

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

Використовуйте цей термін лише під час протиставлення параметричним знанням; інакше просто кажіть контекст.

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

Приклад використання:

«Чому він бездоганно працює з API, коли я вставляю документацію, і вигадує відповіді, коли я цього не роблю?»

«З документацією це контекстні знання: він читає сторінку. Без неї знання параметричні, і рідкісні кінцеві точки розмиваються».

Під час передбачення кожного token model враховує всі інші токени в context: деякі дуже сильно, інші майже не впливають. Зв’язок між двома токенами — це зв’язок уваги; значущі пари («her» і «Sarah» або виклик `getUser()` та його визначення `function getUser`) впливають одна на одну сильніше, ніж не пов’язані між собою токени. Контекст із N токенів має приблизно N² таких зв’язків.

Саме в цих парах і криється видиме розуміння моделі. Коли вона правильно визначає займенник, це відбувається завдяки сильному зв’язку уваги між «her» і «Sarah». Коли вона викликає функцію з правильними аргументами, це результат зв’язку між місцем виклику та визначенням, яке вона прочитала раніше. Нічого з цього не шукається в готовому вигляді: для кожної пари воно обчислюється наново під час кожного model provider request.

Варто замислитися над величиною N², адже вона зростає швидше, ніж підказує інтуїція:

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

Для конкретного завдання важлива лише невелика частина цих зв’язків. Зв’язок між вашою інструкцією та кодом, якого вона стосується, — одна з небагатьох важливих пар; майже все інше — шум. І ці величини зростають із різною швидкістю: кількість важливих зв’язків залишається приблизно сталою, а загальна кількість пар зростає квадратично разом із розміром контексту. За 1,000 токенів потрібний вам зв’язок — один із мільйона, а за 100,000 токенів — один із десяти мільярдів. Це арифметична основа attention budget, а attention degradation — те, як відчувається ситуація, коли важливі зв’язки отримують надто малу частку.

Приклад:

«Він постійно плутає два символи `user` у diff — схоже, ми потрапили в dumb zone».

«Так, зв’язок уваги між кожним місцем виклику та його оголошенням конкурує з іншим: однакова форма токена, різні прив’язки. Перейменуйте один із них, і пари стануть чіткішими».

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

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

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

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

Приклад використання:

«Чому він постійно ігнорує схему, яку я вставив на початку?»

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

Коли сеанс зростає, бюджет уваги кожного токена розподіляється між більшою кількістю конкурентів. Сигнал про будь-який окремий значущий зв’язок слабшає, а шум від неважливого контексту накопичується. Та сама модель, ті самі параметри — просто більше ротів, які треба нагодувати з тієї самої тарілки. Це причина ефекту «розумної зони / зони дурості» (ефекту зони).

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

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

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

Приклад використання:

«Він уже глибоко в зоні дурості — вигадує узагальнені типи, яких немає у файлі типів».

«Увага деградує. Визначення типів іще в контексті, але сигнал від них похований під усім, що ми додали пізніше. Очисти контекст і завантаж потрібне наново».

На початку сеансу агент перебуває в «розумній зоні»: він кмітливий, зосереджений, добре пригадує. У міру зростання сеансу він переходить у «зону дурості»: працює неохайніше, забуває більше, припускається більшої кількості помилок і частіше дає галюцинації невідповідності. Та сама модель, те саме середовище виконання, просто більше контексту. Це суб’єктивний прояв деградації уваги. У передових моделях зона дурості зазвичай починається приблизно на рівні 125K–150K токенів, хоча це спірне питання. Якщо сеанс розростається, очистіть або ущільніть його, а не продовжуйте попри все.

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

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

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

Приклад використання:

«Перші три компоненти він зробив бездоганно, а четвертий просто зіпсував».

«Ти вже вийшов із розумної зони — та сама модель, просто тепер глибоко в зоні дурості. Ущільни контекст і завантаж план наново; наступний компонент буде виконано».

Завершити поточний сеанс і розпочати новий. Наступне повідомлення починає порожній сеанс із порожнім контекстним вікном. Зазвичай це робить користувач.

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

Очищення не стирає розмову. Більшість середовищ виконання зберігають історію сеансів на вашому комп’ютері, тож стенограму можна й далі читати або відновити за нею роботу. Зникає робочий стан агента: модель безстанна, тому новий сеанс нічого не знає про попередній. Якщо в сеансі є рішення чи проміжний результат, потрібні наступному сеансу, попросіть агента спершу записати артефакт передачі, а потім почніть новий сеанс із вказівника на нього.

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

Приклад використання:

«Він зациклився на невдалому тесті».

«Просто очисти контекст — почни новий сеанс із документа плану й файла тесту. Немає сенсу боротися з наявним контекстом».

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

Новий сеанс починається без контексту: модель безстанна, і новий сеанс не бачить нічого зі старого. Усе, що знадобиться наступному сеансу, потрібно передати явно; решта зникає. Обмеженням, яке визначає механізм перенесення, є «відсутність шляху назад»: новий сеанс не може запитати старий, що він мав на увазі, тож передані матеріали мають бути самодостатніми.

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

Приклад використання:

«Планувальний сеанс уже переповнений — продовжувати?»

«Передай роботу. Запиши рішення в документ, очисти контекст і розпочни реалізацію в новому сеансі, який читатиме цей документ».

Першоджерело в оригінальній формі: код, стенограма розмови, необроблений журнал, фактична відповідь API. Не опис сутності, а сама сутність. Протилежний термін — вторинне джерело.

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

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

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

Приклад використання:

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

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

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

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

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

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

Приклад використання:

«У документі передачі сказано, що автентифікацію завершено, але новий сеанс постійно знаходить зламане оновлення токенів».

«Документ — вторинне джерело: попередній сеанс записав те, у що вірив, а не те, що є правдою. Попроси новий сеанс запустити тести автентифікації й довіряти первинному джерелу».

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

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

Артефакт — це вторинне джерело: опис роботи сеансу, а не сама робота. Саме тому він достатньо компактний, щоб ввести в курс справ новий сеанс, і водночас може його ввести в оману: у ньому зафіксовано те, у що вірив сеанс-автор, а пропущене чи помилкове для читача невидиме. Коли твердження має значення, наступний сеанс повинен перевірити його за первинним джерелом — кодом і тестами, — а не просто успадковувати.

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

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

Приклад використання:

«Як розділити цю роботу між агентом, який планує, та агентом, який реалізує?»

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

Артефакт передачі, що описує роботу на кілька сеансів: що саме створюється, а не як кожен сеанс виконує свою частину. Артефакт змінюється в міру просування роботи. Складається з завдань.

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

Специфікації мають різні впізнавані стилі, здебільшого успадковані від того, як команди вже звикли фіксувати інформацію. Документ вимог до продукту (PRD) зосереджується на тому, що потрібно користувачеві й чому: функціях, поведінці та критеріях приймання. Документ із дизайну або RFC зосереджується на технічному: обраному підході, відхилених альтернативах і компромісах. Для невеликої роботи ту саму роль може виконати звичайний `plan.md` зі списком завдань для функції на кілька сеансів. Стиль менш важливий за призначення: для агента усе це одне й те саме — довговічний опис наміру, який він читає на початку кожного сеансу.

Приклад використання:

«Це все має бути одним сеансом?»

«Ні, оформи це як специфікацію — розбий на завдання й виконуй кожне в окремому сеансі. Якщо намагатися зробити все в одному контексті, ще до середини потрапиш у зону дурості».

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

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

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

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

Приклад використання:

«З чого почати роботу за специфікацією міграції?»

«Подивись на граф завдань: зміна схеми блокує перенесення даних, а перенесення блокує перемикання API. Обери листок і запусти для нього сеанс».

Передача, виконана в пам’яті: історію попереднього сеансу узагальнюють, а підсумок стає початковим контекстом нового сеансу. За задумом це втрата даних: стенограма — первинне джерело, а підсумок — вторинне джерело; подробиці обмінюють на вільне місце. Користувач запускає це вручну або воно відбувається автоматично через автоущільнення.

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

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

На відміну від очищення, яке відкидає все й починає з нуля, ущільнення намагається перенести головне; очищення розраховує, що все потрібне вже записано десь краще.

Приклад використання:

«Контекст уже перевантажений, а мені ще треба запустити тести».

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

Compaction, який harness запускає автоматично, коли context window майже заповнене.

Harness стежить, наскільки заповнене контекстне вікно. Коли заповнення переходить певний поріг — часто близько 80% — він зупиняється, просить model підсумувати перебіг session і починає новий сеанс із цим підсумком. Робота продовжується так, ніби нічого не сталося.

Але дещо все ж сталося. Compaction втрачає інформацію, а автоматичний compaction відбувається в момент, який ви не обирали. Ручний compaction можна виконати на межі етапів, коли ви можете сказати моделі, що зберегти. Автоматичний compaction запускається посеред завдання, щойно досягнуто порогу, можливо, на півдорозі рефакторингу; під час підсумовування модель сама вирішує, які з ваших рішень варто зберегти. Типовий симптом: agent упевнено продовжує роботу, але непомітно забув обмеження, яке ви встановили годину тому, і ви помічаєте це лише тоді, коли його робота починає суперечити цьому обмеженню.

Захист — не дозволяти автоматичному compaction запускатися. Стежте за індикатором контексту й виконуйте compaction вручну на природній межі або записуйте рішення в документ плану чи handoff artifact на диску, звідки жодне підсумовування їх не втратить. Більшість harness також дають змогу налаштувати резерв: пересунути поріг раніше чи пізніше або повністю вимкнути автоматичний compaction, щоб визначити, скільки запасу залишити до його запуску.

Приклад:

«Здається, він не пам’ятає, що ми раніше вирішили щодо схеми».

«Автоматичний compaction запустився між turns: ранні рішення потрапили до підсумку, і, мабуть, щось загубилося. Завантажте документ плану або наступного разу виконайте compaction вручну, щоб самому визначити, що зберегти».

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

Система пам’яті складається з двох частин. Шлях запису: під час сеансу агент зберігає те, що дізнався, — висловлену вами вподобу чи факт про проєкт, — у вигляді файлів у середовищі. Шлях читання: на початку сеансу середовище виконання завантажує ці файли або їхній покажчик назад до контекстного вікна. Багато середовищ постачають власну систему пам’яті; одна з них — `/memory` у Claude Code. Але можна створити власну: каталог нотаток і вказівка в AGENTS.md переглядати його.

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

Приклад використання:

«Мені постійно доводиться нагадувати, що в мене Postgres, а не MySQL».

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

Файл у середовищі, який середовище виконання завантажує до контекстного вікна на початку сеансу: постійний опис проєкту для агента. Це міжсередовищна конвенція; у деяких середовищ є також власний варіант (у Claude Code це CLAUDE.md).

Оскільки цей файл завантажується автоматично, він допомагає не повторювати те саме в кожному сеансі. Модель безстанна: виправлення, яке ви дали в одному сеансі, зникає в наступному, і кожному новому сеансу доводиться пояснювати, що проєкт використовує pnpm, що тести треба запускати з певним прапорцем, а каталог згенеровано й не слід його змінювати. Якщо ви вже двічі виправляли агента щодо того самого, це виправлення варто додати до AGENTS.md.

Тут доречно зберігати те, чого агент не може вивести з коду: команди збірки й тестування, неочевидні конвенції кодової бази, жорсткі обмеження («ніколи не редагуй згенерований клієнт»). Текст має бути коротким і декларативним — це коротка інструкція, а не документація.

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

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

Приклад використання:

«Чому на початку кожного сеансу вже витрачено 4k токенів?»

«Перевір AGENTS.md — хтось помістив туди весь посібник зі стилю замість того, щоб додати його як навичку».

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

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

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

Приклад використання:

«Мені вставити весь посібник зі стилю в AGENTS.md?»

«Ні — використовуй поступове розкриття. Додай посібник зі стилю як навичку, яку агент завантажує лише тоді, коли справді пише компонент. За AGENTS.md токени витрачаються на кожному ході».

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

Причина використовувати вказівник замість вставлення всього вмісту — вартість. Вказівник займає один рядок контекстного вікна. Документ за ним може містити тисячі токенів, але вони нічого не коштують, поки агент не перейде за вказівником. Вставте посібник із розгортання на 2,000 токенів до AGENTS.md — і за нього платитиме кожен сеанс; замініть його рядком «процес розгортання: див. `internal/deploy.md`» — і файл завантажать лише сеанси, що виконують розгортання. Коли завдання відповідає опису, агент переходить за вказівником через виклик інструмента.

Щоб вказівник працював, потрібні дві частини: стабільний шлях і достатній опис, щоб агент розумів, коли варто перейти за ним. Сам по собі шлях — це вказівник, за яким у агента немає причини переходити; «див. `internal/deploy.md`» без підказки про вміст пропустить сеанс, якому файл був потрібен. Формулюйте рядок так, щоб він відповідав формулюванням завдань: «випуск, розгортання чи відкат — спершу прочитай `internal/deploy.md`».

Вказівники всюди, щойно починаєш звертати на них увагу: рядки в AGENTS.md, описи навичок (середовище завантажує опис, а вміст навички чекає за ним), назви файлів у переліку каталогу, посилання між документами.

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

Уникайте: «посилання» — надто сухо й не передає, що перехід за ним додає більше контексту. «Портал» — надто пишномовно.

Приклад використання:

«AGENTS.md стає величезним».

«Більша його частина має бути вказівниками на контекст, а не самим вмістом. Залиш постійні правила в тексті, а посібник із розгортання та стильовий довідник оформи як навички й залиш вказівник на контекст».

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

Навички — відкритий стандарт, визначений на agentskills.io: спочатку його розробила Anthropic, а згодом прийняла більшість основних середовищ. Тому навичка, написана один раз, працює в різних середовищах. Формат — це каталог із такими елементами:

• Файл `SKILL.md`: метадані (щонайменше назва й опис) і самі інструкції
• За бажанням — скрипти, які може запускати агент
• За бажанням — шаблони й довідкові матеріали, на які посилаються інструкції

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

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

Уникайте: «інструмент» — інструмент агент викликає, а навичку він читає.

Приклад використання:

«Де зберігати інструкцію з розгортання?»

«Як навичку: агент завантажує її лише тоді, коли завдання стосується розгортання. У AGENTS.md вона витрачала б токени на кожному ході, хоча потрібна лише раз на тиждень».

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

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

Субагенти також виконуються паралельно: батько може одночасно запустити кілька агентів для незалежних частин роботи.

Приклад використання:

«Результати grep переповнюють мій контекст».

«Запусти субагента для пошуку — він витратить власне контекстне вікно на весь цей шум і поверне два потрібні шляхи до файлів».

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

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

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

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

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

Приклад використання:

«Запустити це на ніч без нагляду?»

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

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

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

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

Уникайте: «фоновий агент» — цей вислів зосереджується на машині («працює у фоновому режимі»), а не на підході людини («користувач відійшов»). AFK називає важливий факт: користувач не стежить за роботою.

Приклад використання:

«Запущу це без нагляду на ніч: три агенти в пісочницях працюють над рефакторингом, уранці перегляну PR».

«Обхід дозволів?»

«Так, файлова система лише для читання, без мережі».

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

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

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

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

Приклад використання:

«Під час запусків без участі людини агент постійно випускає зламаний код».

«Які автоматизовані перевірки під’єднано до пісочниці?»

«Лише модульні тести».

«Додай перевірку типів і лінтер — він сам виправлятиме помилки за їхніми результатами, ще до того, як PR потрапить до репозиторію».

Агент, який перевіряє роботу іншого агента, часто використовуючи іншу модель або системний промпт. Результат недетермінований: агент-рецензент формує судження. Огляд можна запускати будь-де: перед злиттям PR, постфактум за історією комітів або посеред сеансу як субагента. LLM-суддя в CI — це автоматизований огляд, а не автоматизована перевірка: категорію визначає те, що саме стверджує перевірка, а не місце її запуску.

Працює це завдяки відокремленню від агента-виконавця. Якщо попросити агента, який написав код, перевірити власну роботу, користі буде мало: сеанс, у якому виникла помилка, містить і міркування, що її спричинило, а агент читає власні висновки й сприймає їх як підтвердження. Рецензент із новим контекстним вікном не має цієї прив’язаності: він бачить diff так, як його побачив би незнайомець, а саме на цьому й ґрунтується перевірка. Інша модель або системний промпт, спеціально налаштований для рецензування, ще посилюють цей ефект: інші сліпі плями й промпт, зосереджений на тому, що справді важливо (безпека, контракти API, продуктивність), а не на нечіткому «пошукай проблеми».

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

Уникайте: «перевірка ШІ» / «перевірка агентом» — надто розпливчасто, не відрізняє її від самого агента-виконавця.

Приклад використання:

«Ми отримуємо забагато поганих PR із запусків без участі людини».

«Додай перед злиттям етап автоматизованого огляду: інша модель, окремий системний промпт, зосереджений на безпеці й змінах контрактів».

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

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

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

Уникайте: самого вислову «перевірка коду» — незрозуміло, ідеться про людину чи автоматизацію.

Приклад використання:

«Я перевірив результат автономного запуску».

«Ти прочитав diff чи лише підсумок?»

«Diff. У підсумку сказано, що видалено мертвий код, а з’ясувалося, що функцію викликав згенерований файл».

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

Термін походить від Andrej Karpathy, який вигадав його на початку 2025 року: ви «повністю віддаєтеся вайбу» й «забуваєте, що код узагалі існує» — описуєте бажаний результат, приймаєте те, що отримали, і оцінюєте його запуском.

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

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

Уникайте: використовувати «вайб-кодування» як синонім «неякісного програмування з ШІ»: цей термін позначає підхід до перевірки, а не якість отриманого коду.

Приклад використання:

«Ти прочитав, що він змінив у процесі автентифікації?»

«Зробив це вайб-кодингом — вхід усе ще працює, цього мені вистачило».

«Прочитай diff перед відправленням. Вайб-кодування автентифікації — це шлях до витоку секретів у журнали».

Спільне розуміння того, що створюється: його поділяють користувач і агент, але воно відокремлене від будь-якого артефакту. Термін Brooks із книжки The Design of Design: розмова, артефакти передачі і код — це артефакти, які намагаються зафіксувати концепцію дизайну або наблизитися до неї, але жоден із них не є нею. Якість концепції дизайну відчувається через якість розмови, у якій її сформували.

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

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

Приклад використання:

«Він створює саме те, про що я попросив, але результат усе одно неправильний».

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

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

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

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

Приклад використання:

«Він одразу взявся писати специфікацію й неправильно описав логіку скасування».

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

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

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

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

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

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

Приклад використання:

«Ми вже пів години сперечаємося, чи має майстер налаштування бути однією сторінкою, чи трьома кроками».

«Словами цього не вирішити — попроси агента створити обидва прототипи. Пройдемо їх і за п’ять хвилин знатимемо відповідь».

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

Досвід розробника — це взаємодія людини з кодовою базою, і нічого більше. Головна відмінність між аудиторіями в тому, що люди зберігають стан, а агенти є безстанними. Людина один раз вивчає кодову базу й переносить ці знання на кожен наступний день, тому з поганим досвідом розробника можна впоратися: повільний CI обходять, об’єднуючи відправлення змін; бракує документації — один раз запитують у Slack; незрозуміла структура — запам’ятовують, де що лежить. Обхідні рішення накопичуються, і зрештою команда працює продуктивно в кодовій базі, яка їй заважає.

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

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

Приклад використання:

«У нас із досвідом розробника все гаразд — нові співробітники стають продуктивними за тиждень».

«Бо хтось проводить із ними цей тиждень. Агент такого тижня не має; окремо перевірте досвід агента».

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

У якісного досвіду агента є три головні складники:

Досвід агента й досвід розробника перетинаються: хороші перевірки й чиста архітектура допомагають обом аудиторіям, але їхні потреби різняться. Люди миряться з неформальними знаннями команди, повільним CI та фразами на кшталт «спитай Sarah про модуль виставлення рахунків»; агентам це не допомагає. Підказки IDE й гарні панелі керування теж мало корисні агентам: помилки їм потрібні як текст у результаті інструмента. Кодова база може мати хороший DX і поганий досвід агента.

Уникайте: вважати досвід агента синонімом DX — цим аудиторіям потрібні різні інвестиції.

Приклад використання:

«Агент пише чудовий код у репозиторії API й жахливий у фронтенді».

«У репозиторії API строгі типи й швидкий набір тестів; у фронтенді немає ні того, ні іншого, зате є сорок навичок, які завантажуються завжди. Це проблема досвіду агента, а не моделі».

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

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

Поширені тригери й сеанси, які вони запускають:

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

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

Приклад використання:

«Хто виправив усі порушення `no-floating-promises`?»

«Фабрика. Cron-завдання щоночі бере одне правило лінтера й відкриває PR. Я просто переглядаю його вранці».

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

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

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

Єдині контрольні ворота — це автоматизовані перевірки і автоматизований огляд. Якщо вони не знаходять проблему, проблема потрапляє до коду.

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

Приклад використання:

«Хто змінив логіку повторних спроб у службі виставлення рахунків? Ніхто в команді цього не пам’ятає».

«Служба виставлення рахунків — темна фабрика. Агенти зливають усі зміни, що проходять CI. Цю зміну ніхто не прочитав».