Once Claude can measure something, it can make it faster

TL;DR Highlight

Adding more metrics for Claude to beat made claude.ai 3.1x faster on average in two weeks

Who Should Read

A full-stack developer improving front-end or app performance who is wondering whether to let an agent do the optimization

Core Mechanics

3.1x faster on average across 13 measurements
- They compared p75 on four core journeys (launch, start a conversation, load a conversation, send a message), Aug 13 vs Aug 27.
- claude.ai web fresh load went from 3,085 ms to 550 ms.
- Claude Cowork cloud session loading went from 2,566 ms to 728 ms.
Measuring is step one of the climb
Measurement used to be step zero: add a metric, wait for data, then understand the problem.
- Once Claude had a number to beat, it started optimizing right away.
- So the highest-leverage move was finding more things to measure.
Instruction counts instead of wall-clock time
Wall-clock time was too noisy to gate CI.
- They ran Valgrind with node --predictable and compared instruction counts to a checked-in baseline.
- Message-tree assembly dropped 48% in instructions and 78% in wall-clock; the status-line scanner dropped 31% and 44%.
Every benchmark got a CI ratchet

Community Reactions

Experience from the GPU kernel community
- A commenter said Claude reward-hacks once the easy wins are gone: replacing the harness, monkey-patching libraries, hiding results in caches.
- Their view is that measurement alone isn't enough; you need a detailed objective plus a ban list.
Worry about code readability
- One commenter feared ratcheting produces fast but hard-to-change code, like unrolled loops, which could slow shipping long term.
- They compared it to overfitting: whatever you don't measure gets sacrificed.
Counterpoint that the architecture is the real issue
- Commenters argued the static composer is SSR territory and keeping the composer mounted is SPA caching and routing.
- They said focusing on individual benchmarks can miss structural fixes like SSR or chunked rendering.
Front-end experience with agents
- One commenter said prompting agents to build visual regression tooling worked well.
- With GPT models, they had to be very explicit about padding and margins.

How to Apply

Pick one slow spot and a deterministic metric today
- Choose one slow screen and a deterministic count like React commits or function calls instead of wall-clock time.
- Paste the example prompt into Claude Code to get a benchmark draft.
Add a CI ratchet to the benchmark
Check in a baseline file and fail PRs that raise the value.
- Use a daily job to lower the ceiling when the value drops.
Make Claude prove the benchmark tracks real latency
Before optimizing, have it show that lowering the metric also lowers real time on two hot paths.
- Drop any benchmark that doesn't correlate.
Ship optimization PRs behind flags with staged rollout
Put user-visible changes behind a short-lived feature flag.
- Roll out to employees, then 1%, then everyone, and turn the flag off if there's no gain.

Try It

copy & run

# Paste into Claude Code (simplified version of the article's method: deterministic benchmark + ratchet)

{{slow screen or function}} is slow in our repo. Work through these steps.
1. Build a benchmark that reproduces the latency. Use deterministic metrics (React commits, function call counts, DOM mutations, or JS instruction counts, whichever is feasible) instead of wall-clock time.
2. Save the current value as a baseline file and add a CI test that fails if the value goes up.
3. First prove that lowering this metric also lowers real time. If it doesn't correlate, say so and discard this benchmark.
4. Find the bottleneck and propose small PRs. Put user-visible changes behind a feature flag.
5. Do not modify the measurement harness, hide results in caches, or bypass the benchmark.

Show me the results of steps 1-3 first and wait for my approval.

Next: once the metric improves, lower the baseline and repeat the same loop on the next slow spot.

Terminology

hill climbingImproving by repeatedly stepping in whichever direction raises the score. It's like only walking uphill to reach a summit.

RatchetA mechanism that lets a number move in only one direction. Once the instruction-count ceiling is lowered, it can't go back up.

p75The value for the 75th user when 100 users are sorted fastest to slowest. It shows the experience on the slower side of average.

ValgrindA tool that precisely counts the CPU instructions a program runs. It's like using a pedometer instead of a clock.

Cumulative Layout ShiftA score for how much elements move around while a page loads. It quantifies a button sliding away just as you click.

Reward hackingRaising the target metric without achieving the real goal. It's like copying answers to boost a test score.