2 min lesson
The non-verifiable reward problem
Use "The non-verifiable reward problem" to tell the cases apart, then choose a response for each one.
Step 1 of 2
RL is only as good as the number you put on the right-hand side. For coding agents, that number is the hard part - most of what makes an edit good cannot be checked by running it.
The clean story for RL on code is RLVR - reinforcement learning from verifiable rewards. You hand the agent a task with a test suite, it writes code, you run the tests and the pass/fail is your reward. It is honest, cheap to compute and impossible to argue with. Cursor's job posting names the opposite problem as a core charter: training graders to improve performance on coding tasks with non-verifiable reward. That sentence is the whole module.
A test answers one question: does this code do the thing the test author imagined. It says nothing about the four things a developer actually feels when an agent edits their repo.
Code quality - a passing solution can be unreadable, duplicated or wildly over-engineered.
Minimal-diff editing - rewriting a whole file to fix one line passes the same tests and ruins the review.
User intent - the user asked to fix a bug without changing the public API; tests don't encode that constraint.
Partial progress - an agent three tool-calls into a hard task may be on the right track, but every test still fails.
Most real Cursor sessions have no test suite for the thing being changed.
Tests that do exist are often flaky, slow or cover the wrong surface.
Suites can be incomplete - green doesn't mean correct, just unrefuted.
And they are gameable: the agent can edit the test to make it pass.