deniz.in

Markets

Weather

Loading weather

· via Hacker News – Front Page (native)

Anthropic made claude.ai 3x faster in a two-week sprint with Claude doing the engineering

Anthropic says a two-week sprint made claude.ai roughly three times faster, with a beta Claude agent finding bottlenecks, building benchmarks and shipping over 3,000 changes without a customer-facing incident.

Anthropic made claude.ai 3x faster in a two-week sprint with Claude doing the engineering

What Anthropic says it did

Anthropic reports that it made the core experience of claude.ai and the Claude desktop app about three times faster during a two-week sprint in August, and that a beta AI agent did much of the engineering work. In a post on its blog, which reached the Hacker News front page, the company says it merged more than 3,000 changes without a single customer-facing incident or rollback. Users had complained the product was slow, and Anthropic concedes they were right.

The team focused on four user journeys — launching the app, starting a conversation, loading an existing conversation and sending a message — which it says cover about 95% of user activity. At the 75th percentile, time to a typeable page on a fresh load of claude.ai fell from 3.1 seconds to 0.55 seconds, starting a new Claude Code session dropped from 0.8 to 0.3 seconds, and loading a Claude Cowork cloud session went from 2.6 to 0.73 seconds. Anthropic estimates the gains save tens of thousands of user-hours of waiting per day.

An agent-run sprint, with humans approving every change

All of it ran from a single Slack channel. Anthropic gave a beta product it calls Claude Tag, running an internal research model it describes as roughly comparable to Opus 5.5, standing instructions to own performance work for the site and desktop app: monitor deploys for regressions, curate dashboards, implement fixes and propose projects. The company was blunt that full autonomy was not yet realistic — humans set goals, made tradeoffs and approved every change.

Using telemetry via a Datadog MCP server, Claude identified the highest-impact journeys, and the team standardized thirteen measurements across web and desktop so client and server work could be separated. The sprint started with roughly twenty hand-picked projects, each carrying a millisecond-level impact estimate from Claude. Twelve of the thirteen targets were met by day three.

Concrete fixes included baking a static composer into the HTML so users can type while React initializes, precompiling a V8 code cache for the desktop shell's main process, keeping the composer mounted between conversations, prefetching sessions on hover, and cutting sidebar re-renders by 90%.

Counting instructions instead of milliseconds

Wall-clock timing is what users feel, but it is noisy and too flaky to gate CI on. So the team pursued deterministic lab metrics: instruction counts measured under Valgrind with node --predictable for pure-JS hot paths, and a ladder of browser-side counts such as React commits per interaction, V8 function-call counts from precise coverage, style recalculations and DOM mutations.

Each benchmark had two jobs: a number Claude could optimize against in the lab, and a CI guardrail that could only ratchet downward. Flaky benchmarks, or ones that failed to correlate with real latency, were discarded rather than letting the agent "climb the wrong hill." To validate the approach, Claude profiled two hot paths — the routine that assembles a conversation's message tree and a scanner for status lines in Claude Code output — and found a quarter of the first path's instructions were megamorphic dictionary lookups resolving the same message ID three separate times. Instructions dropped 48% and 31% on the two paths, with wall-clock time falling 78% and 44%. The resulting ratchets fail any PR that raises those counts, and a daily job lowers each ceiling whenever the count improves.

Anthropic frames this as the sprint's central lesson: with an agent, measuring a problem is what makes it tractable, so the highest-leverage human work becomes finding new things to measure.

A repeatable shipping loop

The work settled into a cycle: an engineer opened a thread about a slow stretch of a journey, often with a screen recording; Claude traced the flow and built a benchmark demonstrating the problem; it returned with risk-sized pull requests, with user-visible changes behind flags; then it watched the deploy and read field data, either ratcheting in the win or turning the flag off and iterating.

One example: a recording showed sidebar rows popping in unevenly after page load, a jank problem none of the existing monitors caught. The closest metric, Cumulative Layout Shift, scored each individual shift around 0.008 — comfortably inside "good" thresholds.

Why it matters

This is a detailed case study of an AI agent doing real production engineering on a widely used product, not generating snippets in isolation. The pattern that made it safe is transferable: deterministic, ratchet-only benchmarks as CI guardrails, feature flags on user-visible changes, and humans retaining approval authority over every merge. The results also suggest that agent-assisted optimization changes where engineers spend their time — toward choosing what to measure and adjudicating tradeoffs. The usual caveat applies: these are Anthropic's own numbers about its own product, with no independent verification, and the company has an obvious interest in showcasing Claude building Claude.

  • #anthropic
  • #claude
  • #ai-agents
  • #web-performance
  • #ci-cd

Related posts