Соавтор статьи — Сергей Левенец, CTO в команде ТестОпс.
Искусственный интеллект заметно ускорил разработку, и очевидных выгод от этого много. Оборотная сторона — выросли издержки на поддержку кода, прежде всего на работу с багами. И ложатся они в первую очередь на тестирование.
В прошлой статье мы рассказали про то, как в команде ТестОпс написали и отлаживали агента по правке багов. Но чуть ли не важнее самого агента оказалось справиться с теми изменениями, которые он принёс в рабочие процессы. А для этого нужно было научиться измерять издержки работы агента.
В этой статье мы расскажем о том, как это оказалось непросто, какие инструменты мы создали, и что ещё планируем сделать, чтобы агент лучше интегрировался в команду.
Технологии меняют не только инструменты, но и сам способ работы. Такие изменения редко внедряются вместо основной нагрузки — чаще команда осваивает их параллельно с текущими задачами, находя время на эксперименты, обратную связь и перестройку привычных процессов. Для этого нужны гибкость и определённая смелость: новое не всегда сразу понятно, не всегда работает с первой попытки и неизбежно ставит под сомнение устоявшийся порядок. Поэтому отдельно хотим поблагодарить всех наших инженеров за открытость к изменениям и за то, что они приняли «Агента Смита» в команду не как готовую технологию, а как совместный эксперимент. Особая благодарность Яну Коледе, QA-инженеру, Артёму Оводову, бэкенд-инженеру, и Андрею Подковырову, фронтенд-инженеру, — за готовность пробовать новое, честную обратную связь и вклад в развитие агента.
1. Прямые издержки
Внедрение любой технологии — это не одно решение, а множество, и для каждого из них нужна оценка побочных эффектов. Поэтому для работы «Агента Смита» был создан специальный механизм измерений затрат.
Прежде чем перейти к цифрам, стоит объяснить, зачем вообще строить дашборд, если можно спросить об успехах разработчиков. Ответ простой: субъективная оценка ускорения систематически врёт. В рандомизированном эксперименте METR 2025 года 16 опытных участников зрелых open-source проектов выполнили 246 задач: с ИИ-инструментами задачи занимали на 19% больше времени — при том, что сами участники после эксперимента оценили, что ИИ ускорил их примерно на 20%. Без приборных измерений такие ошибки неизбежны. И чтобы с этими измерениями было удобно работать, был сделан дашборд:
Что именно здесь измеряется?
Уже из прошлого описания видно, что для работы агенту нужно человеческое время. Как минимум:
Тестировщики должны помогать с acceptance-критериями, когда баг-репорт неочевидный. Если же и им не ясно, что считать правильным поведением, подключается разработчик. Этот этап самый дорогой.
Если решение агента оказывается дорогим (в стори-поинтах), разработчики должны оценить предложенный агентом план.
Каждый цикл доработок по комментариям ревью — это ещё один заход человека в контекст.
Логично спросить: всё это больше или меньше, чем разработчики потратили бы сами на исправление бага?
Чтобы сравнить, на платформе есть специальный дашборд, который подсчитывает ROI агента по формуле:
ROI = смёржено_фиксов × часы_экономии × ставка − циклов_доработок × часы_на_цикл × ставка − стоимость_LLM
Что здесь важно.
На стороне экономии:
Трудозатраты разработки на правку багов без агента. Это не прикидка на глаз: мы разобрали свои закрытые баги и получили в среднем 2 часа на штуку, если не брать явные исключения. В модель при этом заложили 1 час, то есть вдвое консервативнее собственного замера.
Считаются только смёрженные фиксы. Мёрж-реквест, который открыли и отвергли, даёт нулевую пользу и ненулевую стоимость. Смысл в том, чтобы сигнал успеха жил снаружи агента: его собственная зелёная проверка недостаточна. Правда, и мёрж — оракул несовершенный: мержит уставший человек, который агенту доверяет. Поэтому опираться честнее не на долю смёрженных, а на долю смёрженных без единой правки человеком — её подделать трудно.
На стороне издержек:
Доработки. Каждый цикл правок по ревью-комментам считается примерно за треть часа разработки: человек снова читает, снова ждёт, снова переключает контекст.
Цена самой модели. Здесь агенту повезло: он работает на сторонней модели, и вся стоимость сводится к оплате прогонов. Обучать собственную не имело бы смысла ни по деньгам, ни тем более по качеству — догнать фронтир на внутреннем корпусе нереально, а платить за попытку пришлось бы годами.
Все три параметра — часы экономии, ставка инженера, штраф за доработку — редактируются в интерфейсе: каждый подставляет свою экономику.
Допущения выбраны против агента, и несмотря на это ROI стабильно выходит положительным. Но прежде чем этому радоваться, стоит описать границы модели издержек — иначе она превращается в способ подтвердить то, во что и так верили.
Она почти не умеет говорить «нет». Посмотрите на арифметику — она вся в пропорциях. Принятый фикс засчитывается как час инженерного времени. Цикл доработок по ревью списывает примерно треть этого часа, а прогон модели на фоне часа работы инженера стоит копейки. Значит ROI уходит в ноль где-то на трёх с небольшим циклах доработок на каждый смёрженный фикс — причём при любой ставке, потому что ставка в этом сравнении сокращается. Это очень мягкий тест: он проходится почти всегда, если фиксы вообще мержатся. Поэтому положительный ROI сам по себе ничего не доказывает — содержательно тут ровно одно число: сколько циклов доработок в среднем приходится на фикс и насколько это далеко от трёх.
В ней нет стоимости разработки самого агента. Считается только эксплуатация. Арифметика тут простая и отрезвляющая: каждый принятый фикс возвращает час рабочего времени, значит человеко-неделя, вложенная в платформу, отбивается примерно сорока смёрженными фиксами, а человеко-месяц — уже ста семьюдесятью. Для всех, кто прикидывает, повторять ли опыт, это, пожалуй, самая релевантная цифра во всей статье — и её же чаще всего не приводят.
И то, и другое стоит держать в голове, читая любые заявления про окупаемость агентов.
Первое из них у нас есть. На 62 смёрженных фикса пришлось 25 циклов доработок по ревью — то есть 0,4 цикла на фикс при пороге около трёх. Запас примерно восьмикратный, и это, пожалуй, единственное содержательное утверждение об окупаемости, которое мы можем сделать честно.
Выгода от модели
Вначале взглянем на текущие издержки. В плюсе — 62 принятых фикса, то есть 62 часа инженерного времени по нашей же вдвое заниженной оценке. В минусе — 25 циклов доработок, около восьми часов; то есть выгода — примерно 54 часа, за вычетом $280 на модель (в эту сумму включена и стоимость экспериментов). Агент однозначно работает в плюс.
Насколько быстро это позволяет окупить первоначальные издержки по постройке?
Здесь нам повезло: первая рабочая версия заняла два-три дня, и всего на платформу ушло порядка человеко-недели — около сорока часов чистой разработки. Отладка шагов, чтение исследований и подбор промптов в этот счёт не входят: они идут до сих пор, параллельно с реальной работой, и отдельным проектом их никто не ведёт. Полученная сейчас польза — 54 часа — уже больше чем покрыла эти входные затраты.
Правда, «постройка» — не единовременная трата. Платформа дорабатывается постоянно, и не только ради багофиксов: на ней же живут воспроизведение багов, автоматизация тест-кейсов, ревью и тестовая документация, а общие части — движок процессов, дашборд, петли обратной связи — работают сразу на все флоу. Так что сорок часов правильнее считать порогом входа, а не итоговым счётом; зато и делится этот счёт не на один пайплайн. Но именно низкий порог входа — главный аргумент в пользу того, чтобы вообще пробовать.
Ко всем этим числам нужно добавить контекста. Сто прогонов — это мало: доля влитых в 81,6% на такой выборке означает «где-то восемьдесят», а не точную величину. И система под выборкой менялась: первые прогоны делал агент без этапа JUDGE, без воспроизводящего теста и без части гейтов, так что средняя за всё время смазывает картину. Мы и не претендуем на большее — это proof of concept, который показал, что схема рабочая и окупается на реальных задачах.
Повод для оптимизма
Есть и косвенные эффекты, которые могут дать экономию больше прямой. Это уже гипотезы, а не наблюдения — об опасности оценок на глаз мы уже говорили, поэтому сразу подумаем, как их проверить.
Если баги исправляются дёшево и автоматически, это должно поднимать мотивацию. Проверяется опросом и динамикой возвратов задач в работу.
Если цена исправления достаточно низкая, можно вообще не задаваться вопросом, исправлять баг или нет. Проверяется долей багов, закрытых как «не будем чинить».
Если этот вопрос не ставится, у разработки и тестирования становится меньше поводов для смены контекста на анализ трудозатрат. Проверяется временем от заведения бага до начала работы над ним.
Но получить полный эффект от этих преимуществ непросто, потому что помимо прямых издержек у агента есть косвенные.
2. Косвенные издержки: технический долг
Оценить косвенные издержки гораздо сложнее, чем прямые, а ситуация с ними менее оптимистичная. Начнём с технического долга.
Откуда он берётся
Фиксы агента часто умножают технический долг, в особенности когда речь идёт о сложных багах. Например, он может писать код, дублирующий уже существующую функциональность.
Это не только наше наблюдение — и новые модели проблему не сняли. Исследование GitClear «The Maintainability Gap», опубликованное в январе 2026 года, разбирает 623 миллиона изменений за 2023–2026 годы, то есть захватывает и нынешнее поколение моделей. За это время дублирование блоков выросло на 81%, доля копипасты внутри коммитов — на 41%, конструкции, маскирующие ошибки, — на 47%, а переиспользование (вызовы функций между файлами) упало на 35%. Рефакторинг почти исчез: доля перемещённого кода снизилась с 21% до 3,8%, и сегодня разработчик примерно в пять раз чаще скопирует, чем вынесет общее, — при том что в 2022-м предпочтение было обратным, два к одному.
Оговорка по источнику: GitClear — вендор аналитики кода, метрики «скопировано / перемещено» считаются по их собственной методологии, и их продукт живёт как раз на этом нарративе. Но даже с поправкой на это вывод для нас полезный: с дублированием мы не одиноки, и списывать его исключительно на особенности своего агента не стоит. Отдельно стоит отметить рост конструкций, маскирующих ошибки, — это ровно тот класс, за которым у нас охотится валидатор в списке анти-костылей.
Есть и более старая, фундаментальная проблема, о которой стоит знать всем, кто строит подобные пайплайны. В литературе по автоматическому исправлению программ различают патч правдоподобный (проходит тесты) и корректный (действительно чинит дефект). Классическая работа Qi et al., ISSTA 2015 разобрала патчи трёх тогдашних систем автоматического ремонта — GenProg, RSRepair и AE — и показала, что подавляющее большинство прошедших тесты патчей были неверными, а многие «чинили» баг простым удалением функциональности. Решающий аргумент авторы предъявили системой Kali, которая умеет только удалять код: она выдала не меньше корректных патчей, чем все три «настоящие». Корень проблемы в том, что тесты как оракул неполны, и с тех пор переобучение патчей стало отдельным направлением исследований.
Именно поэтому в нашем пайплайне зелёный тест не считается доказательством, а шаг VALIDATE отдельно делает аудит честности.
Как сделать работу агента качественнее
Здесь важно, что фиксы на бэкенде получаются заметно лучше, чем на фронтенде. Причин две, и вторая неочевидная.
Первая — в самом коде. Тестировать фронтенд сложнее, агенту труднее написать там воспроизводящий тест, а бэкенд вдобавок размечен файлами AGENTS.md и снабжён куда более подробной документацией. Правило простое: чем больше в репозитории артефактов, адресованных агенту, тем точнее он работает.
Вторая причина — в том, кто настраивал агента. Промпты, правила и гейты писал бэкенд-разработчик, и в них закодирована именно бэкендовая экспертиза: что считать костылём, где проходит граница слоёв, какой тест доказывает фикс.
Агент унаследовал не только сильные стороны своего автора, но и его слепые зоны. Это, пожалуй, самое отрезвляющее наблюдение за всю историю: качество агента упирается не в модель, а в то, чью экспертизу в него успели вложить.
Отсюда и ближайший план — подключить к настройке фронтендеров и внести их экспертизу тем же способом, каким вносилась бэкендовая.
Была мысль научить агента символьному поиску по коду (проект Serena). От этой идеи отказались: при этом подходе LSP-слой надо поднимать и поддерживать под каждый язык репозитория, а выигрыш конкретно для шага диагностики не был очевиден.
Зато прорабатывается другое решение — поиск по графу знаний. Он индексирует репозиторий в персистентный граф и позволяет спрашивать про связи, а не про строки.
Во-первых, этот поиск позволяет не держать в md-файлов ту часть, которая быстрее всего устаревает, — описание структуры: где что лежит, кто кого вызывает, какие есть точки входа. А вот правила «как надо и как нельзя» граф не заменяет и заменить не может: он показывает, что в коде есть, а не что должно быть. Разница принципиальная —
выводить конвенции из текущего состояния значит узаконить уже накопленный техдолг: если мутации БД в трёх местах протекли из репозитория в контроллер, граф отрапортует это как существующий паттерн, а не как нарушение. Так что нормативная часть остаётся в файлах — но приходит туда не вручную, а через петлю правил, вырабатываемых специальным агентом (о ней мы говорили в первой статье).
Во-вторых — и это главный расчёт — граф должен поднять качество самих фиксов. Самые дорогие ошибки агента — это ошибки не в написании кода, а в понимании его окрестностей:
кто ещё опирается на инвариант, который фикс собирается поменять;
правда ли смежный слой уже поддерживает то, на что рассчитывает фикс;
единичный ли это баг или соседние входы бьют в тот же дефектный путь.
Сегодня агент отвечает на такие вопросы грепом и здравым смыслом — то есть иногда угадывает. Граф же отвечает на них по построению.
Кстати, это же сокращает дублирование: прежде чем писать код, можно спросить, не реализована ли нужная функциональность где-то рядом. Но это — уже следствие, а не цель.
Если расчёт оправдается, фиксы будут реже промахиваться, и упадёт среднее число циклов доработок на фикс — то есть ровно та величина, которую мы назвали единственной содержательной в модели ROI. Появится шанс со временем разблокировать агенту рефакторинг, запрещённый сейчас именно из-за риска техдолга, — а вместе
с ним и задачи посложнее нынешних. Граф уже подключён за флагом, так что ждём, что покажет эксперимент.
Наконец, разработчики исследуют возможность добавить агенту больше контекста. Сейчас иногда возникают ситуации, когда агент пытается исправить поведение, которое не является багом. Этого не происходило бы, если бы агент умел читать историю фиксов, треды по различным проблемам и прошлые задачи. Обеспечить такую базу знаний только для «Смита» было бы слишком дорого, но она могла бы быть крайне полезной для других задач, и команда планирует её создать.
Новый взгляд на технический долг
Разработка с ИИ заставляет спросить: как работать с техническим долгом и сколько усилий на это тратить?
Полезно вспомнить, что стоит за метафорой. Долг — это не «некрасивый код», а проценты: то, чем расплачиваешься потом. Платят их в двух валютах — трудом за каждое следующее изменение и ценой дефекта, который этот код рано или поздно породит. //Значит, величина долга зависит не только от самого кода, но и от того, кто и как будет его менять, и во что обойдётся ошибка. ИИ подвинул все три множителя, причём в разные стороны, — поэтому пересматривать нужно не понятие долга, а конкретные позиции в портфеле.
Читаемость. Если раньше одним из важнейших критериев качества была человеческая читаемость, то сейчас основной объём чтения приходится на модель — например, когда человек просит найти нужный кусок. Однако модели помогает почти то же, что и человеку: локальность, явные имена, отсутствие неявных связей, небольшие модули (целиком помещающиеся в контекст). А самое дорогое чтение — разбор инцидента ночью — по-прежнему делает человек, причём под давлением. Изменился адресат рутинного чтения, а не цена непонятного кода.
Тут напрашивается контрпример. Роберт Мартин, автор «Чистого кода», недавно написал, что больше не читает код, написанный его агентами: по его словам, это единственный способ воспользоваться их продуктивностью. Если код вообще не читают, то и читаемость как будто ни при чём.
Но заменил он чтение не доверием, а экстремальными ограничениями вокруг агента: юнит-тестами, тестами на Gherkin, QA-процедурами, метриками качества, мутационным
тестированием, покрытием. Право не читать оплачено проверками, само по себе оно не наступает. Наш пайплайн — ставка ровно на это: не «прочитать за агентом», а окружить его проверками, которые он не может обойти.
Код, который ведёт к багам. Ещё одно рабочее определение долга. Раз стоимость исправления бага падает, этот критерий должен просесть в значимости — но только на половине цепочки. Дешевеет исправление, а не попадание дефекта к пользователю: баг, доехавший до продакшена, стоит ровно столько же, сколько стоил раньше. Правее релиза удешевления не произошло.
Связанность. Является ли жёсткая связанность техническим долгом? В теории — да. Но здесь тоже всё упирается в вопрос издержек. Гексагональная архитектура, в которой ядро ничего не знает о своей реализации — это здорово, но есть случаи, когда нарушения этого паттерна общеприняты.
Например, в Java-среде почти все проекты написаны на Spring Boot, вероятность миграции с него почти нулевая, а цена полной отвязки ядра архитектуры от Spring Boot — огромная. Граница, по которой мы проводим решение отвязывать архитектуру или нет, проводится по объёму трудозатрат. Держать доменные классы свободными от аннотаций фреймворка
дёшево и окупается сразу, ещё до всякой миграции: такой домен тестируется без поднятия контекста. Выносить за порты каждое обращение к инфраструктуре — дорого и окупается только в сценарии, который никогда не настанет.
Здесь же и ответ на вопрос, сколько усилий тратить на долг. Столько, сколько сэкономит его устранение. Для агента это неудобная новость, потому что этого он не знает — поэтому он одинаково охотно строит абстракцию «на будущее», которого не случится, и протаскивает зависимость через три слоя, потому что так короче. Это, а не нехватка сообразительности
у модели, — настоящая причина, по которой рефакторинг ему пока не доверяют. И заодно видно, чего для этого не хватает: не более умной модели, а базы знаний — истории решений, отменённых планов и того, что в этом коде уже пробовали менять.
Даже с такой базой агенту — как и людям — придётся нарушать устоявшиеся практики чистого кода. Но нет ничего более естественного, чем нарушение правил. Во Вселенной, которая после Большого взрыва оказалась бы идеально однородной, не образовалось бы ничего — ни галактик, ни звёзд, ни нас: тяготению просто нечего было бы стягивать. Всё существующее выросло из ничтожных неоднородностей плотности порядка одной стотысячной; они до сих пор видны как рябь в реликтовом излучении.
Идеальная однородность — это отсутствие информации, а всякая структура начинается с отклонения. Кодовая база, в которой не осталось ни одного места, где кто-то сознательно заплатил сложностью за гибкость или гибкостью за простоту, — это либо база, в которую перестали вносить изменения, либо база, за чистоту которой заплатили тем, чего в ней теперь нет.
Поэтому важна не конечная картинка идеальных правил, а метод движения, учитывающий реальные издержки — и «ноль багов в бэклоге», с которого начиналась эта история, честнее читать как вектор, а не как пункт назначения.
3. Косвенные издержки: нагрузка на QA
Мы давно знаем, что чем «левее» в релизном цикле удалось поймать проблему, тем дешевле её решить. Поэтому закономерно, что самым больным по нагрузке участком при внедрении «Агента Смита» стал один из процессов с «правой» стороны: ручной регресс.
Агент существенно усложнил жизнь тестировщикам — хотя и не в одиночку:
Во-первых, поскольку агент действительно ускорил разработку, в тестирование стал приходить гораздо больше кода, чем обычно. Эта нагрузка росла и до «Смита» благодаря другим нейросетевым инструментам, и ресурсы QA были уже напряжены.
Во-вторых, к коду, написанному с участием нейросетей, пока меньше доверия — и, по опыту тестировщиков, багов в нём действительно больше. Здесь речь не только про «Смита»: основной объём такого кода дают разработчики, работающие с ИИ-ассистентами.
Эти проблемы существовали и до «Смита»; главной его издержкой стало то, что он ускорил один участок конвейера, не трогая остальные, — а система не едет быстрее своего узкого места, и возникает очередь. Именно этот эффект обнаружили в отчёте DORA 2025 года: выяснилось, что связь внедрения ИИ с пропускной способностью доставки положительная — а вот со стабильностью доставки отрицательная. Конечно, отчёт написан год назад, но объяснение авторов работает и сегодня: ускорение обнажает слабости ниже по потоку, и без надёжных систем контроля — автотестов, зрелой работы с версиями, быстрой обратной связи — рост объёма изменений оборачивается нестабильностью.
Проблема в том, что учесть эти дополнительные издержки, скажем, в том же дашборде, гораздо сложнее, чем издержки времени разработчиков — как раз потому, что они «правее» в релизном цикле и проследить связь с работой агента сложнее.
Что же можно предпринять?
Коротко говоря:
двигать проверки влево, туда, где ошибки обнаруживать дешевле
разбираться, где поток забивается на самом деле
наращивать мощность в конце линии
Работа с требованиями
Требования почти никогда не полны: часть ответов живёт в Figma, часть — в тредах мессенджера, часть не существует нигде, пока кто-нибудь не спросит. Сегодня эти пробелы всплывают, когда код уже написан, а тестировщик упирается в вопрос «а как вообще должно быть».
Агент способен вскрывать эти пробелы раньше, причём с двух сторон сразу.
Он строит критерии приёмки строго по тексту задачи — а значит, видит ровно ту границу, где текст заканчивается и начинается догадка.
Он читает кодовую базу — а значит, видит расхождения между тем, что написано в требовании, и тем, как система устроена на самом деле.
Здесь — первый способ ускорить процесс: оба списка, пробелы и расхождения, можно отдавать людям до начала разработки, а не после неё. Дыру это закроет не полностью: агент не знает, чего он не знает, и молчащее требование выглядит для него полным. Но ценность не в том, чтобы агент дописал требование за аналитика. Она в том, что три амиго — аналитик, разработчик, тестировщик — садятся обсуждать не пустой лист, а конкретный перечень вопросов, у каждого из которых есть адрес в коде или цитата из задачи. Разговор про требования стоит дорого; сделать его короче и предметнее — самый дешёвый способ убрать поток вопросов, который сейчас доезжает до этапа проверки.
Ревью кода
Один из самых ранних этапов проверки — ревью кода. Здесь важно, с чем сверяют новый код. Если дифф читают не сам по себе, а против тестовой документации — сценариев и чеклистов на эту функциональность, — потенциальные баги видны сразу, ещё до всякого запуска. Не «код выглядит нормально», а «вот этот сценарий из чеклиста диффом не закрыт, а вот в этом ветка ошибки не обработана».
Здесь, впрочем, есть неприятная симметрия. Ревью — одновременно и лекарство, и место, где стоит очередь: как будет видно в конце раздела, именно в ожидании ревью агентский мёрж-реквест проводит основную часть календарного времени. Усиливая ревью, мы давим на то самое узкое место, которое пытаетесь расшить. Выход не в том, чтобы ревьюить меньше, а в том, чтобы к моменту ревью на руках было больше готовых доказательств, — об этом следующий пункт.
Агент, доказывающий свой фикс
Самое приоритетное направление проверки — научить агента воспроизводить баг и проверять собственный фикс на тестовом стенде, прикладывая доказательство к мёрж-реквесту: воспроизведение до правки, его отсутствие после, видео и скриншоты обоих прогонов.
Сейчас агент утверждает, что починил, а проверяет это человек — причём проверяет с нуля, потому что верить утверждению не на чем. Если к мёрж-реквесту приложен пруф, работа тестировщика меняется качественно: он не воспроизводит заново, а смотрит на доказательство и решает, засчитывать ли его. Это, похоже, единственный способ снять нагрузку, не понижая планку.
Части этого процесса уже работают на той же платформе: агент умеет сам драйвить браузер и приносить вердикт с видео и скриншотами, умеет писать Playwright-спеки и гонять их на своей ветке до зелёного. Задача — соединить эти действия в багофикс-пайплайне.
Пропускная способность QA
Для нового темпа разработки нужна новая пропускная способность QA — это было ясно и до «Смита». Вопрос в том, чем её набирать. Наращивать руки в конце линии — самый дорогой из способов. Можно ли набрать её ускорением самого QA нейросетями?
Да, можно — но это требует предварительной работы: по внутреннему опыту команды тестирования нейросетевые помощники лучше всего приживаются там, где уже стабильно работают человеческие процессы.
Есть и другое решение. Главное, что сейчас не может делать агент, и может — тестировщик, это знать, что значит «продукт работает». Конечно, последнее слово останется за QA, но облегчить нагрузку может помочь проектирование оракулов — так проверки уйдут «влево» и станут дешевле. Это самое интересное направление из всех, что у нас запланированы, и самый большой плацдарм для новых решений.
Главный вывод такой: ускорять написание кода бессмысленно, если система не может его доставить, потому что пропускная способность потока равна пропускной способности узкого места. Хитрость в том, чтобы знать, где именно это место находится — за расшивкой одного участка проблемы неизбежно возникнут в другом. Поэтому при работе с любым растущим процессом нужно опираться на измерения и внимательно прислушиваться к обратной связи.
4. Ближайшее будущее
В этих двух статьях мы много говорили о планах по улучшению агента; здесь коротко перечислим то, что уже в работе или на подходе.
Замкнуть проверку на самом агенте. Это тот самый оракул, о котором говорили в предыдущем разделе: агент поднимает ветку, воспроизводит баг, чинит его, дописывает недостающие тесты любого уровня и сам прикладывает доказательство к мёрж-реквесту. Части этого уже работают порознь; задача — свести их в один пайплайн.
Собственный эксперимент вместо чужих цифр. Благодаря тому, что шаг с созданием теста BRT (Bug Reproduction Test) можно отключать, мы собираем статистику по результатам с ним и без него, чтобы лучше понимать его эффективность.
Отбор лучшего из нескольких фиксов. В исследовании Google предлагается генерировать пул патчей и выбирать между ними по прохождению воспроизводящего теста. У нас для этого уже есть всё: красный BRT как отборочный оракул и изолированная рабочая копия.
Измерение переобучения. Набор проверок, которых агент не видит, позволит измерять число случаев, когда патч прохдит быстрый гейт, но падает на этом скрытом наборе. Так мы получим честно измеренный уровень переобучения патчей.
Измерение багов, заведённых после мержа фикса. Прямой сигнал о том, что фикс создал новую проблему. Ровно та косвенная издержка, которую мы называем трудноизмеримой — и которую измерить всё-таки можно.
QA-время в формуле ROI. Модель считает только часы разработчиков; час тестировщика, ушедший на проверку агентской правки, в неё не входит — а после раздела 4 понятно, что это самая недооценённая статья расходов.
5. Заключение
Агентная правка багов оказалась интереснейшей историей. Она взяла на себя интеллектуальную рутину — и при этом заставила много думать: о себе самой, о фундаментальных теоретических подходах в отрасли, и о человеческих процессах.
Для работы агента оказалась крайне важна его инфраструктура: качественные промпты, файлы с инструкциями, подробная документация. Решение отдать управление ветвлениями коду, а не модели, сделало систему отлаживаемой.
Не менее важным оказался человеческий труд. Новый, более нагруженный процесс болезненно реагирует на неполные требования, неравномерное ревью кода и на то, что готовый фикс приезжает без доказательств.
От того, что разработка ускорилась, никуда не уйти. Вполне естественно, что у новых инструментов множество побочных эффектов — поэтому мы учимся их измерять и ищем новую точку равновесия. Впереди — фронтенд-экспертиза в настройке агента, более качественная разметка кода, работа с узким местом доставки и создание общей базы
знаний.
Но главная ценность этой работы, пожалуй, не в починенных багах. До «Смита» нейросети меняли инструменты внутри процесса — сейчас же поменялся сам процесс:
сместились точки, где нужен человек;
изменилось, что считается доказательством работы фикса;
появились метрики, которых раньше просто не существовало.
Всё, что пришлось изобрести по дороге — оракул, отделённый от исполнителя; гейты доверия; петля правил; измерение косвенных издержек — оказалось не про баги. Это переносимая оснастка для любого агентного процесса, а заодно честный ответ на вопрос, во что такой процесс обходится на самом деле.
Этот опыт мы получили на одном узком, хорошо очерченном классе задач — причём таком, где критерий правильности можно вывести из репорта и превратить в проверку, а успех подтверждается извне, судьбой мёрж-реквеста. Почти всё по-настоящему интересное лишено и того, другого: требования, архитектурные решения, приоритизация, работа с легаси.
Ни один из шагов «Смита» не переносится туда как есть — зато переносится способ рассуждать: отдели оракула от исполнителя, назови заранее, что считается доказательством, померь, во что это обошлось, и не верь себе на слово. Если из статьи что-то и стоит унести, то именно это, а не список конкретных шагов.
В «Матрице» агент Смит — программа, которая начинает бесконтрольно копировать себя
и в итоге ломает систему, частью которой была. Имя выбирали в шутку, но шутка оказалась содержательной: всё, что здесь описано, — это, по сути, попытка не дать полезному автоматическому размножению кода стать неконтролируемым.
