MODULE 08 / 18 · PART 3 · PROVE & HARDEN
Performance & Optimization
Measure first, name the bottleneck, and quantify the gain against the risk.
THE SHORT ANSWER
What this module changes.
An optimization without a baseline is a guess with extra steps. Ask for the metric, the tool, the baseline, and the measured delta on realistic data.
Measure first. Any optimization prompt that does not start with a measurement is a guess with extra steps.
Performance in East Africa is often a data-cost and device problem, not a server problem. Bundle size, image weight, cold starts and third-party scripts matter on a 2 GB Android phone over a metered connection.
THE MODULE PROMPT LIBRARY
20 prompts for performance.
Copy any prompt, replace the [bracketed] slots with your own project context, and attach the files the agent needs. Use “Copy all prompts” when you want the full module in one place.
20 copy-ready prompts. Bracket text is a slot for your own context — replace it before you send the prompt.
Before optimizing, tell me how to measure this: [code path]. What metric, what tool, and what baseline do I need?
Why it worksWithout a baseline, you cannot tell an optimization from a regression.
Here is the profile: [profile]. Identify the top three contributors and rank them by achievable gain, not by absolute cost.
Why it worksOptimizes where the headroom is, not where the flame graph is tallest.
What is the theoretical floor for this operation? How far from it are we and what accounts for the gap?
Why it worksEstablishes whether there is anything left to win.
Analyze the algorithmic complexity of [function] and tell me at what input size it becomes the bottleneck.
Why it worksConnects complexity to the scale at which it actually matters.
Find the N+1 queries in this code: [code]. Show me the query log evidence and the fix.
Why it worksN+1 is the most common performance bug in application code.
What is this code doing that it does not need to do? Find the wasted work before optimizing the necessary work.
Why it worksRemoving work beats making work faster.
Propose the caching strategy for [operation]: what to cache, the key, the TTL, the invalidation, and the staleness the user will see.
Why it worksInvalidation is the hard part of caching; naming it up front prevents bugs.
Where is the memory going in this process? Identify the allocations that dominate and which are avoidable.
Why it worksAllocation churn is invisible in CPU profiles but shows up in latency.
Optimize this hot path and show me the before/after benchmark on realistic data, not a microbenchmark.
Why it worksRealistic data is the difference between a real win and a benchmark artifact.
What is the tail latency of this endpoint and what causes it? p99 matters more than the mean.
Why it worksAverages hide the user experience; tails are what users feel.
Is this optimization worth the complexity it adds? Quantify the gain and the maintenance cost.
Why it worksSome optimizations cost more than they save; this makes that explicit.
Identify the lock contention in this code: [code]. Propose the change that reduces the critical section.
Why it worksContention is a scaling wall that profiling under low load never reveals.
What is the cost of this serialization boundary? Compare the formats and the payload sizes.
Why it worksSerialization is often the hidden cost in service-to-service calls.
Propose the batching strategy for [operation] and tell me the latency/throughput trade-off it makes.
Why it worksBatching always trades latency for throughput; make the trade explicit.
Where should this computation happen: client, server, or database? Give me the cost of each placement.
Why it worksPlacement decisions dominate performance more than micro-optimizations.
Set up the performance regression test for [path] so this does not silently degrade later.
Why it worksPerformance that is not tested is performance that will be lost.
What is the cold-start cost of this service and what dominates it?
Why it worksCold start is a user-visible metric in serverless and autoscaled systems.
Review this query plan: [plan]. What is the database doing that we did not intend?
Why it worksQuery plans reveal the difference between what you wrote and what runs.
Give me the optimization options for [bottleneck] ranked by gain per unit of risk, with the risk named for each.
Why it worksPerformance work carries correctness risk; ranking by risk-adjusted gain is the right frame.
What would we have to change architecturally to remove this bottleneck entirely, and is it worth it now?
Why it worksDistinguishes incremental tuning from the structural fix.
PRACTICE · 20–30 MINUTES
Try it on a project you actually own.
Pick one slow page or endpoint. Measure p95 latency and payload size before asking for changes, then re-measure after.
- Pick one prompt from this module that matches a real task.
- Replace every bracketed slot with context from the feature you are working on now.
- Attach only the files the agent needs. Keep secrets, credentials and personal data out of the chat.
- Ask for the artifact — a spec, diff, test, runbook or decision note — and the evidence that it works.
- Record what changed and what remains unverified in the repository.
Want the same prompts across every module? Search the full prompt library or return to the course overview.