Стандартная метрика сдвигов вёрстки ставила claude.ai оценку «хорошо» — а на 31% загрузок что-то на странице сдвигалось уже после того, как в ней можно было печатать.

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

Строки сайдбара подъезжали после загрузки, и ни один монитор этого не видел. Cumulative Layout Shift давал на сдвиг около 0,008 при пороге «хорошо» в 0,1. Заметили по записи экрана. Тогда Claude завёл событие, которое привязывает каждый сдвиг к области страницы и фазе загрузки, и тест, падающий на любом сдвиге: 20 из 20 красных прогонов на main, 20 из 20 зелёных на PR. Первые же данные с поля — те самые 31%.

Главный вывод авторы делают сами: раньше измерение было нулевым шагом, а с Claude это «step one of the climb». Дали агенту число — он его двигает. Поэтому самым ценным стало искать, что ещё можно посчитать, а каждый принятый замер превращался в порог CI, который можно только опускать.

Обратная сторона этого вывода: агент чинит ровно то, что видит метрика. Всё, чего она не видит, остаётся как было, при зелёном дашборде. Там же нашлась секунда зависания подсветки кода — из-за длинного тире, которое переводит строку в UTF-16.

https://claude.dev/blog/how-we-made-claude-ai-faster/

Какое зелёное число в вашем проекте вы ни разу не сверяли с записью экрана?