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

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

Для оценки каждой задачи нужны три параметра:

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

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

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

Что значит «отдать задачу агенту»

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

Разделим работу на шесть действий:

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

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

Для остальных задач предусмотрены два режима:

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

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

Единица оценки: конкретная задача в конкретном проекте

Название категории слишком широкое. «Написать тесты» может означать три unit-теста для чистой функции с ясным контрактом или восстановление интеграционного покрытия после миграции нескольких модулей. «Сделать рефакторинг» может быть переименованием локального символа или переносом общей модели данных между сервисами.

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

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

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

Три параметра применимости

Каждый параметр получает уровень 1, 2 или 3. Числа позволяют хранить и анализировать данные по каждому параметру. Общий балл исказит оценку: высокая проверяемость не снижает цену ошибки, а ясное требование не создаёт независимый способ проверки.

1. Определённость результата

Определённость отвечает на вопрос: может ли команда до начала реализации описать, что должно измениться и что должно остаться прежним?

Уровень 1: низкая

Поставьте 1, если выполняется хотя бы одно условие:

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

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

Уровень 2: средняя

Поставьте 2, если основное поведение согласовано, но остаётся один или несколько ограниченных вопросов:

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

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

Уровень 3: высокая

Поставьте 3, только если выполнены все условия:

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

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

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

2. Проверяемость результата

Проверяемость отвечает на вопрос: сможет ли команда подтвердить результат независимо от объяснения агента?

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

Уровень 1: низкая

Поставьте 1, если присутствует хотя бы один признак:

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

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

Уровень 2: средняя

Поставьте 2, если основное поведение проверяется, но остаётся заметная зона ручного контроля:

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

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

Уровень 3: высокая

Поставьте 3, только если выполнены все условия:

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

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

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

3. Цена ошибки

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

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

Уровень 1: низкая

Поставьте 1, если все условия выполнены:

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

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

Уровень 2: средняя

Поставьте 2, если последствия ограничены, но потребуют заметного восстановления:

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

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

Уровень 3: высокая

Поставьте 3, если выполняется хотя бы одно условие:

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

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

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

Как выбрать режим без конфликтов в матрице

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

Приоритет	Условие	Режим работы
1	Цена ошибки = 3	Человек владеет решением и приёмкой. Агент выполняет ограниченные, заранее перечисленные шаги. Нужны независимое ревью и план безопасного выпуска
2	Проверяемость = 1	Сначала построить способ проверки. До этого агенту поручают исследование, воспроизведение и подготовку проверок
3	Определённость = 1	Работать короткими исследовательскими шагами. Человек подтверждает направление после каждого шага
4	Определённость = 2 или проверяемость = 2, цена ошибки = 1 или 2	Делегировать ограниченный этап с обязательной контрольной точкой и расширенным просмотром результата
5	Определённость = 3, проверяемость = 3, цена ошибки = 2	Работать совместно: агент выполняет ограниченный этап, человек подтверждает контрольные точки и принимает результат после независимой проверки
6	Определённость = 3, проверяемость = 3, цена ошибки = 1	Агент выполняет полный цикл до готового к приёмке результата. Человек просматривает подтверждения и итоговый diff

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

Матрица выбирает исходный режим для текущего состояния задачи. После исследования определённость может подняться с 1 до 2. Падающий тест и воспроизводимый запуск могут повысить проверяемость. Изоляция изменения и проверенный откат могут ограничить последствия.

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

Какие доказательства прикладывать к оценке

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

Для определённости подойдут:

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

Для проверяемости нужны исполняемые или наблюдаемые подтверждения:

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

Для цены ошибки записывают:

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

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

Где JetBrains IDE добавляет факты для приёмки

Проверяемость зависит от того, какие сведения агент получает о проекте. Текст файлов и вывод команды покрывают только часть картины. В Java- и Kotlin-проектах JetBrains IDE хранит структурную модель кода, связи символов, конфигурации запуска, результаты тестов, сообщения инспекций и состояние приложения во время отладки.

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

Факты из IDE усиливают проверку при заранее заданном ожидании. Успешная компиляция подтверждает выбранную область сборки, но ничего не говорит о продуктовом смысле изменения. Зелёный тест подтверждает только заложенный в него сценарий. Отладчик показывает состояние одного воспроизведённого запуска, поэтому регрессионный набор всё равно нужен.

Veai выполняет семантическое переименование через JetBrains IDE

Veai вызывает рефакторинг JetBrains IDE. Такой артефакт показывает выполненную операцию и затронутый символ; совместимость изменения подтверждают отдельные сборки и тесты.

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

В карточке нужно назвать каждое подтверждение и его границы. Отчёт «всё прошло» для приёмки слаб. Запись «конфигурация payment-service:testзавершилась успешно, выполнено 126 тестов, интеграционный набор не запускался» позволяет человеку понять, что проверено и что осталось.

Примеры оценки реальных задач

Обновить руководство по согласованным исходным материалам

Условия:

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

Оценка: определённость 3, проверяемость 3, цена ошибки 1. Агент может подготовить полный черновик и выполнить проверку ссылок. Человек сверяет факты, формулировки и принимает публикацию.

Если источники противоречат друг другу или позиционирование ещё обсуждается, определённость снижается до 1 или 2. Категория задачи та же, режим уже другой.

Добавить unit-тесты к чистой функции

Условия:

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

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

Если ожидаемое поведение выводится только из текущего кода, определённость не выше 2. Такие тесты могут закрепить дефект.

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

Условия:

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

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

Добавить повторные попытки во внешний вызов

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

Оценка: определённость 2, проверяемость 2, цена ошибки 2. Агенту можно поручить исследование и ограниченную реализацию. После анализа идемпотентности разработчик подтверждает направление. Перед выпуском команда проводит стендовую проверку и проверяет отключение по флагу.

Изменить расчёт платежа

Даже при формальном контракте цена ошибки равна 3. Срабатывает первое правило матрицы. Агент может найти затронутые места, подготовить тестовые данные и предложить патч. Профильный разработчик отвечает за решение, независимые тесты, ревью граничных случаев и выпуск.

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

Спроектировать разделение монолита

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

Оценка: 1, 1 или 2, 3. Агент подходит для построения карты зависимостей, поиска циклов, сбора обращений к данным и подготовки вариантов. Архитектурное решение принимает команда после исследования.

Как провести пилот на задачах команды

Пилот должен отвечать на два вопроса:

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

Расход токенов входит в расчёт стоимости. Цель команды состоит в сокращении активного времени разработчика при сохранении требуемого качества.

Шаг 1. Сформируйте представительную выборку

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

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

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

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

Шаг 2. Откалибруйте оценщиков и оцените карточки

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

Согласованность оценщиков =
  карточки с одинаковой оценкой
  / все карточки калибровочной выборки

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

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

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

Шаг 3. Зафиксируйте границы и критерий остановки

До запуска укажите:

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

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

Шаг 4. Сначала зафиксируйте невыполненный критерий

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

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

Окно Test Results показывает один упавший и 21 пройденный тест

Окно Test Results фиксирует имя конфигурации, число тестов, время запуска и различие между ожидаемым и фактическим результатом. Скриншот подтверждает один запуск; повторная проверка после исправления должна быть сохранена отдельно.

Шаг 5. Выполните задачи в назначенном режиме

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

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

Шаг 6. Измерьте полный цикл

Для каждой попытки фиксируйте:

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

Главный показатель времени:

Активное время разработчика =
  постановка
  + активное взаимодействие
  + проверка
  + ручные исправления
  + восстановление после дефектов

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

Шаг 7. Проведите приёмку без опоры на резюме агента

Результат принимают по сохранённым доказательствам:

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

Фраза агента «задача выполнена» не подтверждает результат.

Итог Auto Review в Veai с областью проверки и выводом ревью

Итог Auto Review хранит проверенную область и вывод по изменённому коду. Отчёт дополняет результаты тестов, инспекций и просмотр diff, перечисленные в критериях приёмки.

Шаг 8. Сравните с базовой линией внутри категории

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

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

Шаг 9. Разберите ошибки прогноза

Есть два полезных типа ошибки:

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

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

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

Как посчитать долю задач

Одного процента недостаточно. Полезно считать четыре показателя.

1. Прогнозная доля самостоятельного делегирования

Прогнозная доля =
  задачи, попавшие в правило 6 матрицы
  / все оценённые задачи

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

2. Подтверждённая доля

Подтверждённая доля =
  принятые задачи из самостоятельного режима,
  где активное время разработчика ниже базовой линии
  и нет дисквалифицирующего дефекта
  / все задачи пилота

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

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

3. Доля задач для совместной работы

Доля совместной работы =
  принятые задачи из правил 3, 4 и 5,
  где активное время ниже сопоставимой базовой линии,
  нет существенной переделки
  и нет дисквалифицирующего дефекта
  / все задачи пилота

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

4. Доля с учётом трудоёмкости

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

Взвешенная подтверждённая доля =
  сумма базового человеческого времени подтверждённых задач
  / сумма базового человеческого времени всех задач выборки

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

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

Метрики, которые стоит оставить на дашборде

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

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

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

Карточка оценки задачи

Задача:
Категория:
Модуль или система:
Ожидаемый результат:
Что должно остаться без изменений:

ОПРЕДЕЛЁННОСТЬ: 1 / 2 / 3
Основание оценки:
Неизвестные вопросы:
Кто принимает продуктовые и технические решения:

ПРОВЕРЯЕМОСТЬ: 1 / 2 / 3
Как показать невыполненный критерий до изменения:
Независимый критерий приёмки:
Какие сборки, тесты, инспекции и запуски доступны:
Какое поведение проверяется во время выполнения:
Что останется непроверенным:

ЦЕНА ОШИБКИ: 1 / 2 / 3
Кого и что затронет дефект:
Можно ли остановить распространение:
Способ и время отката:
Что не восстановится после отката:

РЕЖИМ ПО МАТРИЦЕ:
[ ] Самостоятельное выполнение агентом
[ ] Совместная работа короткими шагами
[ ] Подготовительная помощь

Разрешённые файлы, модули и действия:
Запрещённые действия и среды:
Условие остановки:
Контрольная точка:
Кто принимает результат:

ПОСЛЕ ВЫПОЛНЕНИЯ
Активное время разработчика:
Автономное машинное время:
Время проверки:
Ручные исправления:
Повторные попытки:
Принятая доля патча:
Выполненные проверки:
Пропущенные проверки:
Дефекты после принятия:
Стоимость модели:
Нагрузка проверяющего, 1-5:
Итог: принято / принято после переделки / отклонено

Ограничения метода

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

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

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

Точность исторического времени зависит от способа учёта. Если базовая линия собрана по субъективным оценкам, вывод об экономии помечают как предварительный. Ручной и агентный процесс лучше измерять одинаковым способом.

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

Вывод

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

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

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

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

Разработчики в вашей компании уже тратят много токенов. Как проверить реальную пользу ИИ для бизнеса?