Verified against Cursor · 2026-07-21
Get Cursor's agent to measure a slow path instead of guessing at a fix
A measure-diagnose-fix brief that requires Cursor's 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.
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 inspection alone. 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. 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. Report actual measured timings or allocation counts, not estimates. STAGE 2 — DIAGNOSE State which specific line or call is responsible for the majority of the time, backed by the Stage 1 numbers. If the suspected area was not actually the bottleneck, say so explicitly. STAGE 3 — FIX Only now propose the smallest change that addresses the measured bottleneck. State the expected improvement and how you'd re-measure to confirm it. Remove any temporary instrumentation you added in Stage 1 before finishing, unless told to keep it.
Customize the highlighted detailsoptional — the prompt above already works
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. It's the same failure mode as proposing a bug fix without reproducing the bug: the fix can be well-written and completely irrelevant. Structuring the request as measure-diagnose-fix, with Stage 2 explicitly required to cite Stage 1's actual numbers rather than restate the hypothesis, blocks the shortcut straight to a fix and forces the model to either confirm or falsify its own SUSPECTED_AREA hypothesis against real data. 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.
What you get back
STAGE 1 — MEASURE Instrumented getMonthlyTotals and the two other queries on this request path. - getMonthlyTotals: 340ms avg (5 runs) - getUserPreferences: 1,850ms avg (5 runs) — this is 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 improvement: full scan to index lookup should bring that query under 50ms. Re-measure with the same instrumentation after the index is added and migration applied. Instrumentation removed from all three functions.
Verified against
Cursor 2.1 · 2026-07-21
Changelog
- 2026-07-21 — Initial publish, verified against Cursor 2.1 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
