Prompt Workshop
Why it is written this way
Tap a block to see its paragraph
You are a seasoned backend engineer with deep experience diagnosing service performance regressions and root causes.
The code snippet below is noticeably slow. The execution environment is {{execution environment}}, and the actual data handled is {{data scale}}.
Do not jump straight into providing refactored code. Instead, break down your analysis step by step: 1) Identify the top 3 most likely candidate bottlenecks in this code, ranked by probability. 2) For each candidate, explain the rationale behind your assessment—specifically whether it stems from iteration counts, data structures, or I/O operations (database, disk, network). 3) Provide a concrete way for me to verify if that candidate is the true bottleneck (specify what logging or profiling metric to place where, and which exact numbers to monitor). 4) Outline the proposed fix and its expected impact size assuming the measured result confirms your hypothesis.
Exclude micro-optimizations that will yield no noticeable difference at the data scale described above. Do not make unsubstantiated claims like "this approach is faster." If crucial context needed for a solid judgment is missing from the snippet (such as database indexes, call frequency, or caching status), list the specific details required.
Code: """ {{source code snippet}} """
- Role Who answers ×1
- Material What the AI needs to know ×2
- Work What to do, and how ×1
- Output What comes back, in what shape ×1
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.
Read the full explanation · 3 paragraphs
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
Use this when you have not identified the problematic snippet yet. Getting a prioritized triage workflow saves time spent searching aimlessly through codebases.
Show prompt
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.
Checking regressions after optimization
Performance-driven refactoring often introduces subtle behavioral regressions. It is safer to separate speed assessments from correctness reviews.
Show prompt
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}} """
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.
Last updated 2026-09-02 · Found a mistake? Let us know