2 min lesson
Carry honest critiques - and frame them as the work
Make the call in this situation: "You're asked what frustrates you about Cursor. Draft a 30-second answer that proves real usage and reasons like someone on the inference team." Explain what supports it.
Step 1 of 2
Carry honest critiques - and frame them as the work
- A latency complaint you can locate: which surface, roughly what budget it blew and why that's a routing or batching issue rather than “the model is slow.”
- A reliability complaint: a time a provider hiccup leaked through as a visible stall and how health-based routing or hedging would have hidden it.
- A cost-aware observation: where you'd suspect the system over-spends - say, hedging everything instead of only tail-risk requests.
- A quality observation tied to model choice: a task where one model clearly fit better, which connects straight to routing policy.
Show that you've customized the tool. Mention your .cursor/rules and the model-selection preferences you've settled on, with reasons - a cheaper model for boilerplate, a stronger one for gnarly refactors. That's exactly the routing instinct the role exercises.
Turn every critique into a hypothesis you'd test, not a gripe. “Tab felt slow on big files” is a complaint. “Tab felt slow on big files, which I'd guess is context-assembly or prefill cost scaling with file size - I'd want to see the p95 split by file size before blaming the provider” is a candidate already reasoning like the team.
If you haven't used it for real, start now. Two to four weeks of daily, genuine work is the minimum to have opinions that survive a follow-up question. Cramming a demo the night before produces exactly the generic praise that gets screened out.