Optimizing performance with AI assistance usually fails because the prompts are vague, asking for "optimizations" without context and constraints. These ready-to-use templates force the LLM to analyze specific bottlenecks, propose measurable fixes, and respect your architectural boundaries. I've tested these against Claude 3.5 Sonnet, GPT-4o, and DeepSeek-V3, and they consistently produce actionable code instead of generic advice.
Why Generic Prompts Fail Here
The classic "optimize this function" prompt returns a mix of micro-optimizations (like changing let to const) and rewrites that break your existing API. The failure mode is predictable: LLMs optimize for readability, not runtime. They don't know your hot paths, your data volumes, or your latency budgets.
Generic prompts also fail because they lack a baseline. Without profiling data or a specific metric, the model guesses what's slow. The templates below solve this by forcing you to provide three things: the exact code, the measured bottleneck, and the constraint (memory, latency, or throughput) that matters most.
Template 1: The Profiler's First Pass
This template works best when you've already identified a slow function via Chrome DevTools, Py-spy, or your APM tool. It's designed for single-function optimization where you know the input shape but not the algorithmic bottleneck.
You are a performance engineer. Analyze the following function for performance bottlenecks.
Function:
[PASTE FUNCTION CODE HERE]
Language: [e.g., TypeScript, Python]
Input size: [e.g., 10k records, 1MB JSON, 100 concurrent requests]
Current execution time: [e.g., 250ms]
Target execution time: [e.g., under 100ms]
Constraint: [e.g., must not increase memory by more than 20%, must not change function signature]
Provide:
1. The top 3 algorithmic or I/O bottlenecks, ordered by impact.
2. A rewritten version of the function that addresses the #1 bottleneck.
3. The expected performance gain (as a percentage or time estimate) and why.
4. One trade-off you made (e.g., memory vs. speed) and when it would break.
Do not suggest caching unless the function is called repeatedly with identical inputs.
Do not change the function's external behavior.
Placeholders explained: [PASTE FUNCTION CODE HERE] is your actual code — don't truncate it. [Input size] matters because an O(n²) fix for 10 items is pointless. [Current execution time] grounds the model in reality; without it, you'll get "this is already fine" or a rewrite that's slower.
Template 2: The Batch Refactor
This is for when you need to optimize a module or a data pipeline — not a single function. It's structured to prevent the LLM from rewriting everything from scratch, which is the most common failure with larger codebases.
You are a systems architect. Optimize the following data processing pipeline for throughput.
Code:
[PASTE FILE OR MODULE CODE HERE]
Current throughput: [e.g., 500 items/second]
Target throughput: [e.g., 2000 items/second]
Hardware: [e.g., 2 vCPU, 4GB RAM, Node.js 20]
Data characteristics: [e.g., 90% of records are under 1KB, 10% are up to 10MB]
Rules:
- Keep the public API (function names, exports) identical.
- You may introduce concurrency, batching, or streaming — but only if you explain when it fails.
- Do not use external libraries unless they are already in package.json.
- If the bottleneck is I/O, show the exact async pattern to use.
Output:
1. A diagnosis of the current bottleneck (CPU-bound, I/O-bound, or memory-bound).
2. A rewritten version of the pipeline with parallelization or batching.
3. A note on the failure mode: at what input size does your optimization degrade?
Ask me for clarification if the data flow is ambiguous — do not guess.
This template shines with Claude and GPT-4 because they handle multi-step reasoning well. The key difference from Template 1: you're asking for architectural changes, not micro-fixes. The "ask me for clarification" line prevents the model from inventing assumptions about your data flow.
Template 3: The Constrained Edge Case
This is for the hard cases: real-time systems, memory-constrained environments, or code where the naive optimization is wrong. Use this when you've already tried a basic prompt and got a "solution" that broke under load.
You are optimizing code for a hard real-time system. The following code has a strict latency budget.
Code:
[PASTE CODE HERE]
Latency budget: [e.g., 10ms p99]
Current p99: [e.g., 45ms]
Environment: [e.g., single-threaded event loop, no GC pauses allowed, 64MB heap limit]
Hard constraints:
- No dynamic allocations after startup (pre-allocate buffers).
- No `async/await` in the hot path — use callbacks or worker threads only.
- The solution must be deterministic — no Math.random(), no Date.now() for logic.
Provide:
1. The main source of latency variance (not just average — variance).
2. A rewritten version that meets the budget, or state clearly if it's impossible.
3. The exact trade-off (e.g., CPU cache misses vs. allocation overhead).
4. A test harness snippet to verify the p99 improvement.
If the constraints are contradictory, say so immediately and propose which one to relax.
This template is aggressive on purpose. The hard constraints force the LLM to think about memory layout, event loop blocking, and allocation behavior — things generic prompts never touch. It works best with DeepSeek-V3 or Gemini 1.5 Pro, which handle constraint-heavy reasoning well, but it also exposes GPT-4's tendency to hallucinate "optimizations" that don't compile.
How to Adapt These for Your Own Codebase
First, always paste the exact code, not a simplified version. LLMs optimize what they see — if you give them a toy version, you get a toy optimization. Second, replace the placeholder metrics with real numbers from your profiler. A model that knows your p99 is 45ms will make different decisions than one guessing.
Third, add your team's specific rules to the constraint line. If you use a linter that bans any, say so. If you're on a memory-constrained Lambda, write that instead of "4GB RAM." The templates are skeletons — flesh them out with your actual environment.
Finally, treat the output as a proposal, not a merge-ready PR. I've seen these templates produce genuinely clever solutions, but I've also seen them suggest worker threads for a 5ms task. Always benchmark the result against your baseline before committing.
Do These Prompts Work With Any LLM?
No. Claude 3.5 Sonnet and GPT-4o handle Template 1 and 2 well because they excel at single-function analysis and structured output. Template 3 requires stronger constraint-following — DeepSeek-V3 and Gemini 1.5 Pro are more reliable there. You'll also notice that smaller models (e.g., GPT-3.5) will ignore your constraints and return generic advice; don't waste tokens on them for performance work. For the best results, run the same prompt across Claude and GPT-4, then merge the best parts of each answer.
The one adjustment that improves these prompts the most: replace every placeholder with a concrete number before you paste the prompt — even if you have to guess. "About 200ms" beats "slow", and "roughly 10k records" beats "a lot of data". Specificity is the only thing separating a useful optimization from a rewrite of your code that doesn't compile.