claude.ai разогнали в 3 раза за две недели с помощью Claude

Anthropic за двухнедельный спринт в августе ускорила основные сценарии claude.ai и десктопного приложения Claude примерно в три раза. Узкие места, бенчмарки, правки и наблюдение за деплоями команда поручила самому Claude; 23 сентября компания описала спринт в посте ClaudeDevs в X и в подробном разборе на claude.dev. Тем, кто хочет отдать агенту оптимизацию фронтенда, разбор даёт рабочий метод: сначала найти детерминированный счётчик вроде числа инструкций или React-коммитов, доказать, что он движется вместе с реальным временем, и закрепить его в CI планкой, которая может только опускаться. Все цифры в разборе получены замерами самой Anthropic.

Тройка - сводная оценка. По сценариям картина разная, если смотреть на 75-й перцентиль (время, в которое укладываются три четверти загрузок). Свежая загрузка claude.ai до момента, когда можно печатать, сократилась с 3,1 до 0,55 секунды, старт новой сессии Claude Code - с 0,8 до 0,3 секунды, загрузка облачной сессии Claude Cowork - с 2,6 до 0,73 секунды. Первая загрузка, выходит, стала быстрее более чем в пять раз, а старт Claude Code - примерно в 2,7 раза. В сумме, по оценке компании, пользователи ждут на десятки тысяч часов в день меньше.

Счётчик вместо секундомера

Реальное время - то, что чувствует пользователь, но оно шумит, и миллисекунды слишком нестабильны, чтобы валить по ним CI. Инженер Сэм спросил в треде, нельзя ли вместо этого считать JS-инструкции. Claude ответил, что для чистых JS-путей можно прогонять бенчмарк под Valgrind с node --predictable и сравнивать с закоммиченным базовым значением: «один прогон, статистика не нужна». Для браузерных путей Chromium считать инструкции не даёт, и Claude предложил другие детерминированные счётчики: React-коммиты на одно действие пользователя, число вызовов функций по точному покрытию V8, пересчёты layout и стилей, мутации DOM. Через одиннадцать минут шли пять тредов, по одному на каждый счётчик.

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

Доказывали на двух горячих путях: сборке дерева сообщений диалога и сканере статусных строк в выводе Claude Code. Профиль Valgrind показал, что четверть инструкций первого пути уходит на мегаморфные поиски по словарю (обращения, где V8 встречает слишком много разных форм объекта и переходит на медленный общий поиск), причём один и тот же ID сообщения разрешался трижды. Через час Claude срезал инструкции на первом пути на 48%, на втором на 31%, а реальное время упало на 78% и 44% соответственно.

Обе метрики после этого стали планками в CI. Любой PR, который поднимает число инструкций на этих путях, падает, а ежедневная задача опускает потолок, как только счёт снизился. Отсюда команда выводит главный урок спринта: раньше метрика была нулевым шагом, её добавляли и ждали данных, а с Claude она стала первым шагом оптимизации. «Как только у Claude появлялось число, которое нужно побить, он мог начинать оптимизацию», - пишут в Anthropic. Поэтому самым выгодным занятием оказался поиск новых вещей, которые можно измерить.

Как работал цикл

Сначала Claude через Datadog MCP разобрал данные об использовании и выделил четыре сценария, на которые приходится 95% активности: запуск приложения, новый диалог, открытие существующего диалога и отправка сообщения. На вебе, десктопе и разных продуктах это дало тринадцать замеров. Около двадцати заранее отобранных проектов Claude оценил в миллисекундах, из этих оценок сложили цели спринта, и двенадцать из тринадцати целей были выполнены уже к третьему дню. Среди плановых проектов: статичное поле ввода, вшитое прямо в HTML, чтобы печатать можно было ещё до инициализации React, и заранее скомпилированный кеш кода V8 для главного процесса десктопной оболочки. Для переходов поле ввода оставили смонтированным между диалогами, сессии стали подгружать при наведении курсора, а перерисовки боковой панели сократили на 90%.

Дальше всё шло через один канал в Slack с Claude в каждом треде. Кто-то открывал тред о медленном участке, часто со скриншотом или записью экрана. Claude прослеживал поток, находил или писал бенчмарк, который воспроизводит проблему, и приносил PR, чаще несколько, нарезанных по риску и удобству ревью, а всё заметное пользователю прятал за флагом. После выкатки Claude смотрел деплой и полевые данные: если стало быстрее, планку бенчмарка опускали, если нет, он выключал флаг и пробовал снова.

Пример: на записи экрана строки боковой панели появлялись после загрузки страницы, причём строки чата и Cowork приезжали в разное время. Ни один монитор этого не ловил. Ближе всех был Cumulative Layout Shift, но каждый сдвиг набирал около 0,008 при пороге «хорошо» в 0,1. Иссак предложил обратиться напрямую к Layout Instability API, и Claude сделал событие телеметрии, которое привязывает каждый сдвиг к именованной области (боковая панель, лента сообщений) и фазе (до первой отрисовки, после того как можно печатать). Интеграционный тест падал в 20 прогонах из 20 на main и проходил в 20 из 20 на ветке с исправлением. А полевые данные показали, что в 31% загрузок веб-версии что-то сдвигалось уже после того, как страница стала доступна, без всяких действий пользователя: поздняя строка заголовка, каретка, съезжавшая после загрузки имени, список, прыгавший при появлении полосы прокрутки.

В пике одновременно шли больше ста пятидесяти тредов, отдельный тред выдавал 50-100 PR, а в самые загруженные дни сливали больше двухсот изменений. Примерно треть PR добавляла телеметрию или ограничители. Шелли, одна из инженеров канала, назвала модель «демоном чисел». Находки при этом были вполне приземлённые:

• 6 900 хуков и 900 подписок на стор в пути набора текста, которые перерисовывались на каждое нажатие клавиши;
• один селектор :root:has(), добавлявший 24 миллисекунды к каждому изменению DOM;
• забытый location.reload(), дававший полмиллиона скрытых перезагрузок в день, которых не видела ни одна метрика загрузки;
• одинаковые снимки кеша, которые простаивающие вкладки дважды в минуту клонировали в IndexedDB, целиком в главном потоке.

Самая неожиданная находка касалась длинного тире. Подсветка готового блока кода могла заморозить страницу примерно на секунду: если в markdown ответа был хоть один символ вне Latin-1, вроде длинного тире или фигурной кавычки, V8 хранил всю строку в UTF-16, и каждое регулярное выражение подсветки шло по медленному двухбайтовому пути. Claude исправил это изменением в двадцать строк: перед подсветкой каждый блок кода копируется в однобайтовую строку.

Чья модель и чьи цифры

Спринт шёл на Claude Tag в бете с внутренней исследовательской моделью, которую Anthropic называет примерно сопоставимой с Opus 5.5. Цели, компромиссы и одобрение каждого изменения оставались за людьми. Каждый PR проходил автоматическое ревью и минимум одно одобрение человека, юнит-тесты писали до оптимизаций. По подсчёту компании, за спринт слили больше трёх тысяч изменений без единого инцидента для клиентов и без откатов. Переписка с Сэмом в посте воссоздана по реальному разговору.

Канал тем временем стал общим: другие команды начали приносить туда свои изменения на ревью производительности.