AI Coding Agents
Performance
Performance regression review with coding agents
September 22, 2026 - 2 minute read
Performance regression review checks the application after a coding agent changes it, rather than measuring how quickly the agent writes code. Suppose a changed endpoint looks fast with a warm local cache but performs a database query for every returned item on a cold request. Reviewers need a comparable workload to establish whether the change violates the service's latency or query budget.
A performance budget turns that limit into a merge criterion. Google’s performance budget guidance describes budgets for quantities such as resource size, timing milestones, and rule-based scores. Backend services can apply the same principle to latency, throughput, memory, database calls, or queue depth.
Start from a comparable baseline
Choose a representative workload before reviewing the patch. Fix the dataset, concurrency, cache state, runtime version, hardware class, and number of samples. Compare the branch with its merge base under the same conditions. A result from a warm local cache cannot support a claim about a cold production path.
For the endpoint example, run the same request against the branch and merge base with equivalent cold-cache preparation. Preserve the number and shape of returned items, capture query counts and plans, and measure response latency across repeated runs. Repeat the warm-cache case separately. That distinguishes added database work from a change in cache hit rate.
Other changes need different measurements, such as bundle size for a frontend dependency or memory growth for a worker. Keep existing service-level objectives and budgets as the source of truth.
Record natural variance. If repeated baseline runs vary more than the observed difference, the test cannot support a regression finding. Improve the harness or report the result as inconclusive instead of assigning false precision.
Preserve raw measurements and profiler output with the review. Aggregated scores alone can hide one expensive route, query, or interaction.
Review the changed execution path
Trace the request through the changed code to the repeated queries. A query inside an item loop is a credible risk, but profiling should establish whether it runs for the chosen workload. If batching removes the extra queries, repeat both cold and warm runs and verify that missing-item and authorization behavior remain correct.
Factory’s local code review supports custom instructions for performance regressions and unnecessary re-renders. Give the review concrete repository context, including the hot path, budget, benchmark command, and known exceptions. A generic request to “check performance” produces weaker evidence than a named workload and threshold.
Keep deterministic tools in the loop. Bundle analyzers, profilers, query planners, load tests, and browser measurement tools produce artifacts that another reviewer can inspect. The agent can connect those results to the diff and propose a focused fix.
Make the finding reproducible
A useful performance finding names the affected input, changed metric, comparison commit, environment, and command. It also points to the code path that explains the result. Screenshots without configuration or a single timing from a developer laptop do not provide enough evidence for a merge decision.
Run correctness tests after any optimization. Caching, batching, and deferred work can improve a benchmark while changing freshness or failure behavior. Preserve the original acceptance criteria and add a regression check where the repository can run it consistently.
Automated review in CI can apply the same instructions to every pull request through Factory’s code review workflow. Keep noisy benchmarks advisory until their variance is understood. Promote stable, decision-relevant measurements to required checks.
