В прошлой статье мы разбирали, как сделать работу ИИ-агента предсказуемее: зафиксировать требования в спецификации с помощью Specification-Driven Development (SDD), до реализации описать ожидаемое поведение тестами по Test-Driven Development (TDD), а готовый результат проверить и передать отдельному субагенту на ревью.
У такого подхода есть цена.
Подготовка спецификации, написание тестов до кода и отдельное ревью требуют времени разработчиков. Возникают два вопроса: сколько контроля нужно конкретной задаче и когда затраты на него окупаются?
Полагаться только на свои ощущения в таких вопросах очень опрометчиво. В одном из экспериментов разработчики считали, что ИИ ускорил их примерно на 20%. Замеры показали обратное: с ИИ они работали на 19% медленнее.
В статье считаем полную стоимость работы с ИИ-агентом: разбираем, что уже измерено, сколько времени человек тратит на проверку и почему разным задачам нужен разный уровень контроля.
Что показывают эксперименты, если читать их целиком
Заголовки об ИИ в разработке противоречат друг другу: «на 55% быстрее», «на 19% медленнее», «на 26% продуктивнее». Результаты расходятся, потому что исследования проводились в разных условиях и измеряли разные показатели.
Для сравнения я выбрал работы с доступными первоисточниками, описанной методологией и измеримыми результатами. Исследование пул-реквестов стоит отдельно от контролируемых экспериментов: оно показывает, как агенты используются на практике, но не позволяет установить причины полученных результатов.
P.S статья написана мной разработчиком агента Михаилом Костицыным
Copilot заметно ускорил выполнение одной изолированной задачи. В эксперименте Google точечная оценка тоже была положительной, но доверительный интервал включал отсутствие эффекта. Demirer и коллеги зафиксировали рост числа завершённых задач в трёх компаниях.
METR получил противоположный результат: опытные разработчики выполняли задачи на знакомых зрелых проектах медленнее. Исследование измеряло общее время работы, поэтому по нему нельзя определить, сколько времени участники потратили на составление запросов к модели, ожидание ответа, чтение сгенерированного кода и исправления.
Есть и косвенные данные о качестве. В эксперименте Стэнфорда участники с ИИ-ассистентом писали менее безопасный код, но были увереннее в его безопасности. У этого результата есть ограничения: исследование проводилось на лабораторных задачах и моделях 2022 года.
В отчёте DORA 2024 рост использования ИИ на 25% был связан с расчётным снижением стабильности поставки ПО на 7,2% и пропускной способности поставки на 1,5%. Эти оценки получены по данным опроса и показывают статистическую связь, но не доказывают, что изменения вызваны применением ИИ.
Вывод из этих работ довольно узкий. В некоторых условиях ИИ ускорял разработчиков, в других замедлял. Результат зависел от задачи, проекта, опыта участников и способа применения инструмента. Имеющиеся исследования не позволяют определить, какой фактор влияет сильнее.
Большинство работ измеряет скорость выполнения задачи или количество закрытых задач. Полную стоимость работы с ИИ они не считают.
Скорость одной задачи не показывает полную экономику
Фраза «ИИ повышает продуктивность» может означать несколько разных вещей.
Первый вопрос: быстрее ли разработчик выполняет отдельную задачу? Это измеряли эксперименты Copilot и Google.
Второй: закрывает ли команда больше задач за тот же период? На него отвечали Demirer и коллеги.
Третий: как меняется качество кода, количество дефектов, частота инцидентов и сопровождаемость? По этим показателям пока есть только косвенные данные.
Четвёртый: окупается ли ИИ после учёта проверки, доработки и последствий пропущенных ошибок? Надёжного ответа на этот вопрос пока нет.
Замедление участников METR на 19% также не означает, что ИИ бесполезен. Эксперимент показал, что задачи с доступом к ИИ заняли больше времени. На каком этапе появились дополнительные затраты, исследователи не установили.
Поэтому для оценки ИИ недостаточно измерять скорость генерации или время выполнения одной задачи. Нужна полная стоимость.
Формула полной стоимости
Для конкретной задачи стоимость работы с агентом можно представить так:
Полная стоимость = подготовка + работа модели + проверка и переделки + внедрение + организационный контроль + ожидаемый ущерб
Подготовка включает постановку задачи и составление спецификации. Работа модели состоит из вызовов и генерации. Проверка и переделки охватывают чтение результата, ревью и исправления. Во внедрение входят интеграция, доставка и выкатка.
Организационный контроль включает проверки информационной безопасности и соответствия требованиям, аудит изменений, лицензирование, вопросы интеллектуальной собственности и защиту данных, которые передаются модели.
Ожидаемый ущерб учитывает дефекты, прошедшие через все проверки.
Агент окупается, если эта сумма меньше стоимости выполнения той же задачи вручную при сопоставимом уровне риска.
Условие о риске нельзя опускать. Команда может сэкономить 15 часов разработки, но при этом повысить вероятность инцидента в платёжной системе. Даже один такой инцидент способен стоить дороже, чем все часы, сэкономленные за год.
Для редких катастрофических сценариев, например утечки данных или необратимого повреждения производственной базы, ожидаемого ущерба в формуле недостаточно. Такие риски лучше ограничивать отдельным порогом или прямым запретом. Усреднять их вместе с рутинными дефектами нельзя.
У этой модели есть неприятная особенность. Генерация дешевеет с каждым поколением моделей, а чтение кода, проверка требований и ревью по-прежнему требуют человеческого времени. Чем больше изменений производит агент, тем выше может быть нагрузка на проверяющих.
Наблюдательное исследование агентских пул-реквестов подтверждает, что сгенерированные изменения доходят до слияния. Однако история коммитов не показывает, сколько времени люди потратили на доработку и приёмку.
Экономика агента во многом зависит от ответа на один вопрос: сколько стоит убедиться, что результат соответствует требованиям.
Два параметра: стоимость проверки и последствия ошибки
Уровень контроля можно выбирать по двум параметрам:
-
Сколько стоит независимая проверка результата.
-
Какой ущерб причинит пропущенная ошибка.
В теории тестирования существует проблема оракула: иногда получить надёжный ответ о корректности программы трудно или дорого. Для одной задачи достаточно компилятора и тестов. Для другой эксперту приходится вручную восстанавливать требования, читать код и проверять пограничные случаи.
Второй параметр отражает последствия ошибки: от дефекта в прототипе, который можно исправить за час, до потери денег или данных. В классических моделях управления рисками, в том числе у Боэма, риск зависит от вероятности события и размера ущерба. В нашей матрице вероятность не выделена отдельно, потому что она меняется вместе с качеством проверки. Чем надёжнее проверка, тем ниже вероятность того, что ошибка попадёт в рабочую среду.
Больше всего шансов окупиться у агентов в задачах с дешёвой проверкой и ограниченными последствиями ошибки. Генерация стоит недорого, а результат можно проверить по понятному критерию: код компилируется, тесты проходят, выходные данные совпадают с эталоном.
Но зелёный прогон тестов сам по себе ещё не доказывает корректность. Его ценность зависит от полноты и независимости тестов.
Если тесты написал тот же агент на основе той же трактовки требования, которую использовал при генерации кода, независимой проверки не получилось. Агент проверил собственное понимание задачи.
Более надёжные тесты должны приходить из другого источника. Их может написать разработчик на основе заранее утверждённой спецификации. Проверкой также могут служить эталонный набор данных или заранее определённые инварианты.
Если проверка полна, независима и обходится дешевле ручной реализации, происхождение кода становится менее существенным. Код мог написать человек, агент или генератор из спецификации. Доверие в этом случае опирается на проверку результата.
Если проверка неполна, нужно учитывать знание предметной области, ответственность автора изменения и независимое ревью. Ни человек, ни агент сами по себе не гарантируют правильного понимания требований.
У автономии есть два способа управления риском.
Первый состоит в том, чтобы сделать проверку надёжнее и дешевле.
Второй позволяет ограничить возможный ущерб с помощью песочницы, флага функции, постепенной выкатки на часть трафика и заранее проверенного отката.
Сколько контроля нужно для SDD и TDD
SDD, TDD, самопроверка и ревью субагентами требуют времени. Разработчики составляют спецификацию, читают тесты, проверяют результат и проводят дополнительные итерации ревью.
Проводить полный цикл для каждой задачи невыгодно. Если разовый скрипт легко проверить и его ошибка не приведёт к серьёзным последствиям, спецификация и два независимых ревью могут стоить дороже, чем ручное исправление результата.
Для логики начислений, управления доступом или миграции производственных данных ситуация обратная. Подробная спецификация, тесты и независимое ревью необходимы, но даже их может оказаться недостаточно.
Чем выше риск, тем глубже должен быть процесс проверки. Снизить затраты можно за счёт инструментов, которые ускоряют проверку и дают воспроизводимый результат.
Например, агент может запускать тесты через настроенные конфигурации JetBrains IDE, а не собирать команду запуска вручную в терминале. В таком случае используется та же конфигурация, что и у разработчика, а падение можно анализировать по конкретным результатам запуска.
Насколько это сократит время проверки, зависит от проекта, настроек, тестового раннера и качества тестов. Поэтому эффект нужно измерять во время пилота, а не заявлять заранее. То же относится к отдельному ревью со статическим анализом IDE.
Такой проход может находить часть ошибок и предупреждений, но не проверяет требования, архитектурные решения и риски предметной области.
До начала пилота нужно зафиксировать, какие IDE, конфигурации запуска, тестовые раннеры и виды анализа поддерживает используемая установка Veai. После этого можно измерить результат на выбранном классе задач.
Инструменты способны снизить стоимость проверки. Они не уменьшают последствия пропущенной ошибки и не снимают ответственность с команды.
Как провести проверку в своей компании
Ни одно из перечисленных исследований не проводилось на вашей кодовой базе и с вашим потоком задач. Проверить экономику агента можно только на собственных данных.
Опроса «стало ли быстрее?» для этого недостаточно. В эксперименте METR разработчики считали, что ускорились примерно на 20%, хотя замеры показали замедление на 19%. Расхождение составило около 39 процентных пунктов.
Сначала распределите входящие задачи по классам риска, а затем случайно назначайте режим работы.
Не стоит сразу строить сетку из четырёх классов задач и четырёх режимов. Для неё потребуется выборка, которой у большинства команд нет. Практичный старт включает два или три класса задач и два режима, например «без агента» и «агент с отдельным ревью».
Случайное назначение необходимо. Если разработчики сами решают, когда использовать агента, эксперимент измерит одновременно эффект инструмента, личные предпочтения участников и особенности выбранных ими задач.
Для начала достаточно семи метрик:
Продолжительность эксперимента зависит от потока задач. Несколько десятков наблюдений в каждой группе помогут увидеть крупный предварительный сигнал, но не сделают вывод статистически надёжным.
До старта нужно определить:
Тогда эксперимент ответит на прикладной вопрос: на каких классах задач агент окупается в вашей компании.
Команда, которая работает в JetBrains IDE и оценивает Veai, может начать с одного класса задач, для которого есть измеримая и недорогая проверка. Заранее зафиксируйте метрики, случайно распределите задачи между двумя режимами и измерьте базовую стоимость проверки.
Обещать экономию до такого измерения рано.
Чего мы пока не знаем
Надёжных причинных оценок долгосрочных эффектов почти нет. Мы не знаем, как массовое внедрение агентов повлияет на сопровождаемость кода через год, нагрузку на ревьюеров, компетенции команды и частоту производственных инцидентов.
Контролируемые эксперименты в основном измеряют краткосрочные показатели: время выполнения задачи и число закрытых задач. Данные о длительном периоде чаще поступают из наблюдательных исследований и опросов. Установить причинную связь по ним нельзя.
Матрица из этой статьи не претендует на универсальную модель. Она помогает принимать решения при нехватке данных: агенту можно дать больше самостоятельности, когда результат легко проверить, а последствия ошибки ограничены. Для задач с дорогой проверкой или тяжёлыми последствиями нужен более строгий процесс.
Границы между классами будут меняться вместе с моделями, инструментами проверки и новыми данными. Понять, для каких задач и насколько они изменятся, помогут только долгосрочные исследования.
Если вы уже проводили похожий пилот с рандомизацией или хотя бы с точными замерами времени, расскажите в комментариях о результатах. Таких данных пока не хватает и исследователям, и командам, которые решают, сколько самостоятельности можно дать агенту.
ссылка на оригинал статьи https://habr.com/ru/articles/1062428/