Verified against Cursor · 2026-08-14
Give Cursor's Agent mode a performance budget to build inside, not a bottleneck to fix afterward
A brief for building a new feature against a stated performance budget from the start, requiring the agent to price each meaningful implementation decision against that budget as it goes, instead of optimizing only after something has already shipped and been measured as slow.
The prompt
Ready to copy — highlighted parts are example details you can swap.
FEATURE Add a live search-as-you-type dropdown to the product listing page, querying the catalog API on each keystroke after a short debounce. PERFORMANCE BUDGET FOR THIS FEATURE — a hard constraint on the implementation, not an afterthought to check once it's done Adds no more than 15KB gzipped to the page's JS bundle, and the dropdown's first result must render within 250ms of the debounce firing on a throttled 4G profile. WHAT COUNTS TOWARD THE BUDGET Bundle size measured via the existing webpack-bundle-analyzer build step, scoped to the product-listing route's chunk only. Render time measured via Chrome DevTools Performance panel, from debounce-fire to first result painted. BASELINE, BEFORE THIS FEATURE EXISTS Product-listing route chunk is currently 142KB gzipped; page interactive at 1.1s on the same throttled 4G profile. As you build this, do not treat the budget as something to verify only at the end. At each meaningful implementation decision — adding a dependency, choosing a data-fetching pattern, adding a re-render trigger — state briefly what it's expected to cost against the budget, using BUDGET_SCOPE as what actually counts. If a design choice would plausibly blow the budget, say so before writing it and propose the cheaper alternative, rather than building the expensive version first and discovering the number afterward when it's a bigger diff to undo. DEPENDENCY / LIBRARY RULE Do not add a new dependency to satisfy part of this feature without first checking its cost against the budget (bundle size, cold-start cost, whatever BUDGET_SCOPE names) — a library that solves the problem elegantly but alone consumes a third of the total budget is not a free win just because it works. WHEN DONE Measure the actual cost against BUDGET_SCOPE the same way CURRENT_BASELINE was measured, and report the number next to the budget, not just "should be fine." If it's over budget, do not report it as done with a caveat — identify the specific contributor responsible for the overage and either fix it now or state explicitly what would need to change and why that's out of scope for this pass.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
A "make it fast" instruction given only after a feature already exists puts the model in the position of reducing a cost it has already committed a specific shape to — a chosen data-fetching pattern, a re-render trigger, a dependency — which is measurably harder and more invasive than never incurring that cost in the first place, since by the time anyone measures it, the expensive choice is already threaded through several files and unwinding it is a second, larger diff on top of the first. Stating the budget upfront as a constraint on the choices being made, rather than a target to hit afterward, changes which question the model is actually answering at each step — from "does this work" to "does this work within this number" — and those two questions produce genuinely different code, not the same code that just happens to get measured differently later. The instruction to price a new dependency against the budget before adding it targets a specific and reliable blind spot: an agent evaluating whether a library is a good choice for a feature will confidently answer "does this solve the stated functional problem," but virtually never checks it against a performance budget unless explicitly asked to, because those are two different questions and only one of them is implied by "pick a library that does X." Requiring the final measurement to use the exact same method as CURRENT_BASELINE, rather than a fresh ad hoc check, matters because two numbers produced by two different measurement methodologies aren't actually comparable even though they look like they are — and a looser, less careful measurement taken at the end, under time pressure to call the feature done, is exactly where a real budget overage hides behind noise in how it was measured rather than getting caught.
What you get back
Dependency check: considered use-debounce (2KB gzipped) vs. hand-rolling a 15-line debounce hook (0KB) — hand-rolled version chosen, since the library's extra API surface isn't needed here and every KB counts against the 15KB ceiling.
Data-fetching: chose a single AbortController-cancelled fetch per keystroke over a library-based query cache, since a full query-cache dependency would have consumed roughly a third of the bundle budget on its own for a feature that only needs cancel-on-new-keystroke behavior.
Final measurement (same method as baseline): product-listing chunk now 153.4KB gzipped (+11.4KB, under the 15KB ceiling). First result paints at 210ms after debounce fire on throttled 4G (under the 250ms ceiling).
Verified against
Cursor 2.2 · 2026-08-14
Changelog
- 2026-08-14 — Initial publish, verified against Cursor 2.2 Agent mode building a bundle- and render-time-budgeted feature.
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
