How to Optimize Code Performance With AI

Playbook

Most "optimization" is fiction. Someone feels the app is slow, asks an AI to "make this faster," the agent rewrites a loop, everyone nods, and the app is exactly as slow as before — because the loop was never the problem. Optimizing on vibes is how you spend an afternoon making clean code uglier for a zero-percent improvement. The discipline that actually works is short and unglamorous: measure, fix the top bottleneck, measure again to prove it. If you can't show a before number and an after number, you didn't optimize anything. You just changed some code.

Step 1: Measure first — always, no exceptions

Before you touch a single line, find out where the time actually goes. Human intuition about performance is famously wrong — the slow part is almost never where you'd guess. So profile a real, representative run: the actual slow page, the actual heavy job, with realistic data, not a toy example. A profiler tells you which functions eat the wall-clock time; a benchmark gives you a hard number for the operation you care about. Get that number written down. It's your baseline, and without it every claim that follows is unfalsifiable.

Hand the agent measurement, not a mandate to "speed things up":

• The profiler output or timing data from the real slow path.
• The specific number you want to improve — page load, request time, job duration.
• Realistic input, because performance on ten rows tells you nothing about ten thousand.

Step 2: Fix the single biggest bottleneck

Profiles are lopsided. Usually one thing — a query in a loop, an unindexed lookup, a redundant network call, a needless re-render — accounts for most of the time, and everything else is noise. Optimize that one thing and ignore the rest. This is where agents help most: point one at the specific hot function and ask it to explain why it's slow before proposing anything. A good answer names a mechanism — "this runs one database query per row, so 500 rows is 500 round-trips" — not a vague "we can make this more efficient." Resist the urge to let the agent optimize five things at once. If you change five things and it gets faster, you don't know which one worked, and you probably made four of them worse for nothing.

Step 3: Re-measure to prove it

Run the exact same profile or benchmark again, on the same input, and compare to your baseline. This is the whole point. Either the number moved or it didn't. If it dropped meaningfully, keep the change. If it didn't move, revert the change — you added complexity for no benefit, and unearned complexity is a cost, not a trophy. Make the agent show real before/after output, not a claim. "This should be faster" is not evidence; "the request went from 840ms to 120ms on the same input" is.

The copy-paste optimization prompt

Here's the prompt we hand an agent to keep it honest through the whole loop:

We have a performance problem. Follow this order and do not skip.

BASELINE
- Slow path: <the page / job / request>
- Current number: <e.g. 840ms, on this input: ...>
- Profiler output: <paste it>

STEP 1 — Identify the single biggest bottleneck from the
profile. Explain the exact mechanism (why it's slow). Do not
propose a fix yet.

STEP 2 — Propose the smallest change that targets ONLY that
bottleneck. No unrelated rewrites, no "while we're here."

STEP 3 — After the change, re-run the same benchmark on the
same input and paste the new number next to the old one.
If it didn't improve meaningfully, say so and revert.

Common wins the agent will find

Once you're measuring, the same culprits show up over and over: N+1 database queries (a query inside a loop), missing indexes on columns you filter by, work done inside a request that should be cached or moved to a background job, and re-computing something on every render instead of once. These are high-impact and low-risk precisely because you can prove each one with a before/after number. Chase these before you ever reach for exotic micro-optimizations, which usually buy milliseconds while making the code unreadable.

Two traps to avoid

First, don't optimize code that isn't hot. Making a function twice as fast is worthless if that function is 0.5% of runtime — you've spent effort and added risk for nothing measurable. The profile tells you what's worth touching. Second, watch correctness. A faster version that returns slightly different results isn't an optimization, it's a bug with good latency. After any performance change, run your tests to confirm behavior is identical. Speed that breaks correctness is the worst trade in software.

When to stop

Optimization has diminishing returns fast. Once the app is comfortably within your target — the page loads quickly, the job finishes in time — stop. Further tuning trades real readability for gains no user will feel. The measure-fix-measure loop is as valuable for telling you when you're done as for telling you what to fix. The goal was never "the fastest possible code"; it was "fast enough, proven, without wrecking the codebase."

Optimizing with AI works exactly when you refuse to trust it and insist on numbers. Measure, fix the one real bottleneck, re-measure, keep only what the data justifies. If your bottleneck turns out to live in the database, writing SQL with AI without corrupting data covers the query side, and once you've made a fix, a fresh pass with CI/CD set up with AI can guard against a future change quietly re-slowing the hot path.