One Composer turn drops a 30-file / 2000-line diff into the apply preview. Red and green everywhere; you scroll for two minutes and still can’t separate the core change from the “while I was here” cleanups. Tests pass and you still don’t trust it — because nobody can responsibly review 2000 lines of AI edits. The cause isn’t the model misbehaving; it’s a too-wide prompt plus Composer’s default to do it all in one shot.
Stopping the bleed isn’t reviewing harder. It’s rejecting and asking for a split.
Common causes
1. Task scope too big — should have been multiple Composer turns
“Refactor the auth system” guarantees a giant diff. The model dutifully redoes auth, sessions, API middleware, tests, error handling all at once.
How to judge: scan your prompt for “system,” “module,” “everything,” “all.”
2. Composer mixed feature work with drive-by cleanup
While implementing the feature, the model spots ugly naming or long functions and refactors them too. You can’t tell what’s essential vs aesthetic.
How to judge: diff contains the new feature plus renames / extract-function / reformatting.
3. Agent mode cascaded across files
The agent edits A, realizes it has to touch B, then C, then D — five tool calls later the file count tripled.
How to judge: expand the Composer message, look for a long chain of read_file / edit_file tool calls.
4. Rewrite-heavy model on a simple task
opus / gpt-5 in agent mode lean toward sweeping rewrites. A 100-line patch turns into an 800-line “modernization.”
How to judge: the model says “I rewrote it to be more modern” — danger signal.
5. No diff-size cap in .cursorrules
No default cap. If you don’t tell it “keep PRs ≤ 200 lines,” the model outputs the “complete proper solution” it learned in training.
How to judge: cat .cursorrules for “max diff” / “minimum” / “small.”
6. Asked for the “perfect solution” in one go
“Refactor this module using best practices” reads as “output a complete best-practice version” — i.e. a big diff.
How to judge: prompt contains “best practice,” “clean architecture,” “ideal.”
Before you start
- Identify the entry point: Composer / Cmd+K / chat. Cmd+K rarely produces huge diffs.
- Do not apply.
git diff > /tmp/big-diff.patchfirst to preserve evidence. - Note Cursor version, active model, whether agent mode + Max mode were on.
Info to collect
- The full prompt that triggered the diff.
git diff --statoutput.- Screenshot of the message’s tool-call chain (one call vs many).
- Active model + mode + Max mode state.
- Repo
.cursorrulescontent (any diff-size clauses?).
Shortest fix path
Ordered “split first, fix workflow second.”
Step 1: Reject — don’t apply
Hit “Reject” on the Composer message. Don’t let sunk-cost push you into apply — cleaning up a bad apply costs far more than rejecting and redoing.
Step 2: Have Composer split the plan itself
New prompt:
The previous proposal is too large to review. Do NOT change code yet.
Instead:
1. Split it into 3-5 smaller PRs.
2. For each PR list:
- title (one line)
- files touched
- estimated diff size (lines)
- what it accomplishes
- dependencies on other PRs in this list
3. Order them so the riskiest is last.You get a 5-PR plan you can evaluate.
Step 3: Execute one PR at a time
Now implement PR #1 only. Stay within the listed files. Do not start PR #2.Apply → run tests → commit → next. Each PR is independently revertable.
Step 4: Separate cleanup from behavior changes
If a PR still mixes both, ask for another split:
Split PR #2 again: one PR for "rename foo to bar" (mechanical), one for "add retry logic" (behavioral).
Apply the mechanical one first and review separately.Step 5: Codify a diff cap in .cursorrules
# .cursorrules
- Default to small, reviewable diffs (≤ 200 lines per response).
- When a task seems to require a larger change, STOP and propose a split plan instead.
- Never combine refactor / rename with behavioral changes in one diff.
- Always state estimated diff size before generating code.Step 6: If you really must apply a big diff
Some cases (e.g. generated output) can’t be split. Commit a clean baseline first, apply, then immediately commit with feat: bulk codegen output — DO NOT review line-by-line. Revert is then one git commit.
How to verify the fix
- Rerun the same prompt; confirm the model now proposes a split instead of dumping 2000 lines.
- Have a teammate try the same prompt to verify the rule is in team config.
- Each split PR should pass CI / review independently and be cleanly revertable.
If it still fails
- Reduce prompt to a single sentence + single file + single goal.
- Roll back the most recent
.cursorruleschange to verify rule is taking effect. - Search forum.cursor.com for “composer split PR”; include prompt + model + diff size.
- Grab View → Output → Cursor logs and post to Bug Reports.
Prevention
- Standardize prompt template: “State diff size estimate first; if > 200 lines, propose a split before coding.”
- Default to Edit mode or Cmd+K; only flip to Agent when multi-step is genuinely required.
- One feature branch per Composer task + commit after every small step.
- For known-large refactors use a CLI agent like Claude Code with explicit per-file scope.
- Team PR rule: AI-generated diffs > 300 lines aren’t accepted for review until split.