Коротко. AI-агент может открыть технически корректный pull request (PR) и всё равно решить не ту задачу: выбрать устаревшее правило, затронуть лишний сервис или обойти известное ограничение. Команде нужен короткий контракт, который до запуска фиксирует цель, границы, доказательства результата, момент остановки и владельца решения.

Контракт работает вместе с техническими ограничениями: отдельными доступами, изолированной средой, обязательными проверками и review. Для изменения поведения этого недостаточно: до кода команда ещё согласует сценарий, который будущий тест обязан подтвердить. В статье — копируемый шаблон, сквозной пример и способ встроить эту практику в Git и CI.

Проблема: агенту передали работу без общего решения

AI-агент открыл PR. Тесты прошли. Через десять минут команда видит, что изменения сделаны в другом сервисе, правило уже устарело, а ограничение существовало только в разговоре двух человек.

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

Практическое решение: контракт делегирования

Контракт делегирования — короткий рабочий документ для задач, которые выполняет AI-агент: от черновика и поиска по коду до изменений в изолированной среде. Он фиксирует цель, источники истины, разрешённые действия, стоп-условия, доказательства готовности и владельца решения.

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

Сквозной пример: повторный запрос не должен создавать второй заказ

Ниже будем вести одну иллюстративную задачу. Это не кейс с заявленным эффектом, а безопасный сценарий для первого пилота.

Дано

Платёжный сервис принимает запрос на создание заказа. Клиент может потерять сеть и повторить запрос. Система должна вернуть уже созданный заказ, не создавая второй. В репозитории есть общая архитектурная договорённость об идемпотентности, тест на этот сценарий устарел после изменения обработчика.

Команда ставит задачу: «обновить интеграционный тест повторного запроса». AI-агент получает доступ только к модулю заказов и тестам, создаёт ветку, запускает интеграционные тесты и открывает PR. Схема базы данных, публичный API, правила расчёта и настройки на продакшене остаются без изменений. Если тест показывает расхождение между спецификацией и кодом, агент останавливается и передаёт результат техническому владельцу сервиса.

Такой маршрут совпадает с тем, как GitHub описывает работу coding agent: агент выполняет задачу в ветке и готовит PR, команда проверяет изменения, возвращает их на доработку или принимает решение о слиянии. В статье этот пример будет проходить через все поля контракта.

Сначала выберите поток с понятной ценой ошибки

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

Для первого опыта не берите сложный релиз, платёж, изменение прав доступа или удаление данных. В таких задачах нужны минимальные права, изолированная среда, обязательные подтверждения, журнал действий и аварийная остановка.

Leadership in Tech в материале Before you delegate предлагает начать с шести вопросов: что исполнитель уже знает, зачем нужна работа, какие ресурсы доступны, как выглядит хороший результат, к какому сроку он нужен и какие риски ожидаются. Для агента эти вопросы полезнее длинного промпта: они остаются рядом с задачей после первого запуска.

Контракт делегирования — копируйте в задачу

Вставьте этот блок в карточку задачи, README для агентского сценария или файл рядом с кодом. Для повторяемой работы удобнее хранить контракт конкретной задачи рядом с кодом, например в .agent/contracts/ORD-184.json: он получает версию, попадает в pull request и остаётся доступен при эскалации. Главное — чтобы актуальная версия была доступна до запуска и во время эскалации.

Стартовый набор для Git содержит машиночитаемый пример контракта, короткий AGENTS.md и проверку для GitHub Actions. Его можно скопировать в свой репозиторий и адаптировать под правила команды.

**Задача / ссылка:**
**Версия контракта / дата:**
**Агент и среда:**
**Владелец приёмки:**
**Уровень самостоятельности:** подготовить / изменить в изолированной среде / действие с последствиями

### Результат
- Пользовательский или операционный результат:
- Готово, когда:
- Вне задачи:

### Контекст
- Источники истины в порядке приоритета:
  1.
  2.
  3.
- Разрешённые репозитории, данные, инструменты и окружения:

### Границы действий
- Агент может:
- Агенту запрещено:
- Стоп-условия:

### Проверка и решение
- Обязательные доказательства:
- Кто принимает результат:
- Что требует отдельного подтверждения:

### Эскалация и пересмотр
- Кому передать контекст, канал и срок ответа:
- Резервный владелец:
- Пакет эскалации: резюме, ветка или список изменений, проверки, причина остановки, варианты и вопрос:
- Дата или условие пересмотра:

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

Для маленькой команды один человек может совмещать несколько ролей. В контракте всё равно стоит назвать их отдельно: кто владеет продуктовым или техническим решением, кто принимает результат, кто отвечает на эскалацию, кто подтверждает действие с последствиями.

До кода согласуйте, что обязан доказать тест

Контракт отвечает на вопрос: кто может действовать, в какой среде и где должен остановиться. Для изменения бизнес-правила, API, интеграции или пользовательского пути нужен ещё один короткий шаг: человек подтверждает требование и сценарий приёмки до реализации. После работы ревьюер видит путь сценарий → тест → результат CI и проверяет, что агент не поменял смысл критерия по ходу работы.

Для задач с низким риском достаточно обычного теста и ревью. Для заметных изменений этот путь делает один важный вопрос явным: «Если сценарий пройдёт, мы действительно готовы считать результат достигнутым?» Продолжение разбирает этот слой: простую карту приёмки, два human gate и связь с OpenSpec без дублирования требований.

Сделайте контракт частью запуска и проверки

Файл в Git делает правило видимым и переиспользуемым. Сам файл не мешает агенту его забыть. Для надёжной работы контракт должен участвовать в запуске, ограничениях и проверке результата.

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

.agent/
  AGENTS.md                     # короткая постоянная инструкция
  policies/baseline.md          # общие правила для всех запусков
  contracts/ORD-184.json        # контракт конкретной задачи
  acceptance/ORD-184.yml        # сценарий приёмки и связь с проверкой
.github/workflows/
  contract-guard.yml            # проверка контракта в pull request

AGENTS.md хранит только постоянный маршрут: где лежит контракт, в каких случаях остановиться, как оформить эскалацию. История старых задач туда не попадает. Перед запуском агент получает путь к одному актуальному контракту; это сохраняет контекст коротким.

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

Во время работы. Агент получает доступ только к нужной ветке, тестовому контуру и разрешённым инструментам. Правило «не менять продакшен» должно быть закреплено отдельными учётными данными, защитой окружения и правами ветки. Текст контракта сам по себе не отзовёт уже выданные права.

В pull request. Описание PR ссылается на точный файл контракта. CI сверяет изменённые пути с allow_paths и deny_paths, проверяет наличие контракта и делает PR красным при выходе за границы. Для утверждённого сценария reviewer видит связанный test и результат его запуска. Отдельно остаются обязательные тесты и review владельца.

После запуска. В контракт или журнал исключений попадают эскалации, возвраты и непредусмотренные действия. Повторяющееся исключение означает, что команде нужен новый пункт шаблона, автоматическая проверка или более узкие доступы.

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

Как заполнить шаблон

1. Результат и границы задачи

Зачем: какой результат для пользователя или для работы команды должна дать задача.

Готово, когда: наблюдаемое условие приёмки. Например: «клиент получает корректный статус заказа при повторном запросе; интеграционные тесты проходят».

Вне задачи: что сознательно не меняем. Например: схему авторизации, расчёт цены и внешний API.

Так команда защищается от ситуации, когда агент точно выполняет узко поставленную задачу, пока продуктовый смысл остаётся за пределами его контекста.

2. Контекст и источники истины

Перечислите документы, репозитории, данные и правила, которыми агент может пользоваться. Укажите, чему доверять при противоречиях. Порядок зависит от типа задачи: тесты могут фиксировать устаревшее поведение, исходный код может содержать дефект. В одном сценарии приоритетом станет текущая спецификация, затем архитектурное решение и тесты; в другом — подтверждённый инцидент и рабочее поведение системы.

Если приоритетный источник недоступен или противоречие не удаётся снять, это стоп-условие. Агент не выбирает версию на своё усмотрение.

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

3. Разрешённые действия и стоп-условия

Здесь нужны проверяемые формулировки. «Действуй разумно» не задаёт границу.

Агент может: читать указанные репозитории; искать документацию; создать ветку; менять файлы в названном модуле; запускать заданные тесты; подготовить PR.

Агент обязан остановиться: если для работы нужны персональные данные; если требуется изменить публичный контракт; при новом падении обязательных тестов, которое нельзя объяснить или локализовать; при необходимости новых прав; при конфликте между спецификацией и кодом; если утверждённый сценарий нужно изменить.

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

Выберите для каждого запуска один максимальный уровень самостоятельности:

  • Подготовить. Поиск, анализ, черновик документа, набор тестов. Человек использует результат как материал.
  • Изменить в изолированной среде. Ветка, тестовый контур, PR, настройка в изолированной среде. Результат проверяют автоматическая система и человек.
  • Действовать с последствиями. Продакшен, права, деньги, внешняя коммуникация, удаление данных. Для таких действий в контракте укажите, кто принимает решение, кто подтверждает действие и как его остановить.

Мера самостоятельности зависит от того, можно ли быстро исправить последствия. Свежий v1-препринт Engineering Reliable Coding Agents собирает практики и исследования о надёжности coding agents. Автор прямо отмечает, что сила доказательств различается по темам и зависит от конфигурации системы. Для команды из этого следует практическое правило: важные ограничения и проверки нужно фиксировать в рабочем процессе, доступах и автоматических контролях.

4. Доказательства готовности

Без доказательств отметка «готово» быстро приводит к спору на ревью. В контракте заранее назовите подходящее подтверждение:

  • какие тесты были запущены и их результат;
  • ссылка на PR и перечень затронутых модулей;
  • сравнение поведения до и после изменения;
  • лог или снимок экрана для пользовательского сценария;
  • список допущений и вопросов, которые агент не смог проверить.

Зелёный test подтверждает, что текущий код проходит конкретную проверку. Для изменения поведения добавьте ещё один вопрос: какой утверждённый сценарий этот test подтверждает? Ссылка scenario → test → CI позволяет ревьюеру увидеть ответ, не доверяя пересказу агента.

Объём доказательств зависит от риска. Черновику документа достаточно ссылок на источники и списка открытых вопросов. Для изменения расчёта комиссии нужны тесты, независимая проверка и явное решение владельца продукта.

5. Эскалация и владелец решения

Укажите условие остановки, кому передать контекст, срок реакции и резервного владельца. Формулировка «при проблеме спроси команду» оставляет вопрос без ответственного.

Хорошая запись выглядит так: «При изменении публичного API агент прекращает работу, прикладывает список изменений и варианты совместимости; решение принимает технический владелец сервиса в течение рабочего дня. При отсутствии ответа задача остаётся остановленной».

Исследование о проверяемых правилах работы AI-агентов разбирает один прикладной кейс. Его результаты нельзя без оговорок переносить на любую команду. Кейс показывает, зачем нужны постоянные проверяемые правила: они помогают эскалировать вопросы и восстанавливать историю решений.

6. Срок пересмотра

Контракт действует, пока не изменились существенные условия: модель получила новые инструменты, изменились данные или доступы, случился инцидент, повторилась одна и та же эскалация.

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

Как контракт работает на этом примере

Вернёмся к задаче про повторный запрос заказа. Ниже — заполненный контракт для неё.

Задача: обновить интеграционный тест повторного запроса заказа.

Версия: 1.0, 24 августа 2026. Агент и среда: coding-агент в тестовом контуре. Владелец приёмки: технический владелец сервиса заказов. Владелец смысла сценария: product/domain owner.

Готово, когда: утверждённый сценарий повторного запроса проходит: API возвращает исходный заказ, второй заказ и второе списание не появляются; существующие интеграционные тесты проходят.

Вне задачи: изменение схемы базы данных, логики расчёта цены, публичного API.

Источники истины: текущая спецификация API → архитектурное решение об идемпотентности → существующие интеграционные тесты.

Агент может: читать модуль заказов и тесты, создать ветку, добавить тест, запустить набор интеграционных тестов, открыть PR.

Стоп-условия: спецификация и код дают разные ответы; для теста требуются реальные персональные данные; падает связанный тест, причину которого нельзя локализовать; утверждённый сценарий нужно изменить.

Доказательства: ссылка на PR, вывод тестов, список затронутых файлов, путь от утверждённого сценария к интеграционному тесту и запуску CI.

Эскалация: технический владелец сервиса отвечает в рабочем канале до конца дня; до ответа агент не меняет реализацию. Пересмотр: после трёх запусков или первого повторяющегося стоп-условия.

Здесь агент действует на втором уровне: меняет только ветку и тестовый контур. Слияние PR остаётся решением владельца приёмки.

Проведите первый эксперимент за две недели

До первого запуска зафиксируйте обычный путь этого сценария: сколько занимает приёмка, где чаще возникают возвраты и какие решения обычно требуют уточнения. Цель пилота — увидеть пользу контракта в конкретном потоке и решить, стоит ли расширять практику.

Две недели, пять запусков и разбор трёх повторяющихся исключений — стартовая эвристика, а не отраслевой норматив. Команда калибрует эти числа по цене ошибки и реальному объёму работы.

  1. Дни 1–2. Выберите безопасный повторяемый сценарий, владельца приёмки, изолированную среду и заполните один контракт.
  2. День 3. Проведите пробный запуск и проверьте путь эскалации.
  3. Дни 4–10. Используйте контракт минимум в пяти запусках или во всех доступных запусках процесса за две недели.
  4. После каждого запуска. Запишите факт эскалации, возврат на доработку, непредусмотренное действие, время от запуска до приёмки.
  5. Дни 11–12. Разберите три самых частых исключения.
  6. Дни 13–14. Примите одно решение: расширить практику, сузить сценарий и доработать контракт или остановить пилот до появления технических контролей.

Пилот не стоит запускать без владельца приёмки, изолированной среды, способа отозвать доступ и понятного канала эскалации.

Оценивайте результат по наблюдаемым признакам: цель задачи стала понятнее; сюрпризов на приёмке меньше; обратимые решения принимаются быстрее; решения с высокой ценой ошибки видны до выполнения. Дополнительно посчитайте число запусков, долю эскалаций, возвраты после приёмки и медианное время до принятия результата.

Где практика ломается

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

Контракт также не делает сценарий приёмки качественным автоматически. Он задаёт владельца, источник истины и путь эскалации. Качество связи «требование → сценарий → test → evidence» требует отдельного review. Продолжение показывает минимальный способ устроить этот review без тяжёлой системы управления требованиями.

Не превращайте контракт в подробное техническое задание. Его задача — дать общий контекст и ясные границы, оставив исполнителю свободу внутри безопасной зоны.

Препринт об assurance в крупной агентной разработке предлагает собирать доказательства для значимых действий и учитывать непроверенные допущения, когда команда определяет степень самостоятельности агента. Это подход к устройству системы, не готовая инструкция. Пороги риска, набор проверок и роли владельцев команда калибрует на своих задачах.

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