Composer 2 for Cursor teams

If Composer 2 made your drafts faster, the next thing to fix is how you judge them. Composer 2 is the model inside Cursor, Anysphere's AI code editor, that generates changes faster than most teams can review them. That speed is real, and it quietly moves the hard part of the work from writing code to deciding whether the code is right. An eval is just a known case with a known answer that you can run the model against again and again. The teams that get value from Composer 2 add a few of those and stop chasing acceptance rate.

Watch the metric that improves while quality drops

When drafts arrive faster, the easy numbers go up first. Lines changed, suggestions accepted, minutes saved: all of them climb, and none of them tell you whether the code is correct.

Acceptance rate is the most tempting of these and the most misleading. It is the easiest number to push up and the one least connected to whether the change actually works, so a faster model inflates it for free. When a measure becomes the target, it stops measuring anything useful.

The fix is to judge Composer 2 against work your team already understands, not against its own speed.

Build an eval set your team can name the answer to

A model is only measurable against work where someone can state the right outcome ahead of time. Start with cases like these:

• a refactor that should not change behavior,
• a test expansion that should catch one known edge case,
• a copy edit that has to preserve a product claim,
• a small API change that has to keep validation intact.

Keep the set in the repo as plain markdown. It needs no new tooling to be useful:

# Composer eval set

Case: checkout copy cleanup
- Input branch: `eval/checkout-copy-before`
- Allowed files: `apps/site/src/app/checkout/**`
- Expected result: copy is shorter; payment behavior unchanged
- Required proof: `pnpm test checkout`
- Reviewer question: can a new reviewer explain the diff without chat replay?

Case: API validation hardening
- Input branch: `eval/careers-api-before`
- Allowed files: `apps/site/src/app/api/careers/**`
- Expected result: stricter validation; no new external destination
- Required proof: `pnpm test api-careers`
- Reviewer question: is every rejected input named in the test?

Now Composer has a repeatable target, and the checking happens inside the workflow your engineers already live in. It pairs well with the subagents and skills topic hub once those drafts start running as bounded agents.

Gate accepted changes before widening Composer use

Before you point Composer 2 at larger work, run every accepted change through four quick checks. The goal is not to slow routine edits down, it is to make sure "accepted" and "verified" mean the same thing.

The metric that counts is not "accepted suggestion." It is "accepted suggestion with sufficient evidence." The .mdc guidance lives under Cursor Rules, and the agent surface under Cursor Agent.

Keep a one-line review note after every Composer PR

After each Composer-assisted PR, the reviewer writes one short note. It takes a sentence and it compounds.

Composer review note:
- Case matched: checkout copy cleanup
- Human edits after Composer: changed error-state wording, added missing test
- Trust change: use again for copy-only checkout changes; do not use yet for payment behavior

Those notes do two jobs. They record where the model can be trusted and where it cannot yet, and they show whether faster generation is cutting review load or just hiding it. Patterns that keep showing up across the notes are good candidates for Cursor Skills. Watch the changelog for model default changes, and keep connector boundaries aligned with the Model Context Protocol specification.

Common questions

• How should a team evaluate Composer 2?

  Judge it against known cases, not against its own velocity. Pick a refactor that should not change behavior, a test that should catch one named edge case, and a copy edit that has to preserve a claim. Keep the eval set in the repo with allowed files, a required proof command, and one reviewer question per case so anyone can rerun it.

• What metrics go wrong with faster code generation?

  Lines changed, suggestions accepted, and minutes saved can all improve while review quality drops, because acceptance rate is the easiest number to inflate. Replace it with one metric: accepted suggestion with sufficient evidence. That means scope match, rule match, a passing proof command, and a PR body that explains intent.

• What is an acceptance gate for generated changes?

  It is four checks before merge: the diff stays inside allowed paths, the relevant .mdc rule is followed, the required command passes after edits, and the PR body explains intent and limits. The gate separates plausible output from verified output and keeps team standards visible without slowing routine work down.

• Do Composer review notes actually pay off?

  Yes, because they record real trust decisions instead of impressions: which case matched, what the human edited afterward, and where the model is not trusted yet. Over a quarter, those notes show whether faster generation is reducing review load or hiding it, and they double as onboarding material for the next reviewer.

Where to go next

Pick three eval cases before you change any team default; if nobody can name the pass condition, you are not ready to measure Composer 2 yet. Our training builds that eval habit against your own repo in a day.