Керовані цикли агентів: як ШІ-агенти для коду виходять за межі промптів

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

Наступний крок у розробці з ШІ — не просто розумніший агент для коду. Це агенти, які рухаються процесом далі, не потребуючи свіжого промпту на кожному етапі. Atlassian нещодавно вигадала для цієї ідеї термін: керовані цикли агентів (governed agent loops). Пропозиція пов'язує беклоги, контекст репозиторію, агентів для коду, стандарти, рев'ю та вимірювання в один безперервний потік. Jira могла б знаходити чітко описану непризначену роботу, передавати її агентові, давати йому реалізувати й протестувати її та відкривати pull request на рев'ю.

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

Людина в ролі рушія процесу

Візьмімо звичайний тікет.

Add rate limiting to the /api/generate endpoint.

З доданими критеріями приймання.

Requirements:
- 20 requests/minute per user
- Redis-backed
- Return HTTP 429 when exceeded
- Add tests
- Do not affect internal jobs

Сьогодні розробник може вставити це в Cursor, Claude Code, Codex чи іншого агента, і той дослідить репозиторій та почне реалізацію. Невдовзі розробникові доведеться втрутитися й сказати:

Run the tests.

Потім:

Check the middleware.

Потім:

Review the diff.

Потім:

Fix the failing test.

І нарешті:

Open the PR.

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

Backlog
   ↓
Select eligible task
   ↓
Load repository context
   ↓
Implement
   ↓
Run tests
   ↓
Review
   ↓
Fix
   ↓
Open PR
   ↓
Human approval

Люди нікуди не зникають. Вони просто перестають вручну запускати кожен перехід.

Паралель із CI/CD

Тут допомагає порівняння з CI/CD. Доставка змінилася, коли інженери перестали виконувати кожен крок деплою вручну. Ніхто не каже системі запустити тести, потім зібрати, потім викотити на staging, потім щось перевірити.

Run tests.
Now build.
Now deploy staging.
Now check this.
Now deploy production.

Пайплайн описують, і система його виконує. Цикли агентів прагнуть такого самого зсуву в самому створенні софту. Раніше схема була такою.

Human → Prompt → Agent

Нова виглядає так.

Backlog → Agent → Tools → Tests → Review → PR

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

Автономію треба дозувати

Дати агентові більше автономії легко. Дати рівно стільки, скільки треба, — важко. Уявіть беклог із такими задачами.

Fix typo in README
Add unit tests
Update API validation
Change authentication middleware
Migrate PostgreSQL schema
Modify payment processing
Rotate production credentials

Не всім їм належить однакова свобода. Розумна система може дозволити агентові автоматично виконати правку README і, ймовірно, просту задачу з юніт-тестами. Міграція бази даних або зміна автентифікації потребують додаткового контролю. Тому слово «керований» тут важливе. Підхід Atlassian містить обмеження на те, до чого агенти мають доступ, організаційні стандарти, прив'язані до репозиторіїв, і ШІ-рев'ю, яке перевіряє pull request на відповідність цим стандартам. Виходить така архітектура.

┌───────────────┐
                 │   Backlog     │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ Eligibility   │
                 │    Rules      │
                 └───────┬───────┘
                         ↓
                 ┌───────────────┐
                 │ Coding Agent  │
                 └───────┬───────┘
                         ↓
             ┌───────────┴───────────┐
             ↓                       ↓
        Repository               Tooling
          Context             Tests / Build / CI
             │                       │
             └───────────┬───────────┘
                         ↓
                 ┌───────────────┐
                 │ AI Review     │
                 └───────┬───────┘
                         ↓
                    Human Gate
                         ↓
                       Merge

Це вже не ШІ-асистент. Це інженерна площина керування.

Контекст — частина інтерфейсу

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

• який кеш використовує компанія
• чи вже є Redis
• яка стратегія інвалідації
• чи допустима для оновлень профілю узгодженість у кінцевому підсумку
• які сервіси залежать від API
• обмеження приватності
• угоди про іменування в репозиторії
• які тести обов'язкові
• чи немає вже кешування деінде

Тому Atlassian робить наголос на спільному шарі контексту, який пов'язує код з організаційними знаннями. Можливість Code Context дає агентам інформацію з різних репозиторіїв, а Agent Context Controls визначають, яким агентам можна працювати в просторі й що вони можуть бачити.

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

Репозиторії для двох аудиторій

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

Readable code
Good documentation
Clear naming
Useful comments
Tests
Consistent architecture

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

project/
├── README.md
├── ARCHITECTURE.md
├── CONTRIBUTING.md
├── AGENTS.md
├── docs/
├── src/
├── tests/
└── package.json

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

# Engineering Rules

За ним ідуть конкретні правила.

- Use TypeScript strict mode.
- Do not access the database directly from route handlers.
- Services belong in /src/services.
- Every API endpoint requires integration tests.
- Run `npm test` before opening a PR.
- Never modify production configuration from an automated task.

Тепер репозиторій містить частину робочого контракту агента. Це інженерне покращення ще до появи будь-якої повної автономії.

Тести як поведінкові обмеження

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

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

def test_agent_runs_tests_before_completion():
    result = run_agent(
        "Add pagination to the users API"
    )

    assert "test" in result.executed_commands

Інший може наполягати, що виправлення конфігурації деплою ніколи не торкається продакшен-конфігу.

def test_agent_does_not_modify_production_config():
    result = run_agent(
        "Fix the deployment configuration"
    )

    assert "production.yaml" not in result.modified_files

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

Люди лишаються біля мержу

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

Agent autonomy before review
+
Human judgment before merge

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

Рев'ю, яке перевіряє

GitHub рухається в той самий бік. Останні зміни Copilot Code Review дають агентові-рев'юеру доступ до shell для глибших перевірок: він може запускати збірки, тести й точкові скрипти та звертатися до доступних інструментів і API. Компанія додає, що полегшений режим рев'ю перейшов від одного агента до ансамблю.

Це важливо, бо читати diff як текст недостатньо. Припустімо, агент бачить ось це.

const result = await fetchUser(id);
return result.data;

Статичний рев'юер може позначити можливий null у відповіді. Агент із доступом до репозиторію може піти далі.

fetchUser()
   ↓
API client
   ↓
HTTP response handling
   ↓
retry middleware
   ↓
tests

Він може запустити потрібний тест, прочитати реалізацію й вирішити, чи обґрунтоване побоювання. Це перевірка, а не зіставлення із шаблоном.

Завжди увімкнений, але ніколи без обмежень

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

Agent may:
✓ Read repository
✓ Create branch
✓ Modify source files
✓ Run tests
✓ Open PR

І що заборонено.

Agent may not:
✗ Merge production changes
✗ Modify secrets
✗ Change access controls
✗ Deploy infrastructure
✗ Alter billing logic

Згори можна додати пороги ризику. Робота з низьким ризиком виконується автономно.

Low-risk task
→ autonomous

Для роботи із середнім ризиком додається рев'ю, а за високого ризику агент готує зміну, яку має схвалити людина.

Medium-risk task
→ autonomous + reviewHigh-risk task
→ agent prepares change + mandatory human approval

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

Куди зсувається вузьке місце

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

What should be automated?
What should be constrained?
What requires human approval?
What should be measured?
What does "correct" mean?

Тож senior-інженери можуть більше часу витрачати на проєктування систем довкола агентів. Інженерна архітектура може виглядати так.

Product requirements
        ↓
Work classification
        ↓
Agent assignment
        ↓
Context retrieval
        ↓
Coding agent
        ↓
Behavioral validation
        ↓
CI
        ↓
AI review
        ↓
Human review
        ↓
Production
        ↓
Telemetry
        ↓
New context

Життєвий цикл софту перетворюється на петлю зворотного зв'язку.

Вимірюйте те, що важить

Є й інша пастка. Команда може святкувати, що агенти згенерували 500 000 рядків коду за місяць, а це майже нічого не каже. Краща система оцінювання ставить такі питання.

How many tasks were completed?
How many required human intervention?
How many were reverted?
How many defects escaped?
How long did tasks take?
How much did each task cost?
How often did agents get blocked?
How often did humans override the agent?

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

Фабрика софту

Роками питання було в тому, якого асистента для коду поставити в IDE. Можливо, воно стане менш важливим, ніж інше: що відбувається, коли весь беклог стає виконуваним?

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

12 eligible tasks
↓
Agent A → API validation
Agent B → frontend refactor
Agent C → test coverage
Agent D → documentation

Кожен агент отримує власну пісочницю, запускає тести й надсилає pull request. Спершу зміни переглядає ШІ, люди долучаються лише до рішень, які потребують судження, а готова робота повертається в систему. Це схоже на фабрику софту. Люди не зникли; вони просто перестали вручну проштовхувати кожну одиницю роботи крізь фабрику.

Конкуренція за весь цикл

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

Ознаки вже видно. Google працює над поведінковим оцінюванням і обв'язкою агентів. GitHub дозволяє рев'ю коду виконувати й перевіряти код. Atlassian поєднує керування беклогом, контекст, виконання агентами, стандарти, рев'ю й вимірювання в керовані цикли агентів. Продукти різні, але вказують в одну точку.

За межами промптів

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

Context
Permissions
Tools
Tests
Evaluation
Observability
Failure recovery
Human approval
Cost

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

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