Первый управляемый цикл

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

Начните с результата #

Подходящий первый процесс отвечает шести условиям.

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

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

Паспорт цикла #

До технической работы владелец заполняет паспорт.

Паспорт остаётся коротким. Подробные правила, наборы проверок и реестр данных хранятся отдельными версионируемыми артефактами.

Зафиксируйте исходный уровень #

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

Минимальный набор:

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

Исследование METR показало, что опытные разработчики в исследованной выборке с инструментами начала 2025 года работали медленнее, хотя ожидали ускорения.

Это не универсальный вывод о разработке. Это сильное напоминание измерять фактический эффект в своём классе задач. [METR-2025-experienced-developers]

DORA связывает результат применения ИИ с качеством инженерных и организационных возможностей.

Наблюдаемая связь не доказывает одинаковый причинный эффект для каждой компании, но поддерживает решение измерять весь процесс, а не скорость генерации. [DORA-2025-report] [DORA-2025-capabilities-model]

Разложите цикл по ролям #

Для каждого шага выберите один из четырёх исполнителей:

1. человек;
2. обычная программа;
3. ИИ без права действия;
4. ИИ с ограниченным правом действия.

Пример для обработки заявки:

Такое разложение обычно уменьшает область ИИ. Это полезный результат: меньше прав, контекста и вариантов поведения проще проверять.

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

Не назначайте один уровень всему агенту.

Для первого цикла A0 означает анализ без права действия, а A1 — подготовку изменения, которое отдельно применяет человек. A2 допускает только ограниченное обратимое действие. A3 относится к узкому циклу с защищёнными переходами.

Канонические определения и полный набор условий находятся в главе 8. Для первого пилота исходно выбирайте A0 или A1. Переход к A2 или A3 требует отдельного договора о самостоятельности и доказательств именно для этого действия.

Спроектируйте проверку до пилота #

Проверка должна отвечать на два вопроса.

1. Получился ли допустимый результат?
2. Был ли путь к нему допустимым?

Удачный ответ может скрывать обращение к запрещённому источнику, пропущенное согласование или лишнюю запись данных. Поэтому отдельно проверяйте итог и допустимость пути. [G1-D1-p22], The New SDLC With Vibe Coding_Day_1.pdf, с. 22.

В план входят:

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

Тесты, созданные той же системой, полезны, но не служат единственным доказательством для существенного риска. [G1-D5-p29], Day_5_v3.pdf, с. 29.

Проведите ограниченный пилот #

Пилот начинается на исторических данных или в режиме наблюдения. Затем ИИ помогает реальным пользователям без права необратимого действия. Только после серии проверок команда может расширить область.

У пилота заранее определены:

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

Один красивый прогон не считается серией. Для вероятностной системы нужна повторяемая проверка, включая редкие сценарии. [G1-D3-p27], Agent Skills_Day_3.pdf, с. 27.

Завершите пилот решением #

Возможны четыре честных исхода.

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

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

Оставить на текущем уровне. A0 или A1 дают большую часть пользы без риска самостоятельного действия.

Остановить. Эффект не подтверждён, проверка слишком дорога или ущерб нельзя ограничить.

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

Условный заполненный пример #

Процесс: подготовка ответа на типовой вопрос клиента.

Результат: оператор отправил точный ответ, соответствующий действующим правилам.

Сигнал: новое обращение в очереди поддержки.

Решение: определить тему, найти действующую статью и выбрать допустимый ответ.

Действие ИИ: сформировать черновик и ссылки на источники. Уровень A1.

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

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

Резерв: оператор отвечает по прежнему процессу.

Решение после пилота: сохранить A1, потому что отправка редких и чувствительных ответов требует человеческого решения. Зрелость процесса можно повышать через качество контекста и проверок без перехода на A2.

Рабочая карточка главы #