Управляемые циклы агентов: как ИИ-агенты для кода уходят дальше промптов

Писать софт с помощью ИИ до сих пор странно похоже на ручную работу. Открываешь 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

Это классические инженерные темы. ИИ не отменил разработку софта; он расширил её поверхность. Разработчик завтрашнего дня, возможно, будет меньше набирать код реализации и больше времени тратить на проектирование системы, которая позволяет машинам безопасно его производить. Возможно, это и есть настоящее начало ИИ-нативного жизненного цикла софта.

Будущее программирования — не один более умный агент, ждущий следующего промпта. Это набор сотрудничающих агентов, которые видят открытые задачи, читают кодовую базу, соблюдают правила команды, проверяют собственный результат и в нужный момент зовут человека. Сделать этот цикл автономным — не самое сложное. Сложно сделать его заслуживающим доверия.