When to stop accepting AI diffs

What a “diff” is

A diff is the view of what changed: lines added and removed. In editors like Cursor, accepting a diff applies the AI’s edit to your files. In chat builders, the equivalent is “apply this huge update” without reading it.

Speed is fine. Speed without reading is how demos become incidents.

Red flags — stop and reset

Pause accepting changes if:

• You cannot explain the change in one or two sentences
• Login, payment, or permission code changed “while fixing a button colour”
• Tests were deleted or skipped to force a green result
• New dependencies appeared with no reason you asked for
• The patch touches dozens of files for a one-line bug
• You feel embarrassed to show the change to a careful friend

Why models do this

LLMs optimise for sounding complete. They may “helpfully” rewrite architecture, rename half the project, or paper over errors. That is not malice — it is how the tools are trained. Your job is product ownership: decide what stays.

Recovery playbook

Do this in order:

• Stop. Do not Accept All again.
• Revert to last known good (Git commit, builder history, or undo).
• Write the invariant in plain English: e.g. “Users only see their own invoices.”
• Re-prompt for a thin slice: one file or one behaviour.
• Read the diff. If you still do not understand, ask: “Explain this change for a beginner; do not modify code.”
• Only then apply, run the app, and try to break the path you care about.

Rules of thumb that keep you safe

Small commits or save points often. Future you cannot un-scramble a two-hour mystery blob.

Security-sensitive areas (auth, payments, database rules) require slower prompts and stricter review — even if the UI looks fine.

If you are a beginner, it is okay to say: “I do not understand this; simplify.” That is skill, not failure.

When to get a human

If the app will hold real customer data or money and you are lost in the diffs, pause launch. A short paid review from a developer you trust is cheaper than a breach or a refund storm.

Related

First production checklist and Production hardening for the go-live gate. How to test prompts for a lighter practice loop before stakes are high.