Cursor: Sometimes the best suggestion is none.
Cursor trained its code suggestions to show up less often and be right more often. Explore why an assistant that knows when to stay quiet can feel more helpful than one that always has an answer.
See the idea in one picture ↓- suggestions shown
- −21%
- accept rate
- +28%
- requests a day
- 400M+
Figures as reported by the company.
Independent educational analysis. Scenarios, people, numbers and illustrations on this page are original PMcademy practice material, not company research results or an endorsement.
Protect the flow, not only the feature.
“Every wrong suggestion pulls me out of the problem.”
- Help that reads his intent
- Quiet when unsure
- Noisy guesses
- Learning to ignore the feature
Read the analysis
Our fictional learner, Tomás, is a developer in the middle of a tricky change. He is holding the whole problem in his head. A suggestion that guesses right feels like the tool read his mind. One that guesses wrong pulls him out of the problem, and after a few of those he starts ignoring all of them. Ask what state your users are in when your product speaks up, and what breaking that state costs them.
Every suggestion costs attention.
A guess at every keystroke
A suggestion only when it is likely to help
Read the analysis
Imagine your product offers help while someone works: a suggested reply, a next step, a completed sentence. Each suggestion asks the person to stop, read and decide. A good one saves time. A wrong one costs the same attention and gives nothing back. The product question is not only how good the best suggestions are. It is what each wrong one costs, and how often you are willing to interrupt.
When to suggest, and when to stay quiet
- 1Every guess shown
Showing every prediction means many wrong ones, and each one interrupts.
- 2Score each choice
Reward accepted suggestions, penalise rejected ones, and stay quiet below a confidence line.
- 3Learn and ship
Accept and reject signals train new versions, rolled out several times a day.
Animated illustration. Names, numbers and people are fictional teaching material.
Teach the system when to stay quiet.
Illustrative data and simplified behaviour. This model does not represent a live company system or measured company results.
Read the analysis
Use the model below to compare three set-ups. In the first, every guess is shown. In the second, a separate filter hides the weakest guesses. In the third, the system itself learns from what people accept and reject, and only speaks when it expects to be useful. Cursor describes the last approach: a reward for accepted suggestions, a penalty for rejected ones and nothing for staying quiet. The counts in the model are illustrative.
Learn from the answer people give you.
Cursor reports fewer suggestions and a higher accept rate than its previous model.
The absolute accept rate or whether developers ship faster.
- Accept rate with suggestion volume
- Time to finish a task
- Feature switched off
Read the analysis
Every suggestion produces a signal: accepted, rejected or ignored. Cursor says it uses these signals to train new versions and roll them out several times a day, and reports fewer suggestions with a higher accept rate than its previous model. That is the company’s own comparison, with no absolute baseline published. In your project, check that the signal means what you think. An ignored suggestion may be wrong, or the person may simply be busy.
Fewer chances to help, more trust when you do.
- Fewer interruptions
- More trust per suggestion
- Better flow
- Some good ideas never shown
- Accept rate can hide silence
- Needs constant retraining
Read the analysis
Showing fewer suggestions means some good ones are never seen. Showing more means more interruptions and a lower chance that each one is right. Neither number is the goal on its own. A rising accept rate can hide a product that has gone too quiet, and a rising suggestion count can hide one that has become noise. Decide which pair of numbers you will watch together, and what would make you change the balance.
When should the assistant speak up?
Your fictional team is adding suggested replies to a customer support inbox. Agents handle dozens of conversations an hour. You can show a suggestion on every message, show one only when the system is confident, or show one only when the agent asks. Choose a default, name the two numbers you will watch together, and explain what result would make you change it.
Choose a next move
Leave with an interruption budget.
Your artifact
Write an interruption budget: each suggestion moment, what a right and wrong suggestion are worth, the confidence needed to speak up, and the paired metrics you will watch.
Critique my project artifact using only the evidence I provide. Write an interruption budget: each suggestion moment, what a right and wrong suggestion are worth, the confidence needed to speak up, and the paired metrics you will watch. Separate observed facts, assumptions, proposed tests and missing evidence. Identify a failure mode and a cheap check. Do not invent company results or user research. Ask for my artifact before starting.
Read the analysis
List every moment your product interrupts or suggests. For each, estimate what a right answer saves and what a wrong one costs. Set the confidence you need before speaking up, the signals you will collect from each response, and the paired metrics that stop you optimising one at the expense of the other. Add one cheap test that would show whether people trust the suggestions more over time.