Why it is written this way
If you prompt an AI for code performance improvement with a vague "make this faster," it will focus on surface-level cosmetic edits. You will get list comprehensions and merged variables, while the true culprit—such as an N+1 database query inside a loop—gets overlooked. Premature edits without measurement lead to useless changes.
Setting the Role as an "engineer diagnosing root causes" fundamentally shifts the nature of the output. A generic code reviewer critiques variable naming and style conventions, whereas a root-cause investigator looks at where execution time is actually leaking. Who you ask dictates the opening paragraph of the response.
Structuring the instruction into four distinct Steps forms the core of this prompt. Forcing the AI to rank candidates requires clear rationale, and demanding verification steps separates facts from speculation. Step 3 in particular prevents "blindly trusting and deploying generated code" by prompting you to measure real numbers first. The same applies to slow database queries, where conventional AI advice skips verification entirely and jumps straight to speculative fixes.
Providing context variables is equally deliberate. Optimizing for 4 million rows presents entirely different challenges compared to 400 rows. The Constraint to exclude micro-optimizations filters out negligible tweaks for that specific scale, while asking to list missing context prevents the model from blindly recommending indexes without knowing if one already exists. Enclosing the code in """ ensures comments inside the snippet are not mistaken for prompt instructions.
Unfamiliar terms? See Aha AI: chain-of-thought, hallucination
Compared with a bad example
This code is too slow, please optimize it: for order in orders: ... (paste code)
Without understanding the data volume, the AI falls back on generic generalizations. It might convert lists to sets or rewrite loops as comprehensions, leaving the runtime virtually unchanged. Even if database calls within the loop are the actual issue, the lack of a structured rationale request buries that point among trivial suggestions. Furthermore, receiving rewritten code immediately leaves you with no plan on what metrics to measure.
Variations
Diagnosing slow UI/page loads
Users are reporting slow load times on a specific screen in our application. The execution environment is {{execution environment}}, and the underlying data is {{data scale}}. Before looking at code, categorize potential causes across the server, database, network, and browser layers, and provide a checklist of verification steps ordered from easiest to hardest to inspect.
Use this when you have not identified the problematic snippet yet. Getting a prioritized triage workflow saves time spent searching aimlessly through codebases.
Checking regressions after optimization
Below is code I refactored for performance reasons. Instead of evaluating whether it is faster, strictly assess whether the logic or runtime behavior might have changed.
Evaluate result ordering, duplicate handling, error behavior, and concurrency under high load, and provide test input examples that could expose edge-case bugs.
""" {{source code snippet}} """
Performance-driven refactoring often introduces subtle behavioral regressions. It is safer to separate speed assessments from correctness reviews.
Model notes
If you have actual runtime benchmark numbers or profiling traces, paste them alongside the code. Without quantitative data, the AI can only make educated guesses based on code structure.
Related prompts
Last updated 2026-09-02 · Found a mistake? Let us know