Агент улучшит любую метрику. Твоя работа - выбрать правильную

На днях Anthropic выпустили пост о том, как за двухнедельный спринт ускорили claude.ai и десктопное приложение в 3 раза. Годный и хорошо оформленный, советую прочитать целиком. Вот что я выделил:

1️⃣ Выбор метрики стал главным решением. Цикл "поменял - замерил - оставил или откатил" стал быстрым и дешевым, а еще его можно гонять параллельно: в пике шло 150+ тредов одновременно. Как только появлялось число, Claude начинал его улучшать. Поэтому больше всего в спринте давала не сама оптимизация, а выбор того, что мерить.

2️⃣ Считать шаги, а не время. Время шумит (частота CPU, сборщик мусора и тд) и не годится как гейт. Это как мерить прогулку по часам: туда попадают светофоры и пробки, которые от маршрута не зависят. А число шагов на том же маршруте одно и то же. В роли шагов у них - число инструкций CPU под Valgrind, React-коммиты, пересчеты стилей. Отличнейший инсайт!

3️⃣ Не каждая метрика полезна - ее надо приземлить. Удобное число еще не значит, что пользователю станет лучше. Поэтому инженеры ввели правило: каждый новый бенчмарк сначала должен доказать связь с реальным улучшением.

4️⃣ Планка, которая только опускается. Хорошая метрика становится автоматическим гейтом в CI: PR, который ее ухудшил, не пройдет. Так выигрыши не протухают.

5️⃣ Человек отвечает за амбицию, вкус и направление. Забавно было читать, как инженеры пинали и мотивировали агента. По умолчанию модель осторожничает: заводит тикеты вместо фиксов и закладывает запас в оценки. Один из инженеров, ходил по тредам с одной и той же фразой: "таргеты - не точка остановки, что дальше? Будь амбициознее!". В другом треде прямо написали: "я открыт к БЕЗУМНЫМ идеям".

Это часть большого тренда. Вы, наверное, давно замечаете волну переписывания на Rust: даже создатель Rails переписал бэкенд HEY на Rust агентами. В другом отличном свежем посте рассказывают как за лето ускорились open-source библиотеки, которые годами выжимали лучшие люди в теме. А Дэн Луу объясняет почему: упал порог окупаемости perf-оптимизаций (мол, больше нет оправданий тормозному софту).

По моему опыту, этот принцип куда шире перформанса: precision/recall в RAG, pass rate на evals, стоимость задачи в токенах, время сборки, tool calls - если есть честное число, агент будет его крутить. Сюда же autoresearch от Karpathy: одна метрика, фиксированный бюджет на эксперимент, и агент сам гоняет тот же цикл. Я применял этот подход в разных проектах, и он работает.

Но легко прочитать все это как "выбери метрику, натрави агентов - и готово". На деле все сложнее, и это, пожалуй, сквозная мысль поста Anthropic. Ключевые сценарии выбирали по данным использования. CLS показывал "хорошо", пока не полезли в сырые данные и не нашли сдвиги верстки в 31% загрузок. Каждый бенчмарк доказывал связь с реальностью, а люди в тредах постоянно договаривались, что на самом деле важно пользователю. Выбрать правильную метрику по-прежнему непросто: нужны внимание к деталям и согласие команды о том, что значит "лучше".

🔥 ➕ 🔁 @nobilix