AI Performance Optimization Workflow
Speed up code that works but drags — find the actual hot path instead of guessing, understand why it's slow, optimize it, and prove with tests that you changed the speed and nothing else.
The problem
Optimizing on instinct is how you spend a day speeding up a function that wasn't the problem. Performance work has a discipline: find where the time actually goes before touching anything, understand why that spot is slow, change it, and prove you changed only the speed. The trap sits on both ends — guessing at the bottleneck, and guessing that the optimization didn't quietly change a result. This workflow replaces both guesses with evidence.
Recommended workflow
Each step uses an existing NewPrompt tool, pre-filled by a matching resource. Open the resource to read it, or jump straight into the tool with the inputs ready.
-
Find the real bottleneck
Before optimizing, locate where the time actually goes — the hot loop, the N+1 query, the redundant recompute. Optimizing the wrong spot is the most common way performance work wastes a day.
Goal The actual hot path, identified with evidence, not a hunch.
Open this step in Debugging Prompt GeneratorResource Debug Performance Problems -
Understand why it's slow
Get a clear read of what the slow code does and why it's expensive, so the optimization addresses the cause — an algorithm, a data structure, a repeated call — instead of papering over the symptom.
Goal A grounded understanding of the cause of the slowness.
Open this step in Code Explanation Prompt -
Optimize the hot path
Make the targeted change — a better algorithm, caching, fewer passes — keeping behavior identical. Faster code that returns a different answer is a regression, not an optimization.
Goal A faster implementation with behavior preserved.
Open this step in Refactor Prompt Builder -
Prove speed changed and behavior didn't
Back the change with tests that confirm the same inputs still produce the same outputs, so the win is real speed and not a silently altered result.
Goal Tests proving the optimization preserved behavior.
Open this step in Test Case Prompt Generator
Expected outcome
The real bottleneck is found, understood, and optimized, with tests confirming the behavior is unchanged — a measurable speedup you can trust, instead of a faster function that quietly returns something different.
Best for
- Speeding up correct-but-slow code
- Fixing a performance bottleneck without changing behavior
- Optimizing a hot path you've already located
Not for
- Fixing a bug — the code here works, it's just slow; use the AI Debugging Workflow
- Restructuring for readability with no speed goal — use the AI Refactoring Workflow
- Tuning database queries specifically — that's a SQL-focused job
FAQ
How is this different from the AI Debugging Workflow?
Debugging fixes code that produces the wrong result. Here the code is correct — it's just too slow. The goal is speed with identical behavior, not a corrected output. Different problem, different success condition.
How is this different from the AI Refactoring Workflow?
Refactoring restructures for readability and maintainability and is happy if behavior and performance are unchanged. This explicitly targets performance — the whole point is to make it faster. A refactor that doesn't speed anything up still succeeds; this one doesn't.
Why find the bottleneck before optimizing?
Because most of the time concentrates in a small fraction of the code, and optimizing anywhere else is wasted effort that adds complexity for no gain. Locating the hot path first is what makes the optimization worth doing.
Part of these blueprints
Complete build journeys that include this workflow as a stage.
Where to go next
Related workflows