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.
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.
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.
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.
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.
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.
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.
The debugging workflow fixes code that returns the wrong result; this one speeds up code that's already correct but slow. Its success condition is a measurable speedup with identical behavior, proven by step 4's regression tests. Debugging changes the output on purpose; this workflow must never change it.
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.
You end with the real bottleneck located with evidence, a grounded read of why it's slow, a faster implementation of that hot path, and tests proving the same inputs still return the same outputs. NewPrompt supplies the prompts and step order; you run them and own the measured result.
Work the four steps in order in your own AI tool: use the debugging-prompt-generator to find the hot path, the code-explanation-prompt to understand why it's slow, the refactor-prompt-builder to optimize it, then the test-case-prompt-generator to verify behavior. NewPrompt hands you the prompts; you run each one and review the code.
Bring code that already works and a concrete sign it's too slow — a lagging endpoint, a heavy loop, a slow page. Step 1 finds where the time actually goes, so you don't need to know the bottleneck yet, but you do need the correct-but-slow code in front of you.
Step 4 backs the change with tests confirming the same inputs still produce the same outputs, so the win is real speed and not a silently altered result. AI drafts the tests and helps you compare — but you run them and make the final call that behavior held.
Complete build journeys that include this workflow as a stage.
The full path to taming an inherited codebase — understand it, document its architecture, pin its behavior with tests, then refactor, modernize, review, speed up, and ship it without breaking what works.
Ask AI to "review this for performance" and you get a tidy list of smells with no idea which one production actually spends time on. Here is how to review code for performance with AI so each finding is tied to a workload, ranked by evidence, and marked with the measurement that would confirm it.
Build a test suite that fails for real reasons, not green decoration — coverage across unit, integration, and edge cases, then a review for the gaps.
The order that actually finds bugs instead of guessing at them — so you end with a verified fix, not a plausible one that quietly returns next week.
Restructure code you own without breaking it — change only what's worth changing, and prove with tests and a diff that behavior held.