Як насправді працює AI coding agent

Після глав 18–21 ми вже вміємо описати вимогу, розбити її на перевірювані частини й спланувати зміни. Глава 22 показала, як перетворити критерії та ризики на план перевірок до написання коду. Тепер розберімося, що відбувається, коли розробник доручає таку роботу AI coding agent — агенту зі штучним інтелектом для розробки. Це не одна «розумна програма», а система з кількох окремих частин: моделі, застосунку, інструментів, середовища й зовнішніх сервісів.

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

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

23.1. AI, мовна модель і агент — різні рівні

Штучний інтелект (AI, Artificial Intelligence) — широка назва методів і програм, що виконують завдання, які зазвичай пов’язують із людськими здібностями: розпізнають мову чи зображення, прогнозують, планують або генерують текст. Саме слово «AI» не говорить, який алгоритм використано і наскільки надійним є результат.

Велика мовна модель (LLM, Large Language Model) — модель, навчена працювати з мовою та іншими послідовностями даних. У спрощеному описі вона отримує контекст і генерує продовження, оцінюючи, які наступні фрагменти найдоречніші в цьому контексті. Це дає змогу відповідати на запитання, узагальнювати текст, пропонувати код і формувати структурований виклик інструмента.

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

Важливо також не плутати три можливості:

1. Модель знає з навчання, як зазвичай виглядає команда або API.
2. Поточний застосунок надав інструмент, який може прочитати чи змінити потрібну систему.
3. Цей інструмент має право й технічну можливість виконати дію саме тут і зараз.

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

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

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

23.2. Із чого складається система

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

Частина	Просте пояснення	Що вона сама по собі не доводить
Модель	Обчислює відповідь на основі отриманого контексту.	Що код виконано, файл прочитано або твердження перевірено.
Застосунок / клієнт	Інтерфейс, через який людина ставить завдання, бачить відповідь і керує сеансом.	Що в застосунку ввімкнені всі можливості, потрібні в іншому продукті.
Harness (оболонка агента)	Організовує запити до моделі, контекст, інструменти, дозволи, повтори, події та завершення роботи.	Що конкретний інструмент доступний або що будь-який запит до нього буде дозволено.
Runtime (середовище виконання процесу)	Фактично запускає програму агента та його інструменти.	Що процес бачить усі файли комп’ютера або має мережевий доступ.
Інструмент (tool)	Окрема операція: прочитати файл, виконати команду, знайти сторінку, створити запис через інтеграцію.	Що його виклик уже спрацював або що результат відповідає вимозі.
Пісочниця (sandbox) / середовище	Робочий простір, у якому інструменти бачать файли, процеси, мережу, залежності й обмеження.	Що там ті самі файли, версії, мережеві маршрути чи дані, що на машині користувача.
Зовнішній сервіс	Система за межами агента: наприклад, GitHub, Jira, база даних або хмарний API (Application Programming Interface — програмний інтерфейс застосунку).	Що інтеграція налаштована, автентифікована, має права запису або повернула очікуваний стан.

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

Harness (буквально «обв’язка», у цій главі — програмна оболонка агента) керує циклом між людиною, моделлю й інструментами. Саме він може додати інструкції, відібрати частину історії, передати схему інструментів, показати запит на дозвіл, запустити команду та повернути її вивід. У невеликій системі ці ролі може виконувати один процес; у хмарному продукті вони розподілені між клієнтом, API та керованим середовищем.

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

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

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

У деяких системах зовнішній API пропонує готовий інструмент, який виконується на стороні постачальника агента. В інших він лише описує операцію, а програму, що викликає Jira чи GitHub, пише й запускає розробник. Тому питання «де виконується цей tool?» треба ставити окремо від «хто його описав?» і «які повноваження він має?».

23.3. Спостережуваний цикл: побачити, обрати, виконати, перевірити, скоригувати

Зручна навчальна схема роботи агента має п’ять фаз:

observe → decide → act → inspect → adjust побачити → обрати → виконати → перевірити → скоригувати

Цикл не є обов’язковим протоколом конкретного постачальника. Він допомагає відстежити зовнішні події:

1. Побачити (observe). Агент отримує запит і доступний контекст: інструкції, файли, попередні повідомлення або результат попереднього інструмента.
2. Обрати (decide). Модель повертає відповідь чи структурований запит на інструмент. Це видимий вибір наступної операції, а не вікно у прихований внутрішній монолог моделі.
3. Виконати (act). Harness перевіряє формат і дозволи та, коли це дозволено, виконує дію.
4. Перевірити (inspect). Система отримує фактичний результат: вміст файла, код завершення процесу, помилку сервера чи створений ідентифікатор запису. Модель може отримати цей результат; людина часто бачить його в журналі або інтерфейсі.
5. Скоригувати (adjust). На підставі результату агент може продовжити іншим інструментом, змінити гіпотезу, попросити уточнення або зупинитися й повідомити обмеження.

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

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

Виклик інструмента: запит не дорівнює виконанню

Опис інструмента повідомляє моделі:

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

Схема зменшує частину помилок формату, але не замінює перевірку бізнес-правил. Навіть валідний JSON (JavaScript Object Notation — текстовий формат обміну структурованими даними) може містити неправильний ідентифікатор проєкту або небезпечне значення.

Повний цикл виклику зазвичай виглядає так:

1. Harness передає моделі контекст і схему доступного інструмента.
2. Модель повертає структуровану назву інструмента та аргументи.
3. Клієнт або сервер перевіряє їх, застосовує авторизацію й вирішує, чи потрібне підтвердження.
4. Runtime або зовнішній сервіс намагається виконати дію.
5. Harness одержує результат чи помилку й передає його назад у наступному запиті.
6. Модель формує подальшу дію або текстову відповідь.

Наприклад, модель може попросити інструмент read_file відкрити src/billing.py. Якщо схема приймає поле path, це ще не означає, що файл існує, лежить у дозволеному каталозі чи доступний саме цьому сеансу. Реальний результат може бути вмістом, помилкою доступу або «файл не знайдено».

У програмному інтерфейсі Claude запит клієнтського інструмента повертається як блок tool_use, застосунок виконує виклик і надсилає tool_result; у деяких сервісах постачальник сам виконує серверний інструмент. У програмному інтерфейсі OpenAI функціональний виклик зазвичай є одним кроком діалогу між моделлю та програмою: застосунок отримує виклик, виконує свій код і повертає результат із посиланням на той самий виклик. Якийсь код має виконати саме дію — назва API цього не приховує.

Ці відмінності пояснюють, чому однаковий за змістом виклик може поводитися по-різному в Claude Code, ChatGPT, Codex, окремому SDK і самостійно створеному застосунку. Продукт може мати власний набір готових інструментів, власний журнал і власну політику підтверджень.

Повідомлення, дія та доказ

Рівень	Що побачили	Що з цього можна виснувати
Повідомлення	«Змінив файл» або текстова команда у відповіді.	Модель повідомила про намір або заявила про результат. Це ще не запис виконання.
Запит на дію	write_file(path="…", contents="…") чи create_issue(...).	Було сформовано аргументи для операції. Сам факт формування не доводить запуску.
Запис виконання	Інструмент відповів ok, повернув код 0 або повідомив про помилку.	Інструмент дійшов до певного результату. Треба ще з’ясувати, що саме означає ok і чи мався потрібний побічний ефект.
Незалежно перевірений стан	Повторне читання файла, перевірка створеного запису в сервісі, повний тестовий результат на відомій ревізії.	Є конкретний доказ певного стану, зафіксований способом, який можна зіставити з критерієм успіху.

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

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

23.4. Середовище, доступ і дозволи

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

Це відокремлено від того, чи дозволено конкретну операцію. Наприклад, код може бути в змонтованому репозиторії, але запис заблокований. Мережа може працювати, але GitHub-токена немає. Токен може бути, але мати лише читання. Інструмент може вимагати підтвердження перед виконанням. Різні продукти по-різному поєднують ці перевірки.

Для зовнішньої системи слід розрізняти щонайменше:

• наявність інструмента в сеансі;
• автентифікацію (хто саме виконує запит);
• авторизацію (які операції дозволені цьому обліковому запису);
• мережеву доступність сервера;
• політику продукту або робочого середовища;
• підтвердження конкретного побічного ефекту.

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

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

Типові помилки на різних межах

Спостереження	Можлива межа проблеми	Що перевірити далі
Модель вигадала назву файла, функції або параметра	Знання моделі чи неповний контекст	Знайти файл у репозиторії та звірити API-контракт.
Інструмент каже «файла немає»	Робочий каталог, гілка, шлях або доступ	Перевірити pwd, гілку, перелік файлів і дозволені каталоги.
Команда завершується помилкою імпорту	Залежності або інтерпретатор середовища	Зіставити версії, lock-файл, команду підготовки й журнал встановлення.
API повертає 401 або 403	Автентифікація чи авторизація	Перевірити тип облікових даних і права; не просити модель вигадати відсутній токен.
Запис у сервіс завершився тайм-аутом	Зв’язок або невизначений побічний ефект	Спершу прочитати поточний стан; не повторювати запис наосліп.
Тест пройшов у вузькому наборі	Межа перевірки або інший стан коду	Перевірити повний набір, потрібну ревізію, інші суміжні сценарії.
Відповідь каже «готово», але немає журналу чи diff	Спостережуваність або передчасне твердження	Вважати статус непідтвердженим і запросити докази.

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

23.5. Детермінований workflow і агентний вибір

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

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

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

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

23.6. Який стан агент бачить і що може зберегти

«Стан агента» — не одна коробка пам’яті. Треба розрізняти:

1. Контекст поточного запиту: системні та розробницькі інструкції, повідомлення людини, вибраний вміст файлів і повернення інструментів.
2. Історію сеансу: попередні повідомлення, виклики й результати, якщо застосунок їх зберігає й додає до запиту.
3. Стан робочого каталогу: файли, незбережені зміни, активна гілка, встановлені залежності й запущені процеси.
4. Зовнішній стан: записи Jira, гілки GitHub, дані бази, хмарні завдання та їхні дозволи.
5. Тривале налаштування або пам’ять: окремі файли інструкцій, профіль, збережене завдання чи база, якщо продукт це підтримує й завантажує.

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

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

23.7. Як розрізняти агентні продукти

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

Тип	Зазвичай дає	Що треба з’ясувати
Чат-помічник	Діалогову модель; іноді — файли чи підключені сервіси.	Чи має цей сеанс доступ саме до потрібного файла або операції; звичайна розмова не відкриває довільні локальні файли чи команди.
Coding agent	Цикл із робочими файлами та інструментами для читання, редагування чи запуску команд.	Де працює runtime, який знімок проєкту він бачить, які дозволи й інструменти ввімкнені.
Model API та client SDK (Software Development Kit — комплект засобів розробки програмного забезпечення)	Запит до моделі й обробку відповіді; модель може повернути структурований виклик інструмента.	Хто реалізує і виконує клієнтський інструмент, де застосовуються дозволи та як повертається результат. SDK сам собою не відкриває файли чи зовнішні сервіси.
Agent framework (фреймворк агента)	Бібліотеки для циклу агента, оркестрації кроків і викликів інструментів.	Чи запускається цикл у програмі розробника, які компоненти framework виконує сам і що лишається налаштувати розробнику.
Керований runtime (середовище виконання)	Служба керує агентським циклом і надає середовище для команд та файлів.	Де зберігаються файли й стан; де виконується кожен інструмент (частину може виконувати застосунок); які права має процес.

Для будь-якого продукту встановіть три речі: де виконується дія, які ресурси й права отримав саме цей сеанс, і який запис доводить результат. Глави 29–39 розглядають конкретні екосистеми; продуктову назву чи модель не можна вважати відповіддю на ці запитання.

Історичний зріз продуктів, перевірений 23 вересня 2026 року

Наведена нижче карта — історичний зріз перевірених офіційних описів на 23 вересня 2026 року, а не актуальна інструкція з доступності чи конфігурації або повний каталог усіх планів, моделей, регіонів, платформ і налаштувань. Для практичного рішення звіряйте чинні документи потрібного постачальника й облікового запису. Доступність може залежати від країни, плану, версії клієнта, організаційної політики, поступового запуску й того, що адміністратор увімкнув. Наявність назви продукту в документації не означає, що вона доступна кожному обліковому запису. Вендори не оприлюднюють єдиного номера версії для описаних тут постійно оновлюваних поверхонь програмного забезпечення як послуги (Software as a Service, SaaS); там, де є окрема версія CLI, SDK чи локального клієнта, її треба звіряти для конкретного встановлення. Тому в таблиці наведено дату зрізу, статуси, прямо зазначені в документації, і межі доступних версійних даних, а не вигадані номери версій.

Екосистема	Що позначає назва	Де проходить цикл і що не слід припускати
Claude (чат)	Розмовний продукт Anthropic у вебі, настільних і мобільних інтерфейсах. За налаштуваннями може використовувати підключені сервіси.	Сам факт чату не означає роботу з локальним репозиторієм чи довільними командами оболонки. Підключений конектор працює лише в межах доступу, налаштувань і дозволених для нього операцій.
Claude Code	Агентний інструмент для програмування в командному рядку, редакторі, настільному застосунку чи підтримуваному вебсередовищі.	Хоч модель і цикл можуть бути схожими, відрізняються місце виконання коду, доступ до робочого каталогу, мережа та доступні інструменти. У документації вказані локальне, хмарне й окремі віддалені режими; їхні параметри треба перевіряти окремо.
Anthropic API і Client SDK	API для програмного надсилання повідомлень моделі; Client SDK (Software Development Kit — комплект засобів розробки програмного забезпечення) спрощує виклики, типи, передавання даних, обробку помилок і повтори.	SDK викликає API, а не відкриває довільно файли чи Jira. У власних client tools ваш застосунок описує схему, виконує операцію, застосовує дозволи й повертає результат. Інструменти, що виконує сервер постачальника, є окремим типом.
Claude Agent SDK	Програмна бібліотека, яка, за поточною документацією, повторно використовує частини агента Claude Code: його цикл, контекст і вбудовані інструменти.	Розробник запускає її у власному процесі та задає доступ, інструменти й середовище. Вона не тотожна базовому Client SDK для окремих API-запитів.
Claude Managed Agents	Керована Anthropic інфраструктура для тривалих агентних сеансів, з API для конфігурацій, середовищ та стану сеансу.	Документація на дату перевірки позначає API для агентів і сеансів як бета-версії; доступність і підтримку середовищ не можна автоматично переносити на інші плани чи продукти Anthropic.
ChatGPT Chat і Work	Chat — загальний розмовний інтерфейс. Work — окремий режим ChatGPT для складніших багатокрокових завдань, які можуть тривати довше й взаємодіяти з дозволеними застосунками та файлами.	ChatGPT Help Center описує Work як окреме від Chat і Codex представлення. Локальні папки потребують настільного режиму й явного доступу; cloud-сеанси можуть мати інший шлях до файлів. Розгортання і дозволи відрізняються між обліковими записами.
Codex CLI (Command-Line Interface — інтерфейс командного рядка), настільний застосунок та інтеграції редактора	Продукти OpenAI для програмних завдань: командний рядок і клієнтські інтеграції. Станом на 23 вересня 2026 року Codex є окремим режимом у настільному застосунку ChatGPT; 9 липня OpenAI оголосила про об’єднання Codex app із новим ChatGPT desktop app.	Обчислення можуть відбуватися на локальній машині або в керованому хмарному runtime залежно від сценарію. App Server в описі OpenAI обслуговує кілька клієнтських поверхонь, але їхній конкретний набір і можливості не є тотожними. Номер версії настільного клієнта і версію CLI треба перевіряти в конкретному встановленні; для хмарної поверхні в перевірених джерелах є дата й описи функцій, але не єдиний оприлюднений номер версії.
OpenAI API і SDK	Responses API дає змогу надсилати запити моделі; інструментальні виклики передаються обробнику програми. Agents SDK додає цикл, інструменти, передачі керування та інші механізми побудови агента.	Вибір Responses API, Agents SDK чи Agents API визначає, хто організовує цикл, де зберігається стан і хто запускає інструмент. Клієнтський SDK не надає автоматично доступ до комп’ютера чи зовнішнього сервісу.
OpenAI Agents API	На дату перевірки — публічна бета-версія API з керованим Codex harness для тривалих хмарних агентів.	Документація описує керовані сеанси й опційне середовище: OpenAI-hosted sandbox, self-hosted sandbox або без sandbox. Бета-версія й її обмеження не означають однакового середовища для Codex CLI, ChatGPT чи Agents SDK.

Публічний пост OpenAI від 4 лютого 2026 року описує Codex App Server та способи, якими його використовують різні клієнти, зокрема локальні застосунки й інтеграції редакторів, Codex Web runtime та командний рядок. Пізніша довідкова сторінка ChatGPT Work і Codex, перевірена 23 вересня 2026 року, описує Codex як окремий режим у настільному застосунку ChatGPT і каже, що його не можна вибрати у веб- або мобільному ChatGPT, хоча підтримувані віддалені сеанси можна відкрити на мобільному пристрої. Анонс OpenAI від 9 липня 2026 року повідомляє, що Codex app об’єднується з новим ChatGPT desktop app. Тому згадка «Web runtime» у лютневому архітектурному описі не є гарантією, що кожному акаунту доступна однакова вебсторінка або що вона є частиною ChatGPT Web.

Claude Code та Codex — не «сама модель». Вони включають оболонку й домовленості про керування контекстом та інструментами. Anthropic Client SDK і OpenAI API-клієнт — це шлях програми до модельного API; бібліотека агента додає цикл; керована Agents API може додати hosted harness і середовище. Назви близькі, але їхня зона відповідальності відрізняється.

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

23.8. Приклад 1: тест не проходить, після першого виправлення знаходиться друга проблема

Умовна постановка

Уявімо вигаданий магазин із функцією знижки. Авторитетне правило цього навчального прикладу каже: сума зберігається в цілих центах і не може бути від’ємною; знижка — ціле число від 0 до 100 відсотків; залишок округлюється до цента за правилом «половину вгору». Файл src/pricing/discount.py, функції та результати нижче вигадані. Це не реальна задача й не фактичний тестовий запуск.

Початковий видимий запис із CI (Continuous Integration — автоматичної інтеграційної перевірки) містить один невдалий тест:

FAILED tests/test_discount.py::test_half_up_rounds_up
Expected: 905
Actual:   904

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

Крок	Видима дія	Фактичний результат у вигаданому прикладі
1. Побачити	Прочитати критерій і запис CI.	Невідомо, чи CI перевіряв саме поточну локальну ревізію; це ще треба зіставити.
2. Дослідити	Прочитати src/pricing/discount.py та тест test_half_up_rounds_up.	У функції є round(amount_cents * (100 - percent) / 100). Тест очікує 905 для 1005 центів зі знижкою 10%.
3. Обрати	Повернути коротку гіпотезу, яку можна перевірити: використане округлення дає 904.5 до цілого за правилом, відмінним від погодженого «половину вгору».	Гіпотеза узгоджується з конкретними вхідними даними; приховані міркування моделі не потрібні для її перевірки.
4. Виконати	Змінити формулу так, щоб додати 50 перед цілочисельним діленням на 100 для невід’ємних допустимих значень.	Видимий diff показує зміну коду. Сам diff не доводить, що тест проходить.
5. Перевірити	Запустити цільовий тест pytest -q tests/test_discount.py::test_half_up_rounds_up.	Вигаданий вивід: 1 passed. Точкова помилка виправлена в цьому сценарії.
6. Розширити перевірку	Запустити всі тести модуля: pytest -q tests/test_discount.py.	Вигаданий вивід показує інший сценарій, test_negative_percent_rejected: функція не відхилила знижку -10.

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

Далі агент відкриває невдалий тест і критерій. Умова 0 ≤ percent ≤ 100 чітко є у вигаданому правилі, тому потрібна перевірка межі, а не нова продуктова здогадка. Функція отримує перевірки для від’ємної суми та процента поза діапазоном. Після другої зміни агент запускає весь набір модуля знову.

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

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

23.9. Приклад 2: знання про Jira без Jira-інструмента

Умовна постановка

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

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

Чесна відповідь може бути:

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

Це повідомлення й чернетка, а не створений issue. Воно не має ідентифікатора Jira, відповіді від API або запису в історії проєкту. Щоб твердження «задачу створено» стало обґрунтованим, застосунок має надати потрібний інтеграційний інструмент, автентифікований обліковий запис має мати дозвіл створення в конкретному проєкті, а після виклику треба отримати результат і, для важливої дії, перевірити запис у самому Jira.

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

23.10. Приклад 3: одна команда локально й у хмарі

Умовна постановка

Уявімо вигаданий репозиторій, де команда python -m pytest -q локально завершується з 12 passed, а в хмарній пісочниці повертає ModuleNotFoundError: No module named 'dateutil'. Усі назви, команди й результати в цьому прикладі вигадані.

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

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

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

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

23.11. Помилки, перевірка й відповідальність

Поширені збої агентської роботи утворюють ланцюг, і на кожному стику потрібен доказ:

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

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

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

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

23.12. Підсумок

AI coding agent — це модель у складі застосунку, який додає інструкції, контекст, інструменти й правила виконання. Модель може запропонувати дію; її виконує конкретний клієнтський або серверний інструмент у конкретному runtime та з конкретними правами. Локальні, хмарні й підключені до зовнішніх сервісів середовища мають різні межі.

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

Наступна глава докладніше розбере контекст, а глава 28 — інструкції. Глави 29–39 розглядають конкретні екосистеми й способи роботи з ними. У кожній окремій задачі знову перевіряйте, що саме є моделлю, що забезпечує harness, де виконується tool і який видимий результат підтверджує дію.

Джерела та подальше читання

Продуктові сторінки й документацію, що підтримують приклади нижче, перевірено 23–26 вересня 2026 року; сторінки про tool use та function calling повторно відкрито 10 жовтня 2026 року. Посилання на живу документацію без видимої дати публікації можуть змінитися. Публічний звіт постачальника описує його власну систему й заявлену архітектуру, а не є незалежною оцінкою надійності. У цій главі немає незалежного бенчмарка чи порівняльного тестування продуктів. Навчальні приклади й їхні виводи синтетичні.

1. Anthropic, Claude Code Overview, поточна документація без видимої дати оновлення; перевірено 23 вересня 2026 року. Підтримує опис Claude Code та заявлених поверхонь: командного рядка, інтегрованого середовища розробки (IDE, Integrated Development Environment), настільного застосунку й вебу. Це опис постачальника, а не перевірка доступності для кожного облікового запису.
2. Anthropic, How Claude Code works, поточна документація без видимої дати оновлення; перевірено 23 вересня 2026 року. Підтримує опис агентного циклу, ролі моделі, інструментів, середовищ і сеансів.
3. Anthropic, Configure permissions, поточна документація без видимої дати оновлення; перевірено 23 вересня 2026 року. Підтримує твердження, що дозволи залежать від політик інструмента й середовища. Приклади налаштувань є описом реалізації продукту, а не загальним правилом для всіх агентів.
4. Anthropic, Tool use with Claude, поточна документація без видимої дати оновлення; перевірено 10 жовтня 2026 року. Розрізняє client tools, де застосунок виконує запит і повертає tool_result, та server tools, які виконує Anthropic.
5. Anthropic, Claude API overview, поточна документація без видимої дати оновлення; перевірено 23 вересня 2026 року. Підтримує опис Messages API, Client SDK і окремої бета-стадії API для керованих агентських конфігурацій і сеансів. Цей стан може змінитися.
6. Anthropic, CLI, SDKs, and libraries, поточна документація без видимої дати оновлення; перевірено 23 вересня 2026 року. Розрізняє офіційний командний рядок, клієнтські бібліотеки API та інтеграції з іншими фреймворками.
7. Anthropic, Agent SDK overview, поточна документація без видимої дати оновлення; перевірено 23 вересня 2026 року. Підтримує відмінність між Claude Code як CLI, Agent SDK, Client SDK і Managed Agents за тим, де й ким запускається цикл.
8. Anthropic Engineering, Scaling Managed Agents: Decoupling the brain from the hands, опубліковано 8 квітня 2026 року; переглянуто 23 вересня 2026 року. Це виклад Anthropic про її керовані агенти та змінність припущень у harness, не незалежне дослідження.
9. Anthropic Help Center, Use connectors to extend Claude’s capabilities, опубліковано 20 серпня 2026 року; переглянуто 23 вересня 2026 року. Підтримує обмеження конекторів правами вихідного сервісу, налаштуванням доступу й дозволеною категорією дій.
10. OpenAI, Unlocking the Codex harness: how we built the App Server, інженерний матеріал від 4 лютого 2026 року; переглянуто 23 вересня 2026 року. Підтримує опис App Server, видимих елементів сеансу, запитів на дозвіл і різних клієнтських поверхонь. Це опис системи самої OpenAI.
11. OpenAI, Introducing the Agents API, оголошення від 10 вересня 2026 року; переглянуто 23 вересня 2026 року. Позначає Agents API як публічну бета-версію та описує використання керованого Codex harness; доступність і фактичні межі залежать від API-конфігурації.
12. OpenAI, Agents API overview, поточна документація; перевірено 23 вересня 2026 року. Підтримує розрізнення агента, середовища, сеансу та подій, а також керованого контексту й можливих типів середовища.
13. OpenAI, Agents, поточна документація; перевірено 23 вересня 2026 року. Порівнює Agents API, Agents SDK і Responses API за місцем виконання циклу, станом, інструментами й середовищем.
14. OpenAI, Function calling, поточна документація; перевірено 10 жовтня 2026 року. Описує п’ять кроків: передати доступні інструменти, отримати виклик, виконати код на стороні застосунку, повернути результат і прийняти фінальну відповідь або наступний виклик.
15. OpenAI, ChatGPT Work and Codex, довідкову сторінку перевірено 23 вересня 2026 року; під час перегляду сторінка показувала відносний індикатор «оновлено 19 годин тому», а не стабільну дату редакції. Описує Chat, Work і Codex як різні поверхні; зауважує, що доступ, файлове середовище та синхронізація різняться. Вміст швидко змінюється.
16. OpenAI, ChatGPT is now a partner for your most ambitious work, анонс ChatGPT Work від 9 липня 2026 року; переглянуто 23 вересня 2026 року. Це твердження постачальника про багатокрокові завдання й інтеграції, а не незалежна оцінка завершуваності чи точності таких задач.
17. OpenAI, Codex CLI repository, офіційний відкритий репозиторій OpenAI; переглянуто 23 вересня 2026 року. Підтверджує, що Codex CLI є програмним проєктом для командного рядка, а репозиторій містить його реалізацію та інструменти. Стан гілки може змінитися.
18. Учасник GitHub, OpenAI Codex issue #6721: Harness interrupting shell execution and/or truncating output, створено 16 листопада 2025 року; на дату перегляду закрито. Це одиничне повідомлення користувача з версією 0.58.0 та його власним описом; воно не є незалежно відтвореним вимірюванням, відповіддю OpenAI або доказом поточної поведінки.
19. Anthropic, Tools for Claude Managed Agents, поточна документація; перевірено 26 вересня 2026 року. Розрізняє вбудовані інструменти керованого агента та користувацькі інструменти, які виконує застосунок.

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

Назви чатів, coding agents, SDK, agent frameworks і managed runtimes не завжди відповідають окремим продуктам: одна система може поєднувати кілька типів. Перед роботою звіряйте актуальні документи саме для потрібної поверхні, встановлення та облікового запису. У цій главі навмисно не наведено модельних версій, цін, лімітів і обіцянок доступності, що швидко старіють.

Історичні невизначеності, зафіксовані станом на 23 вересня 2026 року. Адреса документації OpenAI Codex, згадана в первісному дослідженні (https://developers.openai.com/codex/), тоді переспрямувала на загальний розділ ChatGPT Learn; поверхні Codex звірялися за інженерною статтею OpenAI, офіційним репозиторієм, окремою довідкою й API-документацією. Стаття про App Server називала Codex Web runtime, тоді як довідкова сторінка ChatGPT казала, що Codex не вибирається у веб- або мобільному ChatGPT. Ці записи описували різні поверхні й не підтверджували однакову доступність для всіх акаунтів. Тоді ж Anthropic API огляд позначав Agents, Sessions та Environments API для Managed Agents як бета-функції. Це історична примітка; актуальну наявність перевіряйте за поточною документацією.