Using Claude Code for Performance Work
Claude can find and fix performance issues but needs to be pointed at the right things. Here's the workflow.
Performance work with Claude has a specific failure mode: Claude optimizes the code it can see, not the code that's actually slow. If you paste a function and ask "how can I make this faster," you'll get micro-optimizations on something that might not be the bottleneck at all.
The workflow that actually works starts with measurement.
Start with profiling data, not guesses
Before Claude touches anything, I run a profiler and find the actual slow paths. In Node.js that's usually the built-in profiler or clinic.js. In browser JavaScript, the Performance tab. For database work, query explain plans.
Then I give Claude the profiling output along with the relevant code: "Here's the flamegraph. The slow paths are X, Y, Z. Here's the code for each. What are the optimization options?"
That question — options, not fixes — is deliberate. Performance optimizations have tradeoffs. Claude will lay them out if you ask, rather than just picking one.
What Claude is good at for performance
Algorithm complexity. If you have an O(n²) loop that could be O(n) with a different data structure, Claude will spot it and rewrite it. This is probably Claude's highest-value contribution to performance work.
Unnecessary re-renders in React. Given a component tree, Claude can identify which components are re-rendering unnecessarily and where useMemo, useCallback, or memo wrappers would help.
Database query patterns. N+1 queries, missing indexes, unnecessary joins — Claude recognizes these patterns and suggests fixes. It won't know your exact schema unless you give it to it, but it recognizes the patterns.
Bundle size analysis. If you paste your webpack or vite bundle analysis output, Claude can identify large dependencies and suggest tree-shaking or lazy-loading strategies.
What Claude gets wrong on performance
Premature micro-optimization. Claude will sometimes suggest changes that are theoretically faster but practically irrelevant — caching a value that's only computed once, using a slightly faster array method on a 10-item array. These aren't wrong, they're just not useful.
I've started adding to performance prompts: "Focus only on changes that would move a benchmark by at least 5%. Skip anything that's theoretical or unmeasurable."
Verify with benchmarks
Performance claims need measurement. After Claude produces an optimization, I benchmark the before and after. This is important not just to confirm the speedup — it's also to catch regressions. Sometimes an "optimization" makes the common case faster but the edge cases much slower.
Claude can write the benchmarks too. Give it the function under test and ask for a benchmark using whatever framework you prefer (Vitest bench, benchmark.js, etc.).