Verified against Cursor · 2026-07-23
Require Cursor's Agent mode to measure a slow path before it proposes a fix
A measure-diagnose-fix brief that requires the agent to instrument and get real numbers on a slow code path before proposing any optimization, so a confident-sounding fix can't ship for a bottleneck that was never actually located, and any temporary instrumentation gets removed before the change is called done.
The prompt
Ready to copy — highlighted parts are example details you can swap.
SYMPTOM The /api/dashboard/summary endpoint takes 2-4 seconds under normal load, and users notice the delay. Before proposing or making any change, locate the actual bottleneck. Do not optimize based on what looks slow by code inspection alone — plausible does not mean confirmed. SUSPECTED AREA — a starting point only, not a conclusion Probably the getMonthlyTotals database query, since it joins across three tables. MEASUREMENT METHOD console.time/console.timeEnd around suspect functions is fine for now; no APM tool wired up in dev. BASELINE TO BEAT Current p50 is 2.8s measured over 5 runs; target is under 500ms. STAGE 1 — MEASURE Add the minimal instrumentation needed to get real numbers for the suspected area and any adjacent code on the same request path — not just the one function you suspect, since the actual bottleneck is often a step upstream or downstream of it. Report actual measured timings or allocation counts, not estimates or descriptions of what "should" be slow. STAGE 2 — DIAGNOSE State which specific line or call is responsible for the majority of the measured time, backed directly by the Stage 1 numbers. If the suspected area was not actually the bottleneck, say so explicitly rather than quietly optimizing it anyway since you're already there. STAGE 3 — FIX Only now propose the smallest change that addresses the measured bottleneck specifically. State the expected improvement in the same units as the baseline, and describe exactly how you'd re-measure using the same instrumentation to confirm it actually closed the gap rather than just changing the code's shape. Remove any temporary instrumentation you added in Stage 1 before finishing, unless told explicitly to keep it as permanent monitoring.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
Agentic coding models are fluent at describing plausible-sounding performance fixes — memoization, batching, adding an index — by pattern-matching on code shape alone, without ever confirming that the spot they're fixing is where the time actually goes, which is the same failure mode as proposing a bug fix without reproducing the bug: the fix can be well-written and completely irrelevant to the actual symptom. Structuring the request as measure-diagnose-fix, with Stage 2 explicitly required to cite Stage 1's actual numbers rather than restate the hypothesis in different words, blocks the shortcut straight to a fix and forces the model to either confirm or falsify its own SUSPECTED_AREA hypothesis against real data instead of its own prior about what usually causes this kind of symptom. Instrumenting adjacent code on the same request path, not just the suspected function, matters because the actual bottleneck is very often one step away from where it appears to be — a slow-looking database query might be fast, while the serialization step immediately after it is what's actually consuming the time, and an agent told to "measure the suspected area" narrowly will confirm exactly the wrong hypothesis with real numbers and still land on the wrong fix. BASELINE_TARGET stated as a concrete number, rather than left as "make it faster," gives Stage 3 something falsifiable to compare against — without it, any change that plausibly touches the hot path can be described as an improvement without ever actually re-measuring to check. Requiring instrumentation removal at the end closes a real and common Agent-mode side effect: debug timers or logging left behind in the final diff because the agent's job description was "make it fast," and adding a console.time and never removing it technically doesn't conflict with that instruction on its own.
What you get back
STAGE 1 — MEASURE Instrumented getMonthlyTotals and the two other functions on this request path. - getMonthlyTotals: 340ms avg (5 runs) - getUserPreferences: 1,850ms avg (5 runs) — the actual majority contributor, not the suspected area - getRecentActivity: 210ms avg
STAGE 2 — DIAGNOSE The suspected area (getMonthlyTotals) is not the bottleneck — it's a minor contributor. getUserPreferences is doing a full table scan with no index on user_id, confirmed via the query plan.
STAGE 3 — FIX Adding an index on user_preferences(user_id) is the smallest change addressing the measured bottleneck. Expected: full scan to index lookup should bring that query under 50ms, taking the endpoint from a 2.8s baseline toward the 500ms target. Re-measuring with the same instrumentation after the index is added and the migration applied.
Instrumentation removed from all three functions.
Verified against
Cursor 2.2 · 2026-07-23
Changelog
- 2026-07-23 — Initial publish, verified against Cursor 2.2 Agent mode.
Need this built into your business?
If a prompt isn't enough — custom software, built and maintained for you — that's Scult's day job.
EXPLORE CUSTOM SOFTWARE
