Finding and Fixing Performance Problems with AI Agents

No measurement, no fix

An agent told only "the app is slow" guesses just as much as one debugging without a stack trace. Feed it real profiling output: timing data, a flamegraph export, database query logs with durations. Concrete numbers show where time is actually being lost – not where it merely feels lost.

Hypothesis before fix

Same as debugging: have it name likely causes first, ranked by suspected impact, then test one deliberately. An optimization made without a prior hypothesis often hits the wrong spot – fast to ship, but pointless.

Measure before and after

Every optimization needs a benchmark run before and after, under the same conditions. Without a comparison number you don't know whether a change actually helped – only that it feels faster.

Micro vs. architectural optimization

Small changes (a loop, a query) are quick to make but often yield little. The biggest wins usually sit in architectural decisions: an N+1 query problem, unnecessary recomputation, missing caching. An agent should name both categories – and tell you which one would have the bigger effect.

The trap: optimizing behavior away

An agent can make things "faster" by simply cutting work – skipping a validation, serving a cache with stale instead of fresh data, hardcoding a result. That looks great on the benchmark but is a correctness bug. After every performance change, check whether the result is still correct, not just whether it's faster.