2 min lesson
The four named research bets
Match each case in "The four named research bets" to the signal and response that fit it.
Step 1 of 2
The charter resolves into four concrete research bets. You should be able to define each, say why it's hard and connect it to a Cursor product. Treat these as the four topics most likely to surface in a research-reasoning screen.
Agents reasoning and acting over many tool-calls per episode.
Hard because reward is sparse and delayed - credit assignment across dozens of steps.
A multi-file edit or a debugging session is one long episode, not one completion.
Good looks like: stable credit assignment that improves multi-step coding episodes.
More capability per FLOP: sample efficiency, scaling-law-aware data and parameter choices.
Hard because the obvious lever (more compute) is the expensive one you're trying to avoid.
Touches MoE training and low-precision kernels.
Good looks like: the same or better quality at lower training cost.
Scoring code where unit tests can't capture quality: style, partial credit, multi-file coherence.
Hard because a learned grader can be gamed - reward hacking is the constant threat.
Sits between RLVR's verifiable rewards and RLHF's preference models.
Good looks like: a grader that resists gaming and tracks real code quality.
Learning from live user interactions, not static offline batches.
Hard because of exploration, logging, off-policy correction and safety on production traffic.
Shipped in Cursor TabCursor's original autocomplete: multi-line, edit-aware suggestions you accept with the Tab key. Press Enter for the full definition.'s online-RL approach.
Good looks like: gains from real interactions without destabilizing the model.
Notice the through-line. Three of the four are about reward: where it comes from, how dense it is and whether it can be trusted. RL on coding agents is largely a reward-engineering problem and the JD's emphasis on graders and long horizons reflects that.
Learn more
Full explanation
Where RLVR runs out
RL with verifiable rewards (RLVR) works beautifully when a test suite or compiler can grade the output. Real coding work isn't fully verifiable: a passing test says nothing about whether the diff is the right design and many tasks have no clean test at all. That gap - between what a unit test can score and what a good engineer would accept - is exactly where the grader bet lives and why it's one of the role's hardest problems.
If asked which of these problems excites you most, pick one and go deep rather than gesturing at all four. Name a specific failure mode (say, reward hacking on a learned code-quality grader), describe how you'd detect it and what experiment would tell you whether your mitigation worked. Depth on one bet beats a tour of the menu.
QWhy are graders for non-verifiable rewards a distinct, hard bet rather than just “run more unit tests”?