Can Cursor prove its own work?

Cursor is the most-deployed agent IDE in current use. It writes code, runs tests, observes failures, and iterates. The surface looks like MAPE-K. The question is whether it actually closes the loop, or whether the loop is open in a way that matters.

What Cursor does

• A user prompt becomes a multi-step agent run.
• The agent edits files, runs the project’s test suite, reads the output, and iterates.
• The agent can use tools: read_file, edit_file, terminal, web_search.
• The user sees a diff and either accepts or rejects.

Four practical questions

Condition	Pass?	Notes
1. Closed loop	partial	Cursor observes the test result, but the observation is in-process and not recorded anywhere durable. The “loop” is the agent’s scratch state, not a Ledger.
2. Declarative target	yes	The target is the diff. git diff after the agent run shows the full intent. The transcript is also available, but the diff is the source of truth.
3. Unattended in the ordinary case	no	Cursor requires a human at every turn. The “yolo mode” (auto-accept) shifts the human to the end, not out of the loop.
4. Ground truth	partial	The agent runs the user’s tests, but the user wrote the tests. The eval is whatever the user said it was. There is no separate Verdict plane; the Proposer (the agent) calls the tests and reads the result in the same process.

Where the workflow still needs help

Condition 3 is the loudest failure. The whole point of an agent IDE is that the human types a prompt and the IDE does the work. But the human is still in the loop, approving each change. The system is not unattended in the ordinary case; it is attended in every case.

Condition 4 is the more interesting failure. The “ground truth” is the test suite, but the test suite is not a separate authority. The agent that proposes the change also runs the eval and reads the result. There is no plane separation. A change that “passes” the tests passed because the agent’s proposal and the test runner are in the same process. The trust boundary lives in the user’s trust, not in the architecture.

A subtler version of the same problem: Cursor’s iteration is bounded by what fits in the context window and by the user’s patience. The “verdict” is the agent’s decision to stop iterating, which is the same agent that decided to keep iterating. KILL — the case that was passing and now fails — is not a verdict the agent emits. It is a fact the user discovers when they look at the diff.

What would make the workflow stronger

To satisfy condition 3, Cursor would need an unattended mode with a named exception class. The exception would be “tests do not exist” or “the user is in the file” or something specific. The current “yolo mode” does not have a named exception class; it has a duration limit.

To satisfy condition 4, Cursor would need to separate the Proposer from the Verifier. A change would land in a scratch workspace, an independent Scorer would run a held-out corpus against the change, and a PromotionToken would gate the merge. The current architecture has no such plane; the Proposer is also the Verifier.

See also

• closure-test — the rubric
• autonomic-software-engineering — the practice