В первой части я рассказал, как из ручного копипаста тикетов в консоль агента вырос ИИ-Автопилот — полный конвейер от YouTrack до проверки в живом 2D/3D GUI. По ощущениям всё летало: бэклог таял, в SVN постоянно появлялись коммиты, пользователи едва успевали проверять готовые задачи.
Вот только «по ощущениям» — это ровно та валюта, в которой посчитано большинство статей про ИИ-агентов, и доверия к ней у меня немного. Любая активная система выглядит продуктивной: что-то постоянно собирается, коммитится, переписывается. Отличить эффективность от активности можно только замером.
Поэтому мы собрали всё, до чего смогли дотянуться, и посчитали по-честному. Ниже — что из этого вышло.
Как я считал
Источника три, и ни один из них на наши вопросы в одиночку не отвечает:
-
YouTrack хранит постановку, переходы состояний и решение репортёра;
-
SVN показывает, какой код вошёл в продукт;
-
журналы системы объясняют внутренние попытки, время и токены.
Считал я по двум периодам: как проект жил до ИИ-Автопилота и как живёт после. «После» — это с конца мая, восемь полных недель работы на боевых задачах. «До» — с начала года и до конца мая, когда всё делалось руками.
Главной единицей результата я выбрал Verified. Fixed означает только, что разработчик или система считают работу готовой; между ним и приёмкой иногда проходит несколько дней, а порой случается Reopened, когда пользователь возвращает задачу на доделку. То есть считаю я не «мы сделали», а «у нас приняли».
Ждём теперь не разработчиков, а пользователей
До ИИ-Автопилота проект принимал меньше 5 задач в неделю. После разгона — около 60, и три четверти из них закрыл ИИ-Автопилот. Вот и те самые «в тринадцать раз» из заголовка.
Серым показаны поставки людей, бирюзовым — те, где последний Fixed перед приёмкой сделал ИИ-Автопилот, оранжевым — совместная работа. Тонкая линия — новые заявки: их тоже стало больше, но закрывали мы всё равно больше, чем приходило.
Примечательны тут не только столбцы принятых задач, но и тонкая линия новых заявок. Вместе с решёнными задачами росли и новые: пользователи стали заводить почти втрое больше заявок, чем раньше. Часть из них, впрочем, завела сама система: крупные задачи она разбивает на отдельно проверяемые куски — 45 тикетов из 364. Сначала я списал этот рост на совпадение: мол, попали в активный период. Потом дошло, что это могло быть закономерно.
Гипотеза простая, хотя доказывать её я не брался. Раньше о части проблем просто не писали: какой смысл, если задача месяцами лежит без движения. Пользователь молча обходил неудобное место и работал дальше. А когда чинить стали быстрее чем за день, смысл появился, и люди понесли то, что копили.
Что задачи и правда перестали лежать без движения, видно по срокам. Половина теперь получает первое исправление меньше чем за день, а раньше на это уходило почти три. Это медиана. А были заявки, которые висели месяцами, иные и годами, просто потому что до них никогда не доходила очередь. Так и накопился наш бэклог. Сейчас руки доходят до каждой.
А вот принимать быстрее пользователи не стали. Мы ускорили Решалу, то есть ту часть, что ведёт задачу от тикета до коммита. А сколько готовое исправление пролежит до приёмки, от нас уже не зависит.
Что случилось со старым бэклогом
Кроме свежего потока нам досталось наследство: задачи, копившиеся годами. Те самые, до которых у живой команды никогда не доходили руки — не потому что они неважные, а потому что всегда есть что-то срочнее. На старте таких активных задач набралось больше 700. Мы поставили отсечку по возрасту в 9 месяцев и взяли из них 144, а остальные не стали откапывать из-под пыли времён.
За несколько недель почти две трети задач получили исправление, которое пользователи приняли. Часть закрылась без исправления: что-то оказалось не багом, что-то уже неактуальным. А те, что подвисли, ждут не нас: тестера, который дойдёт до проверки, или автора заявки, который ответит на наш вопрос.
Разобрать задачу не значит закрыть её. Через систему прошли все, а дальше почти всё упирается в человека.
А мощности хватает с запасом. Когда разбирали это наследство, я держал три Решалы разом на разных машинах. Сейчас новых задач приходит меньше, и хватает одной.
Реопены полезли вверх
Разогнались и почти сразу увидели обратную сторону: задачи стали чаще возвращаться на доработку. Кривая поползла вверх, и не заметить это было нельзя.
Красная линия — доля Reopened среди задач с решением тестера. Оранжевая горизонталь — около 11% до запуска.
Возврат — это не приговор задаче, а отметка, что с первого раза не прошло: из тех, что хоть раз возвращали, больше трёх четвертей к моменту среза уже приняты. Но каждая такая задача съедала ещё круг исправления и проверки, а до того раздражала пользователя и впустую отнимала его время на проверку.
Пользователи это и заметили первыми. Причём возвращали в основном не потому, что код не работал, а потому что доказательство выходило так себе: кадр снят не в том месте, не в том масштабе, показывает не то, о чём просил человек. Формально сделано, а доказательств нет.
И тут же выяснилось, зачем эта возня вообще нужна. Кривой путь проверки или неубедительный кадр часто оказывались признаком того, что задачу просто поняли неправильно: пока не воспроизведёшь в интерфейсе руками, этого не видно.
А иногда Решала и вовсе отказывался от работы: не смог добыть доказательство — объявил задачу сложной и отправил её лиду. То самое умение вовремя сказать «не могу», которым я хвалился в первой части, сперва сработало чересчур усердно. Таких лишних эскалаций набралось прилично, и здесь сильная модель на проверке пригодилась ещё раз. Она просто доделывала такие задачи сама, вместо того чтобы занимать ими тимлида.
Так и появился Проверяла — независимый второй проход по каждому готовому результату. Сначала было недовольство пользователей: ИИ тупит и показывает не то. Потом мы завели этот проход и стали следить за процентом реопенов. По той же причине сейчас пробуем на этой роли другую модель.
Поэтому возвраты у нас теперь важный показатель качества. Ускорение множит не только результат, но и брак, а пока его некому вернуть, брака как будто и нет.
Мелочь или большая работа?
Тут вы наверняка спросите: а что это за задачи такие? Крупные фичи или, может, всего лишь правки опечаток во всплывающих подсказках? Вопрос честный, и ответить на него труднее, чем кажется: объём работы мерить не так просто. Поэтому померяем хотя бы то, что легко поддаётся счёту, — строки и файлы.
Правки выходят очень разного размера. Половина задач укладывается примерно в 80 строк и 3 файла, обычная рабочая мелочь. Но хвост длинный: 130 задач задели 5 файлов и больше, 11 перевалили за 1000 строк, а самая крупная — 4896 строк в 31 файле.
Размер правки показывает охват изменения, но ни сложность его, ни ценность.
Видно, что это не поток микрофиксов. Мелких правок и правда больше, но рядом с ними идут крупные изменения и сложная работа с трёхмерной графикой, которой в нашем продукте много.
Разброс тут интереснее медианы. Один и тот же конвейер делает совсем разную работу: убирает лишнее предупреждение при импорте, разворачивает подписи изолиний на картах, добавляет новый сейсмический атрибут вместе с его формулой, строит слайсер для трёхмерных сеток с заполненным разрезом и подвижной плоскостью глубины, делает лучевой пересчёт скоростей.
Куда уходит машинное время
За почти восемь недель, с 1 июня по утро 25 июля, все наши модули наработали 869 часов по 555 задачам. Это чистая работа: разбор, код, ревью, время сборок, добывание доказательств в живом интерфейсе, независимая проверка, а заодно переделки и неудачные попытки. Простой, ожидание людей и моё время сюда не входят.
Выходит около 112 часов в неделю. Сравните с инженером, который работает сорок часов, никогда не отвлекается, печатает мгновенно и всё это время не отходит от своего агента: получится нагрузка примерно на 2,8 таких инженера. Инженеров мы автоматами не заменяем, но масштаб так виден нагляднее всего.
Агенты при этом работают круглосуточно, выходных у них нет: у одной машины в неделе 168 часов, и таких машин у нас несколько. Расходуем мы заметно меньше. Часть времени агенты просто стоят без задач, часть уходит на доработку самой инфраструктуры. Так что 112 часов в неделю — это не предел флота, а столько работы мы в него сумели залить.
Если разложить эти часы по видам работы, на разбор, код и ревью приходится примерно пятая часть. Всё остальное — сборки, доказательства в интерфейсе и независимая проверка. На каждый час разбора, кода и ревью приходится почти четыре часа на то, чтобы убедиться, что написанное работает. Аудит тут отдельная статья расходов: 300 с лишним проходов, и больше трети из них повторные. Система спорит сама с собой.
Пересекающиеся стадии одной задачи учитываются один раз. Одновременная работа по разным задачам складывается: это действительно несколько занятых агентов.
Иронично. Мы гордились техническим мышлением, а первым делом сами же отдали его машине. Самой дорогой работой в итоге оказалась работа ручного тестера.
Значит, ускорять само написание кода дальше почти бессмысленно. Четыре пятых времени уходит на то, чтобы можно было сказать «готово» и не соврать: собрать, показать на живом экране, дать перепроверить. Следующая задача — дешёвое доказательство.
Сколько это стоило
Деньгами всё это выходит в $500 в месяц на подписки: $200 Claude, $200 Codex и ещё $100 — моя личная, которую система тоже подъедает. В эти пятьсот мы влезаем впритык.
Полной стоимостью системы их называть нельзя: сюда не входит ни разработка самого конвейера, ни человеческое время на продуктовые решения и приёмку, ни облачные машины, на которых всё это крутится. Это ровно та сумма, которую мы платим каждый месяц за сами модели.
Если бы тот же объём работы шёл не по подписке, а по опубликованным тарифам за токены, его эквивалент составил бы примерно 5700 долларов в месяц. Больше чем в одиннадцать раз дороже. Это не счёт, который нам кто-то выставил, и не сэкономленные деньги: это цена вопроса, если считать просто по цене токенов.
Столбцы — не наши платежи, а эквивалент того же измеренного использования по опубликованным тарифам. Реальный доступ ко всем моделям стоил 500 долларов в месяц по подпискам.
Самое дорогое — аудит на Codex. У нас там стоит 5.6 Sol, модель не из дешёвых, и это сразу видно по счёту: средний проход обходился почти в $17 против примерно $3 у Claude. Вторые глаза внезапно оказались почти в шесть раз дороже первых. На вторую неделю эксперимента удалось сэкономить, цена прохода опустилась примерно до $15, но дорого всё равно.
И всё же оно того стоило. Claude чаще говорил «годится» и стоил дёшево. Codex возвращал работу на правку примерно в каждом третьем проходе, Claude — примерно в одном из четырнадцати. На живом интерфейсе Codex однозначно сильнее, и это заметили пользователи: доказательства стали убедительнее, а возвратов меньше.
И вот что стоит сказать про эти пятьсот долларов. Они несопоставимы даже с частичной занятостью одного инженера, а работы делается как минимум за двоих. Причём делается не в тепличных условиях: с переделками, с возвратами и с постоянной доводкой самой системы.
Отсюда и следующий опыт, который идёт прямо сейчас. Codex переезжает на роль Испыталы (GUI-пилот) — того, кто добывает доказательство в живом интерфейсе, а аудит возвращается на модель попроще. Расчёт такой: если сразу делать хорошо, то и проверять придётся не так свирепо. Идея красивая, но её надо проверить.
Почему у нас 13x, а у других 25%
Читатель, который следит за исследованиями, тут может насторожиться. В рандомизированном эксперименте METR 16 опытных разработчиков открытых проектов с ИИ-инструментами работали в среднем на 19% дольше. В трёх полевых экспериментах Microsoft, Accenture и ещё одной компании простой доступ к ИИ-помощнику дал рост числа выполненных задач примерно на четверть на выборке почти в 5000 человек. А тут вдруг в 13 раз.
Отчасти дело в том, что измеряли разное. Там опытный сопровождающий с помощником в репозитории, который он и так знает наизусть, или рядовой разработчик с автодополнением. Здесь конвейер от заявки до доказательства.
Но есть объяснение поинтереснее, и мне оно кажется главным. Наш проект годами жил в дефиците рук. Задач всегда было больше, чем людей: очередь копилась, до части заявок никто не доходил, а пользователи привыкли не просить. Мы не ускорили в тринадцать раз хорошо работающую команду. Мы открыли вентиль там, где давно копилось давление.
Если так, то и скромные чужие проценты понятны: там измеряли команды, которые не жили в таком голоде. Дело не в модели, а в разрыве между накопившейся работой и руками, которых на неё не хватало. Надёжно проверить это я не могу: одного проекта для такого вывода мало. Но как рабочая гипотеза она объясняет разом и наши тринадцать раз, и их двадцать пять процентов.
Разработка больше не предел
Выше 100% здесь означает, что вместе со свежим потоком система разбирала старый запас. Это не процент «успеха» одной задачи, а отношение двух потоков за четыре недели.
На графике две линии: сколько задач мы исправили и сколько из них приняли, обе в процентах от новых заявок. С января и до весны они идут ниже паритета — заявок приходит больше, чем закрывается, очередь растёт. К июлю обе поднялись выше ста: в последнем окне исправлено 122%, принято 138%. Свежий поток закрывается целиком, и сверху ещё убывает старый запас.
По объёму приёмка успевает: за неделю люди принимают больше задач, чем приходит новых, и вдобавок разбирают накопленное — отсюда 138 против 122. А вот быстрее принимать одну задачу они не стали, как ждали пару дней, так и ждём. Предел никуда не исчез, он просто переехал: задачу надо поставить, проверить по существу и принять. Наращивать мощность разработки дальше без этих людей нет смысла.
А наши тринадцать раз оказались не свойством модели, а размером прежней пробки в нашем проекте. Расчистим и эту пробку — посчитаем заново, и она наверняка обнаружится где-нибудь ещё.
Если делаете похожее и уже собрали свои грабли, расскажите в комментах какие.
Автор: sae13
