ИИ-агенту нельзя отдавать метрику без смысла

Агент ускоряет цикл, но не выбирает цель

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

Отсюда неприятный вывод. Узкое место часто не в количестве рук, идей или запусков. Оно в решении, что именно считать успехом.

Агент многократно усилит вашу цель, включая ошибочную.

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

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

Время плохо подходит для постоянного контроля

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

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

Такие показатели дают команде 3 вещи:

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

Удобное число сначала нужно связать с пользовательской пользой

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

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

Показателен случай с CLS. На верхнем уровне метрика выглядела благополучно. Но анализ сырых данных показал сдвиги вёрстки в 31% загрузок. Формально всё могло выглядеть приемлемо, а в реальном сценарии интерфейс продолжал прыгать.

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

Достигнутый результат надо превратить в правило

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

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

Для правила достаточно явно записать 3 вещи:

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

Человек задаёт планку, агент делает перебор

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

Человеческая работа здесь конкретна: поставить амбициозную цель, определить границы риска, смотреть на результаты и не позволять подменить исправление списком будущих действий. Полезная установка звучит так: «Таргеты - не точка остановки. Что дальше?»

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

Этот подход работает далеко за пределами скорости

Цикл «изменить - измерить - сохранить или откатить» подходит везде, где есть честный показатель и понятная ценность результата. В работе с ИИ это могут быть precision и recall для RAG, pass rate на evals, стоимость задачи в токенах, время сборки или число вызовов инструментов.

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

Если команде нужна среда, где правила, роли и рабочие сценарии собраны в одном месте, это можно организовать через ATLAS PANEL.