Ask an AI coding agent to implement something twice, and you'll usually get two different answers. Most workflows hide this: you run the agent once, read the diff, and either accept it or ask for changes. You never see what the alternative attempt would have looked like, because there wasn't one.
Cursor 3 makes running more than one attempt at the same task a built-in option rather than something you'd have to script yourself. Its changelog, published in April 2026, describes two new editor commands. /worktree creates a separate git worktree so an agent's changes happen in isolation from your main working copy. /best-of-n runs the same task in parallel across multiple models, each in its own isolated worktree, and then compares the outcomes.
That second command is the interesting one for how you work, because it turns "which attempt is better" from a question you'd have to engineer around into a question the tool sets up for you.
What a worktree buys you
A git worktree is a second working copy of the same repository, checked out to its own directory, sharing the same underlying history. Changes made in one worktree don't touch the files in another until something is explicitly merged.
That matters for AI-assisted work for a reason this site has covered before: an agent can change code you didn't ask it to touch. Isolating an attempt in its own worktree means any unrequested edits stay contained to that copy. If the attempt is wrong, or the agent has wandered into files it had no business touching, you haven't yet put any of that near your main branch. You can inspect it, discard it, or merge it - deliberately, and only after checking.
What /best-of-n actually gives you
Cursor's changelog says /best-of-n runs the same task in parallel across multiple models, each in its own isolated worktree, and then compares outcomes. It doesn't say how many models, how the comparison is presented, or what state each attempt is left in when the comparison happens - the changelog entry is a one-line feature description, not a walkthrough of the interface. Anyone deciding whether to build a comparison step around this should try it and see what the comparison view actually shows before assuming more than that.
What the description does establish, reliably, is the structure: several models attempt the same task, each in a worktree that keeps its changes separate from the others and from your main branch. That structure is the useful part, independent of exactly how Cursor happens to present the results in any given version.
Comparing attempts without letting confidence decide for you
Having several attempts sitting in isolation doesn't tell you which one is right. It just means you now have more than one candidate to check, instead of one candidate you either accept or don't. The evaluation still has to be yours.
This is the same discipline this site has argued for elsewhere: an agent's own report that something works is not evidence that it does (see "Production Ready" Is Not Evidence), and code should be checked against defined behaviour rather than read for how plausible it looks (see How to Test Code You Didn't Write). Multiple attempts raise the stakes on this rather than lowering them, because a more fluent or more confident-sounding attempt is not automatically the more correct one. If you're comparing outputs from different models, you're comparing different writing styles as much as different implementations, and it's easy to mistake the more polished explanation for the more correct one.
A workable way to compare attempts before merging any of them:
- Define the behaviour before you run anything, not while you're looking at results. If you don't have a written statement of what the change should do, you'll end up judging attempts against whatever impression each one gives, which is exactly the confidence-over-correctness trap. The site's Behaviour Definition Template is built for this.
- Test each attempt against that same behaviour, separately, in its own worktree. Because the attempts are isolated, you can run the same checks against each without one attempt's state contaminating another's.
- Record what you found for each attempt, not just which one you picked. If two attempts both pass your checks but implement the behaviour differently, the difference might matter later even if it doesn't matter today.
- Merge the attempt that passed, not the one that read best. If none of them fully pass, that's information too - it may mean the behaviour, clarifications or constraints given to the agents weren't specific enough, not that one of the attempts just needs a nudge.
Where this fits into a controlled workflow
Running several attempts at once doesn't remove the need for the earlier decisions that shape any AI-assisted change: what the change is for, what it should do, what's out of scope, what mustn't break. If those aren't settled before the attempts run, /best-of-n just gives you several plausible-looking implementations of an underspecified task, which is a harder thing to judge between, not an easier one.
Treated as one step within a repeatable build-test-correct workflow, though, parallel isolated attempts are a genuine improvement on the single-shot default: you get more than one candidate to test against the same behaviour, and none of them can quietly become your working code until you've checked it and chosen it.