Пороги остановки пилота с ИИ-агентами

Пилотный проект с несколькими ИИ-агентами для программирования стоит остановить или перестроить, если взвешенная доля переделок держится выше 35% в течение двух последовательных периодов измерения после как минимум 20 подходящих задач. Это правило для принятия решения, а не универсальный закон. Недавние показатели работы без агентов определят, достаточно ли строг порог в 35%, а утечка данных, потеря информации или серьезный инцидент в продакшене могут остановить пилот немедленно.

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

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

Возьмите подходящие задачи за знаменатель и учитывайте только работу, которая попала в пилот по письменному описанию задачи. У подходящей задачи есть сформулированный результат, проверки приемки, репозиторий и среда в рамках работ, а также четкий момент, когда ревьюер может принять или отклонить результат. Если формулировка настолько расплывчата, что два инженера реализовали бы ее по-разному, пилот измеряет качество постановки задач.

Простейшая доля переделок выглядит так:

raw_rework_rate = tasks_requiring_material_rework / eligible_tasks

Существенная переделка означает, что человеку или агенту пришлось изменить поведение, архитектуру, тесты, защитные механизмы, обработку данных или конфигурацию развертывания до приемки. Исправление знака препинания в комментарии не считается. Замена выдуманного API, переписывание нерабочей миграции, добавление пропущенной проверки прав доступа или полный отказ от изменения считаются.

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

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

Присвойте каждой подходящей задаче одно итоговое состояние:

• Принята без существенной переделки
• Принята после существенной переделки
• Отклонена или брошена
• Отменена после слияния
• Связана с пропущенным дефектом

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

Принятые изменения выдерживают проверку ревью

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

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

Я использую только три допустимых значения эквивалента принятого изменения: 0, 0,5 и 1. Задача получает 1, когда обеспечивает весь заявленный результат, 0,5, когда в продукт попадает независимо полезная часть, а недостающая часть возвращается в бэклог, и 0, когда ревьюеры отбрасывают результат. Не разрешайте команде договариваться о значениях вроде 0,8 после просмотра недельного итога. Иначе измерение превратится в защиту пилота.

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

Учитывайте отклоненную работу, даже когда она не оформилась в пул-реквест. Запуски агентов, которые закончились в ветке, рабочем дереве или очереди оркестратора, все равно потратили бюджет инструментов и внимание оператора. Назначайте каждой подходящей задаче постоянный идентификатор до запуска первого агента, чтобы исчезнувшую работу было видно в журнале решений.

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

В еженедельном отчете должно быть такое отношение:

accepted_yield = accepted_change_equivalents / eligible_tasks

Если доля принятого результата ниже 65%, система уже вышла за предлагаемый порог переделок в 35% еще до учета более тяжелых последствий. Пилот с 90% итоговой приемки все равно может быть плохим при 25% приемки с первой попытки, потому что основную инженерную работу выполняют ревьюеры и агенты-исправители.

Минуты ревью показывают скрытый перенос работы

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

Не оценивайте трудозатраты ревью по числу комментариев. Пятиминутная проверка может оставить восемь точных замечаний. Девяностоминутное расследование может завершиться одной фразой: «Эта миграция теряет строки при откате». Используйте таймер или восстановите время по календарному блоку в тот же день. Точности до пяти минут достаточно, а ложная точность породит споры и не улучшит решение.

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

Преобразуйте трудозатраты на ревью в штраф:

review_penalty = max(0, pilot_review_minutes - baseline_review_minutes)
                 / baseline_total_task_minutes

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

Допустим, обычное изменение API занимает у человека 150 минут реализации и 30 минут ревью. Пилот выдает результат, на проверку которого уходит 65 минут. Штраф за лишнее ревью равен (65 - 30) / 180, то есть 19,4% эквивалента задачи. Агент все еще может оказаться выгодным при низкой цене инструментов и принятом изменении. Но он не сэкономил все 150 минут реализации, поскольку переложил 35 дополнительных минут на более дефицитного инженера.

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

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

Разделяйте минуты оператора и ревьюера, даже если обе роли выполняет один человек. Работа оператора включает подготовку запросов, распределение задач, разрешение конфликтов между агентами, перезапуск сред и сборку ветки, пригодной для проверки. Ревью начинается лишь тогда, когда ветка и запись о задаче готовы к решению о приемке. Такая граница не дает труду по оркестрации раствориться в строке «сэкономлено на реализации». В небольшом пилоте попросите человека переключать категорию таймера при смене работы. Первую неделю это покажется излишней педантичностью, затем цифры объяснят, где скрыта дорогая часть: в управлении агентами или в оценке их результата.

Откаты и пропущенные дефекты должны весить больше

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

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

Используйте веса серьезности, а не считайте все последствия одинаковыми:

• Существенная переделка до слияния: 1,0 эквивалента задачи
• Отклоненная или брошенная задача: 1,0
• Вызванный пилотом откат: 2,0
• Пропущенный дефект с ограниченным внутренним влиянием: 2,0
• Заметный пользователям или связанный с безопасностью дефект: 4,0

Эти веса отражают управленческое решение: ошибка после приемки обходится дороже исправления во время ревью. Веса можно изменить, но зафиксируйте их до первой измеряемой задачи. Если продукт работает с деньгами, здоровьем, личностью или необратимыми пользовательскими данными, повысьте вес заметного пользователям дефекта, а некоторые категории превратите в немедленную остановку.

Взвешенную долю переделок считайте так:

weighted_rework_rate =
  (rework_tasks + rejected_tasks
   + 2 * pilot_reverts
   + 2 * internal_escaped_defects
   + 4 * serious_escaped_defects
   + excess_review_task_equivalents)
  / eligible_tasks

Показатель может превышать 100%, и это сделано намеренно. Задача могла потребовать исправлений, попасть в основную ветку, вызвать дефект и привести к откату. Она создала несколько уровней повторной работы. Ограничение на уровне 100% стерло бы разницу между просто отклоненным изменением и дорогим эксплуатационным сбоем.

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

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

Расходы на инструменты входят в цену принятого изменения

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

Полезный экономический показатель выглядит как полная стоимость одного эквивалента принятого изменения:

pilot_cost_per_accepted_change =
  (tool_spend
   + operator_minutes * operator_rate
   + reviewer_minutes * reviewer_rate
   + repair_minutes * repair_rate
   + incident_cost)
  / accepted_change_equivalents

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

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

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

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

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

Порог остановки устанавливают до запуска пилота

Запишите устав пилота с одним главным правилом остановки, экономическими ограничениями, немедленными остановками по безопасности и минимальной выборкой. Для обычного веб-продукта я начинаю с такого правила: приостановить и перестроить пилот, когда взвешенная доля переделок превышает 35% в двух последовательных недельных периодах, пилот завершил не меньше 20 подходящих задач, а каждый период содержит хотя бы 10. Немедленно останавливайте текущую схему, если полная стоимость принятого изменения превышает базовый показатель в 1,25 раза в двух периодах или сработало утвержденное условие немедленной остановки.

Почему 35%? Ниже этой границы пилот еще способен окупить исправления за счет сэкономленного времени реализации, особенно для ограниченных задач. Выше нее исправления съедают больше одного эквивалента задачи из трех еще до учета цены инструментов. Число намеренно строгое, потому что системы с несколькими агентами способны ускорить выпуск плохой работы до того, как команда заметит проблему.

Не копируйте 35% без базового показателя. Если сопоставимый процесс без агентов уже дает 28% взвешенных переделок, требование 10% от пилота может отвергнуть полезную автоматизацию. Если обычный процесс работает на уровне 8%, бездумно принять 34% из-за формального прохождения общего порога было бы опасно. Используйте такое правило:

pilot_stop_threshold =
  min(35%, baseline_weighted_rework_rate + 10 percentage points)

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

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

При малой выборке принимайте решения по количеству событий, а не по красивым процентам. В восьми задачах один откат меняет сырую долю на 12,5 пункта еще до взвешивания. Наблюдайте за пилотом до минимальной выборки, если не сработало условие немедленной остановки. Если команда не находит 20 сопоставимых задач, сценарий может быть слишком редким для количественного пилота. Тогда используйте анализ рисков и разбор отдельных случаев, а не изображайте стабильность показателя.

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

Журнал решений не оставляет места поздним оправданиям

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

Этого заголовка CSV достаточно для принятия решения:

task_id,task_class,risk,eligible,baseline_minutes,accepted_equivalent,material_rework,rejected,review_minutes,baseline_review_minutes,revert,escaped_internal,escaped_serious,tool_cost,operator_minutes,repair_minutes,window,notes

Добавляйте в примечания код причины для каждого нуля, частичной приемки, отката или дефекта. Пишите факты: «Использован удаленный API биллинга, ревьюер заменил интеграцию» дает полезную информацию. «Агент запутался» ничего не объясняет. Первая запись описывает сбой, который можно предотвратить контекстом репозитория или правильным распределением задач.

Проводите еженедельную проверку в таком порядке:

1. Закройте период и сверьте каждый идентификатор подходящей задачи.
2. Подтвердите приемку и связь последствий с ревьюером или владельцем инцидента.
3. Рассчитайте взвешенную долю переделок, долю принятого результата, процентили ревью и стоимость принятого изменения.
4. Сравните результат с сопоставимой базой и двумя предыдущими периодами.
5. Запишите решение продолжить, ограничить, перестроить, приостановить или остановить, а также ответственного за действие.

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

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

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

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

Разобранный пример отделяет ремонт от отмены

Рассмотрим четырехнедельный пилот с 24 подходящими задачами. Агенты выдали 18 эквивалентов принятых изменений. Шесть задач потребовали существенной переделки, причем две из них ревьюеры в итоге отклонили. Одна принятая задача привела к откату. Другая задача создала внутренний пропущенный дефект. Ревьюеры потратили 910 минут при сопоставимой базе в 620 минут, а базовые общие трудозатраты на все 24 задачи равны 5800 минутам.

Не считайте две отклоненные задачи дважды как переделку и отклонение, если журнал хранит отклонение как их итоговое состояние. Взвешенный числитель содержит шесть эквивалентов для исправленных или отклоненных задач, два для отката, два для внутреннего дефекта, плюс (910 - 620) / 5,800, или 0,05, за лишнее ревью. Взвешенная доля переделок равна 10.05 / 24, или 41,9%.

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

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

Экономика может изменить любое решение. Пусть полная стоимость 18 принятых эквивалентов составила 7200 долларов, или 400 долларов за каждый, а сопоставимые человеческие изменения стоят 360 долларов. Пилот дает 1,11 базовой стоимости: выше предупреждающей границы, но ниже порога остановки 1,25. Вместе с 41,9% взвешенных переделок такой результат требует перестройки. Если бы стоимость равнялась 500 долларам за изменение, отношение 1,39 независимо остановило бы схему после необходимого второго периода.

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

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

Сначала остановите схему, а не всех агентов

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

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

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

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

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

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