1 min lesson
Pin behavior with golden examples
Name the key items in "Pin behavior with golden examples", then explain why each one matters.
Step 1 of 2
Pin behavior with golden examplesmaking prompts evaluable
A few in-context examples of a correct edit do more than paragraphs of instruction. They also make the workflow measurable: when behavior is pinned by concrete examples, you can build an eval set around those same cases and detect regressions.
- Show one or two golden examples: input code, the exact edit you’d accept and why.
- Keep examples close to the real task distribution, not toy snippets.
- Hold the temperature low for code edits so the same context yields stable output you can evaluate.
Dumping the whole repo doesn’t add safety; it dilutes attention and invites edits to files you never meant to touch.
If you can’t name why a file is in context, it shouldn’t be there.
Learn more
Full explanation
The cost of richer context
The cost of richer contextbudget it deliberately
More context usually means better edits, but every token added is latency and money on every call in the loop. Decide the context budget per workflow before production, the same way you’d decide a memory budget - not as an afterthought when the bill lands.
Learn more
Full explanation
Mind the context window: the 50-65% rule
Mind the context window: the 50-65% rulethe most quantified craft rule
Output quality drops steeply as the window fills - noticeably by 70-80%, badly before 90%. The working guidance converges on staying under roughly 60-65%, and several heavy users start a fresh agent at ~50%. The bottom-right fullness indicator shows how full the window is and its makeup: the system prompt should stay small and the conversation should dominate. If you’re already 50% full before you send a prompt, that’s a warning sign you’ve loaded too many tools or plugins.
Exceed the limit and Cursor compacts - it compresses prior context. The trap: a compacted run can behave like it never had that context at all, while you still pay for all the tokens.
Don’t ride the window to the edge. Start a fresh agent for any logically new feature, and when a long run nears full, ask the agent to summarize what it’s done and hand that small summary to a new agent - the codebase and commits, not the chat back-and-forth, are the real source of truth.
Vague (“what color is the badge?”) forces the agent to search the whole app. @-mentioning the exact file guarantees it lands in context instead of relying on semantic search - the model reads that file, finds the definition and returns the right hex code. Night-and-day efficiency and accuracy.
@ isn’t limited to files: link docs, and reference a past chat to inherit its summary (Cursor summarizes the prior transcript) without carrying all of that context forward.
The anti-pattern: “make the app better” on the biggest modelvague + expensive = a compounding cost loop
The canonical thing not to do is a vague prompt on the most expensive model. With no clear context the agent makes blind, random edits, burns tokens, then burns more reading and fixing the bad code it just wrote - a compounding cycle. Vague prompts cost more and lower quality; specific, file-referenced prompts cost less and produce better output.
“Make the app better.” - on a frontier reasoning model.
No surface, no change, no constraints.
Blind edits → read/fix → more tokens, on repeat.
“Under the shop page, add an in-stock filter next to the existing tag and sort controls.”
“Preserve the URL query params and update tests if needed.”
Names the surface, the exact change and the constraints.
“I’d start from the failing test and the two files it exercises, @-mention them so they’re guaranteed in context, attach the team’s rules file for conventions and add type defs only where the edit crosses an interface. I keep the window under ~60-65% - if quality is still short, I add context one artifact at a time and watch the eval, rather than dumping the package up front and triggering compaction.”