Агент пише код. А хто проєктує роботу?

Codex, Claude Code, GitHub і Linear: будуємо середовище, у якому агент доводить завдання до перевірюваного результату

Сергій Авдейчик · DOBROVOLA · 15 вересня 2026 року

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

Іноді — так. А іноді агент просто дуже діяльно провів останню годину.

Про це говорять уже не лише шанувальники нових інструментів. Мартін Фаулер описує agentic programming — розробку, у якій людина спрямовує агента і перевіряє його роботу. Адді Османі пропонує думати не про окремий промпт, а про цикл виконання й оцінювання. Роберт Мартін разом із Джастіном Мартіном показують багатоагентний процес, де написання коду оточене спеціалізованими перевірками. Це різні підходи, а не один маніфест. Але питання в них спільне: як організувати інженерну роботу, коли код створює вже не тільки людина? [1] [2] [3]

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

У попередніх матеріалах ми говорили про Software 3.0 і шлях від розмови до блюпринту, дослідження, технічного завдання та приймання. Тепер рухаємося далі: задум уже зрозумілий — як організувати саму розробку? Пов’язаний матеріал про перевірювану роботу наведено в джерелах. [23]

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

1. Робоче середовище — це не вікно Codex

Коли мене питають, де працює мій агент, відповідь «у Codex» надто коротка. Це приблизно як сказати, що інженер працює в текстовому редакторі. Формально правильно, але з картини зникають проєкт, вимоги, колеги, випробування і сам продукт.

У моїй схемі в проєкту є два репозиторії та простір завдань у Linear.

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

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

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

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

Я пропоную таке розділення: документи відповідають на запитання «що і навіщо будуємо», репозиторій застосунку — «що вже побудовано», Linear — «що відбувається зараз». Завдання і віхи задають великий напрям руху. AGENTS.md, CLAUDE.md, ролі та скіли — тонші регулятори: як діяти і що перевіряти на обраній ділянці. Жоден шар не замінює інші. Два репозиторії не є єдиною можливою архітектурою зберігання. Для невеликої вправи можна почати з двох розділів одного репозиторію. Але межу між задумом і виконанням краще зберігати з першого дня.

Схема 1. Середовище більше за інструмент.

>

Блюпринт і ТЗ у project-docs → віха і завдання в Linear → робота агента → зміни та перевірки в project-app → рішення людини.

>

Коментарі в Linear пов’язують доручення, результат і наступний крок. Codex і Claude Code перебувають усередині цього процесу, а не замінюють його.

Як не отримати три конкуруючі версії правди

Не копіюйте одну й ту саму вимогу в п’ять місць. У завданні вкажіть конкретний розділ ТЗ і його версію. У pull request — далі PR — вкажіть завдання. У коментарі з результатом — PR і точний коміт, який перевірявся.

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

2. Що насправді отримує модель

Слово harness можна розуміти як «обв’язка» навколо моделі. Це програмний шар, який передає контекст, організовує виклики інструментів і повернення результатів, підтримує цикл роботи. В інженерному розборі OpenAI добре видно: модель і агентний цикл — не одне й те саме. [5]

Тепер важливе розгалуження. Є смислова організація проєкту, а є технічне складання входу моделі. Їх легко переплутати.

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

В опублікованому OpenAI розборі Codex початковий запит містить базові інструкції, повідомлення розробника про середовище й налаштування, контекст користувача з файлів проєкту та інформацію про скіли, а потім поточне завдання. Це опис конкретного пристрою, опублікований 23 січня 2026 року, а не обіцянка незмінного порядку для всіх майбутніх клієнтів. [5]

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

Codex і Claude Code мають схожі цілі, але не однакові механізми

У Codex проєктні інструкції збираються з AGENTS.md і, за наявності, AGENTS.override.md. Враховуються налаштування користувача і шлях від кореня проєкту до поточного робочого каталогу; локальніші інструкції додаються пізніше. Не слід очікувати, що всі файли в усіх підкаталогах заздалегідь потраплять у контекст. Документація окремо описує межу обсягу та побудову ланцюжка інструкцій під час запуску. [6]

Claude Code використовує CLAUDE.md, проєктні правила і пам’ять. Документація прямо відділяє їх від конфігурації, що виконується примусово. Файли в батьківських каталогах можуть завантажуватися під час старту, інструкції з вкладених каталогів — підключатися в міру читання відповідних файлів. Підтримуються імпорти на кшталт @шлях; наявність файлу сама по собі ще не доводить, що його підключено правильно. [7]

Схема 2. Два різні контури.

>

Контекст моделі: інструкції платформи → підключені правила проєкту → поточне завдання → прочитані матеріали й результати інструментів.

>

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

>

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

Інструкція, повноваження й обмеження — три різні речі

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

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

Для навчального проєкту я рекомендую окремі тестові дані, мінімально необхідні доступи та заборону автоматичного релізу без погодженої перевірки. У GitHub можна вимагати PR, checks і review перед merge; доступність конкретних правил залежить від тарифу й типу репозиторію. Важливо також перевірити можливі обходи правил адміністратором або сервісним обліковим записом. [9]

Ще один нюанс: локальний sandbox не варто автоматично вважати захистом для зовнішнього MCP-інструмента. Віддалений сервіс повинен сам перевіряти права і допустимі операції. Цю межу окремо відзначено в розборі Codex. [5]

3. Спочатку стартовий пакет. Не конституція на двісті сторінок

Мій звичний шлях починається не з команди «створи застосунок». Спочатку я передаю текстовій моделі затверджені блюпринт і ТЗ та свої дизайнерські вподобання. У моїй практиці це часто GPT у режимі Pro. Прошу вивчити актуальну документацію обраної агентної платформи й підготувати стартовий набір файлів.

Ключове слово — стартовий.

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

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

Цей підхід не прив’язаний до Python

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

Для Python у профілі стеку можуть бути pytest, ruff, прийняті правила типів і розміщення модулів. Для TypeScript — менеджер пакетів, команди перевірки типів, тестування й build. Запис pnpm test має сенс лише тоді, коли відповідний сценарій справді визначено в проєкті. Копіювання чужого файлу не створює відсутньої інфраструктури.

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

Схема 3. Що переноситься між проєктами.

>

Ядро: джерела вимог, ролі, передавання роботи, приймання.

>

Профіль стеку: мова, залежності, структура, команди запуску й тестів.

>

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

>

Під час переходу з Python на TypeScript не потрібно заново вигадувати керування роботою. Але команди й структуру слід перевірити знову.

Мінімальна структура може виглядати так:

workspace/
  project-docs/                 # окремий Git-репозиторій
    blueprint.md
    specifications/project.md
    milestones/M1.md
    decisions/
    agent-design/roles/
    agent-design/skills/
  project-app/                  # окремий Git-репозиторій
    AGENTS.md
    CLAUDE.md
    PROJECT_CONTEXT.md
    STACK.md
    src/
    tests/
    .gitignore

PROJECT_CONTEXT.md — наша карта входу: адреси репозиторіїв, версії документів, активна віха, спосіб доступу. STACK.md — реальні команди й домовленості. Каталоги agent-design/roles та agent-design/skills — наші вихідні матеріали, а не магічні імена, які автоматично читає будь-який агент.

Доручення моделі, яка збирає пакет

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

Отриманий ZIP усе одно треба прочитати. Особливо розділи про права, зовнішні дії, виконання скриптів і критерії «готово». Людська перевірка стосується й інструкцій, не лише коду.

Доручення агенту, який розгортає пакет

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

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

4. Як писати AGENTS.md, ролі та скіли без магії

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

Загальні інструкції відповідають: «Які правила діють постійно?» Роль — «За який результат ви відповідаєте зараз?» Скіл — «Як виконати повторювану процедуру?»

Тонкий AGENTS.md

Ось навчальна заготовка. Посилання й команди в реальному проєкті повинні вести до наявних матеріалів.

# Робота в проєкті

Перед початком прочитайте PROJECT_CONTEXT.md і STACK.md.
Працюйте лише над призначеним завданням поточної віхи.
Звірте версію ТЗ і критерії приймання в Linear.

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

Не додавайте незапитаний функціонал і рефакторинг.
Не публікуйте секрети. Не виконуйте реліз без дозволу.

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

Не потрібно перелічувати тут усі endpoint-и застосунку. Файл повинен допомагати знайти потрібні правила, а не конкурувати з ТЗ.

Для Claude Code можна зробити невеликий CLAUDE.md, який підключає спільну основу, а нижче містить лише відмінності клієнта:

@AGENTS.md

# Особливості Claude Code
Перед початком перевірте доступність потрібних інструментів.
Роль і завдання отримайте зі стартового доручення.

Такий імпорт підтримується Claude Code. Після налаштування перевірте завантажений контекст засобами клієнта; не вважайте сам факт збереження файлу доказом його застосування. [7]

Роль — не перелік усіх чеснот ідеального програміста

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

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

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

На дату перевірки Codex підтримує проєктні визначення користувацьких агентів у .codex/agents/*.toml; Claude Code — у .claude/agents/*.md із конфігураційним заголовком. Це різні формати. Наш текст ролі потрібно явно передати сесії або оформити у відповідному адаптері. [12] [13]

Скіл: коли, з чим і до якого результату

На обох платформах скіл будується навколо SKILL.md. Опис допомагає вибрати процедуру, а подробиці підключаються за потреби. Для проєктного розміщення документація Codex вказує .agents/skills/, Claude Code — .claude/skills/. Спільність ідеї не означає тотожність усіх додаткових полів і способів підключення. [10] [11]

Приклад власної процедури:

---
name: verify-delivery
description: Перевірка результату завдання перед передаванням людині.
---

Вхід: завдання, критерії приймання, коміт для перевірки,
перелік змінених файлів і результати CI.

1. Зіставте кожен критерій із перевірюваним доказом.
2. Перевірте основний, порожній і помилковий сценарії.
3. Звірте зміни з межами завдання.
4. Використовуйте дозволені команди з STACK.md.
5. Відділіть дефекти від неперевірених припущень.

Вихід: виконані критерії, дефекти, неперевірені пункти,
посилання на докази та рекомендація наступного кроку.

Не виправляйте код у межах цього скіла.
Не змінюйте критерії та не виконуйте merge або release.

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

Перевіряйте й самі скіли. Дайте процедурі PR із навмисно пропущеним сценарієм, а потім коректний PR. У першому випадку вона має помітити прогалину, у другому — не вигадувати дефект заради переконливого звіту. Тестувати можна не лише застосунок, а й спосіб роботи над ним.

5. Одна віха — один зрозумілий результат

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

Погана віха: «Розробити систему аналітики навчальної активності».

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

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

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

Як виглядає картка, за якою можна працювати

Умовне завдання READ-12:

Результат: звіт за обраний період показує заняття і суму відомих тривалостей.

>

Підстава: затверджений розділ ТЗ і версія набору прикладів.

>

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

>

Критерії: період трактується як напівінтервал [початок, кінець) у погодженому часовому поясі; враховуються лише записи поточного користувача. Для прикладу «20 хвилин, 35 хвилин, тривалість не вказана» результат — 55 відомих хвилин і один запис із невідомою тривалістю. Пропуск не перетворюється на нуль. Порожній період — нормальний порожній звіт, а не помилка.

>

Докази: тести розрахунку й меж періоду, перевірка ізоляції даних користувачів, відтворення екрана, посилання на PR і коміт.

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

Не плутайте «тести зелені» з «завдання розв’язано»

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

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

Схема 4. Від завдання до доставки.

>

Критерій → приклад з очікуваним результатом → зміна коду → перевірка конкретного коміту → PR → рішення людини → merge у main → перевірка погодженого середовища.

>

Наступну віху докладно плануємо на основі прийнятого результату попередньої. Merge і deployment — різні події.

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

6. Непродуктивне кодування: коли рухаються файли, але не продукт

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

Я називаю це непродуктивним кодуванням: активність навколо коду підміняє просування до прийнятого результату.

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

Тому я дивлюся не на кількість комітів. Я запитую: що стало доступним користувачеві? Який ризик зменшився? Що заважає завершити завдання? Скільки часу і повторних запусків вимагав прийнятий результат?

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

Інструкції змінюються і всередині віхи

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

Я пропоную маленький цикл: знайти конкретний епізод → визначити причину → змінити потрібний елемент середовища → повторити перевірку.

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

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

Переконайтеся, що зміни справді застосувалися. Codex документує побудову ланцюжка AGENTS.md під час запуску; для активної сесії не можна просто припустити, що новий файл уже замінив старий контекст. Перезапуск або передбачене клієнтом оновлення контексту має бути частиною процедури. [6]

7. Керівник і виконавець: розділяємо увагу, а не малюємо посади

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

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

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

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

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

Спільна пам’ять процесу — коментарі в Linear

Чат зручний, щоб запустити роботу. Але доручення, результат і коригування повинні залишатися в картці завдання. Інакше наступний учасник муситиме вгадувати, що було вирішено в закритій переписці.

Я пропоную короткий протокол коментарів. Це наша домовленість, а не вбудований стандарт Linear:

ДОРУЧЕННЯ / версія 2
Завдання: READ-12. ТЗ: версія і розділ.
Мета і межі: ...
Критерії: ...
Контрольна точка й умови зупинки: ...

РЕЗУЛЬТАТ / відповідь на доручення версії 2
Гілка, PR, коміт для перевірки: ...
Що змінено: ...
Команди й фактичні результати перевірок: ...
Що не перевірено і чому: ...
Блокери й наступний крок: ...

ПЕРЕВІРКА / того самого коміту
Підтверджено: ...
Дефекти з відтворенням: ...
Коригування або рекомендація людині: ...

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

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

Схема 5. Контроль без другого виконавця.

>

Людина задає мету і приймає результат.

>

Керівник → доручення в Linear → виконавець → PR і докази в Linear → перевірка керівника → рішення людини.

>

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

Що саме перевіряє керівник

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

Наприклад: «Тест суми проходить, але невідома тривалість не перевірена. Відтворіть приклад із ТЗ. Не змінюйте API цілком: виправте обробку пропуску і додайте потрібну перевірку». Це корисніше, ніж «підвищте якість, дійте професійно».

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

8. Довгий цикл: спочатку вручну, потім автоматично

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

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

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

Документація OpenAI розрізняє заплановані завдання у вебінтерфейсі й настільному застосунку; для локальної роботи важлива доступність комп’ютера і файлів. CLI та IDE не слід автоматично приписувати той самий інтерфейс керування розкладом. Перевіряйте актуальні можливості свого клієнта й акаунта. [14]

У Claude Code документовано /loop, зокрема із заданим інтервалом. Це сесійний механізм: виконання залежить від життя сесії, зайнятості агента і правил планувальника; можливі затримки, повторювані завдання мають строк дії. Це не таймер реального часу. [15]

Навчальний приклад для окремої сесії керівника з уже налаштованими доступами:

/loop 30m Перевірте нові докази щодо READ-12 в Linear
і пов’язаний PR. Код не змінюйте. Зіставте прогрес
із критеріями. Залиште коригування лише за наявності
нового дефекту, блокера або відхилення від мети.

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

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

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

9. Для допитливих: OpenAI Symphony

Тут варто зазирнути за межі ручного перемикання між чатами. В OpenAI є Symphony — не Symfony, PHP-фреймворк, а інший проєкт зі схожою назвою.

Репозиторій Symphony містить специфікацію та експериментальну реалізацію оркестратора; автори позиціонують його як engineering preview для довірених середовищ. Це матеріал для вивчення й адаптації, а не обіцянка універсальної production-системи. [16]

Ідея така: оркестратор отримує придатне завдання з трекера, готує окремий workspace, запускає агента і відстежує життєвий цикл роботи. У специфікації розділено налаштування виконання й текст завдання; їх можна зберігати у версійованому WORKFLOW.md. Передбачено керування конкурентністю, повторні спроби та звіряння стану. [17]

У прикладі workflow важливу частину обміну з Linear виконує сам агент через доступні інструменти. Це не означає, що один файл WORKFLOW.md автоматично підключить ваш акаунт і всі права. Приклад потребує осмисленого налаштування інтеграцій. [18]

Схема 6. Оркестратор і керівник — не одне й те саме.

>

Оркестратор: вибрати допустиме завдання → виділити workspace → запустити → спостерігати стан → повторити або завершити.

>

Керівник-агент: перевірити зміст результату → знайти відхилення → запропонувати коригування.

>

Ці функції можна поєднувати. Наявність планувальника сама по собі не дає змістовної перевірки продукту.

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

Перед використанням чужого workflow перевірте стани, переходи, дозволи й умови передавання людині. Зокрема, успішне завершення роботи агента може означати готовність до людської перевірки, а не автоматичний merge і release. Для нашої методики ця різниця принципова. [17] [18]

10. Що справді змінюється: публікації та спостереження

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

Є й перевірювані сигнали напряму. 10 вересня 2026 року OpenAI представила публічну бету Agents API: кероване виконання з Codex harness та інфраструктурою для довготривалої роботи агентів. Це окремий продуктовий анонс, а не нова команда наявного CLI. Твердження про тривалість роботи належать до опису вендора, а не до нашого тесту студентського проєкту. [19]

25 травня 2026 року Anthropic опублікувала розбір containment — обмеження того, до чого агент узагалі може дістатися. Важливий сам інженерний акцент: тривала робота потребує не тільки вдалих інструкцій, а й заздалегідь спроєктованих меж середовища. [8]

Раніші матеріали — OpenAI про harness engineering від 11 лютого й Anthropic про довготривалу розробку застосунків від 24 березня 2026 року — показують передумови цього підходу: середовище, зворотний зв’язок та організація тривалої роботи стають окремою інженерною задачею. Це корисний фундамент, але його не варто видавати за публікації останніх чотирьох місяців. [20] [21]

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

Три свіжі голоси — й одна корисна давніша пересторога

Мартін Фаулер, 21 травня 2026 року. У нотатці Agentic Programming він розрізняє роботу з агентом під осмисленим контролем розробника та підхід, за якого людину перестає цікавити отриманий код. Для нашого курсу це важлива межа: делегувати реалізацію не означає перестати розуміти систему. Перевірка, розуміння і спрямування роботи залишаються значущими. [1]

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

Адді Османі, 7 червня 2026 року. У Loop Engineering фокус переноситься на організацію повторюваного циклу: виконання, оцінювання, збереження стану й наступний крок. Це близько до нашої ідеї довгої роботи в межах віхи. Проте зі статті не випливає, що будь-яка кількість автономних циклів корисна: цикл має давати перевірюване просування, а складність керування повинна окупатися. [2]

Чому варто прочитати: щоб подивитися на автоматизацію ширше за один промпт і водночас побачити ціну погано влаштованого циклу.

Роберт Мартін і Джастін Мартін, червень 2026 року. Публічний опис шостого випуску Agentic Discipline показує Swarm Forge: різні етапи постановки завдання, реалізації, очищення, архітектурної перевірки та контролю якості. Відкритий опис дає змістовний приклад розподілу інженерних компетенцій між агентами; повний відеовипуск доступний окремо. [3]

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

Кент Бек, 23 квітня 2026 року — раніша пересторога. У Nobody Wants Agents він описує неприємний ефект: хотів змінити програму, а натомість отримав роботу з координації кількох агентів. Це особистий розбір конкретного досвіду, а не універсальна заборона багатоагентності. Але він дає чудовий критерій: інструмент має допомагати отримувати результат, а не створювати нове навантаження заради обслуговування самого себе. [22]

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

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

11. Автономність збільшує ціну нечіткого задуму

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

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

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

Схема 7. Залишити свободу реалізації, прибрати невизначеність результату.

>

Нечітка мета → багато непорівнюваних трактувань → важко прийняти роботу.

>

Чітка мета + межі + приклади + перевірки → кілька допустимих реалізацій → перевірюваний вибір.

>

Ми обмежуємо не кожен крок агента, а властивості результату й наслідки дій.

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

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

Не потрібно перетворювати середовище на в’язницю з тисячі інструкцій. Хороша постановка залишає виконавцю вибір реалізації — і не залишає двозначності щодо обов’язкового результату.

12. Невеликий експеримент замість великої віри

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

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

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

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

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

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

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

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

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

Як змінюється робота розробника

[1] Martin Fowler — Agentic Programming. 21.05.2026. https:/​/​martinfowler.com/​bliki/​AgenticProgramming.html

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

[2] Addy Osmani — Loop Engineering. 07.06.2026. https:/​/​addyosmani.com/​blog/​loop-engineering/​

Чому варто прочитати: пропонує розглядати керований цикл, а не окремий вдалий промпт.

[3] Robert Martin, Justin Martin — Agentic Discipline 6: Swarm Forge Demonstration. Червень 2026. https:/​/​cleancoders.com/​episode/​agentic-discipline-6

Чому варто прочитати: публічний опис показує розподіл інженерних компетенцій між агентами. Повний випуск платний; висновки статті обмежені відкритим описом.

Зібрати робоче середовище

[4] Linear — Project milestones. Документація. https:/​/​linear.app/​docs/​project-milestones

Чому варто прочитати: дозволяє перетворити слово «віха» на конкретну структуру завдань і не плутати відсоток в інтерфейсі з прийманням продукту.

[5] OpenAI — Unrolling the Codex agent loop. 23.01.2026; базовий матеріал. https:/​/​openai.com/​index/​unrolling-the-codex-agent-loop/​

Чому варто прочитати: пояснює складання контексту і межу між моделлю, harness та інструментами в конкретній реалізації.

[6] OpenAI — Custom instructions with AGENTS.md. Документація. https:/​/​learn.chatgpt.com/​docs/​agent-configuration/​agents-md

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

[7] Anthropic — How Claude remembers your project. Документація. https:/​/​code.claude.com/​docs/​en/​memory

Чому варто прочитати: пояснює CLAUDE.md, імпорти, локальні правила та відмінність контексту від примусово виконуваних обмежень.

[8] Anthropic — How we contain Claude across products. 25.05.2026. https:/​/​www.anthropic.com/​engineering/​how-we-contain-claude

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

[9] GitHub — About protected branches. Документація. https:/​/​docs.github.com/​en/​repositories/​configuring-branches-and-merges-in-your-repository/​managing-protected-branches/​about-protected-branches

Чому варто прочитати: допомагає технічно закріпити порядок review і перевірок перед зміною основної гілки.

[10] OpenAI — Build skills. Документація. https:/​/​learn.chatgpt.com/​docs/​build-skills

Чому варто прочитати: показує формат SKILL.md, виявлення скілів і підключення подробиць за потреби.

[11] Anthropic — Extend Claude with skills. Документація. https:/​/​code.claude.com/​docs/​en/​skills

Чому варто прочитати: дозволяє адаптувати процедуру під Claude Code, не припускаючи повної взаємозамінності конфігурацій платформ.

[12] OpenAI — Subagents. Документація. https:/​/​learn.chatgpt.com/​docs/​agent-configuration/​subagents

Чому варто прочитати: пояснює, як логічну роль перетворити на реально налаштованого спеціалізованого агента.

[13] Anthropic — Create custom subagents. Документація. https:/​/​code.claude.com/​docs/​en/​sub-agents

Чому варто прочитати: допомагає задати окремий контекст, призначення й інструменти помічника; формат слід перевіряти для використовуваного клієнта.

Автоматизувати лише зрозумілий процес

[14] OpenAI — Scheduled tasks. Документація. https:/​/​learn.chatgpt.com/​docs/​automations?surface=app

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

[15] Anthropic — Run prompts on a schedule. Документація. https:/​/​code.claude.com/​docs/​en/​scheduled-tasks

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

[16] OpenAI — Symphony, офіційний репозиторій. Engineering preview. https:/​/​github.com/​openai/​symphony

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

[17] OpenAI — Symphony Specification. https:/​/​github.com/​openai/​symphony/​blob/​main/​SPEC.md

Чому варто прочитати: дозволяє вивчити стани, workspace, повторні спроби й контракт WORKFLOW.md незалежно від мови реалізації.

[18] OpenAI — Symphony: приклад WORKFLOW.md. https:/​/​github.com/​openai/​symphony/​blob/​main/​elixir/​WORKFLOW.md

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

Зрозуміти напрям — без обіцянок магії

[19] OpenAI — Introducing the Agents API. 10.09.2026. https:/​/​openai.com/​index/​introducing-the-agents-api/​

Чому варто прочитати: свіжий приклад того, яку частину тривалого виконання вендор переносить у керовану платформу.

[20] OpenAI — Harness engineering: leveraging Codex in an agent-first world. 11.02.2026; базовий матеріал. https:/​/​openai.com/​index/​harness-engineering/​

Чому варто прочитати: показує, чому структура репозиторію та зворотний зв’язок стають частиною інженерної роботи з агентами.

[21] Anthropic — Harness design for long-running application development. 24.03.2026; базовий матеріал. https:/​/​www.anthropic.com/​engineering/​harness-design-long-running-apps

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

[22] Kent Beck — Genie Lessons: Nobody Wants Agents. 23.04.2026; раніший авторський досвід. https:/​/​newsletter.kentbeck.com/​p/​genie-lessons-nobody-wants-agents

Чому варто прочитати: допомагає помітити момент, коли керування агентами стало новою проблемою замість розв’язання старої. Автор зазначає спонсорство описаної сесії компанією Augment Code.

[23] Сергій Авдейчик — Ви отримали відповідь. А хто організував роботу? 12.09.2026. https:/​/​dobrovola.dev/​uk/​writing/​from-ai-answers-to-verifiable-work

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