Vibe Coding prompt of the day

One fix broke something else: find what the last change touched

The AI fixed the bug you asked about and now a different part of the app is broken. Find out what the change touched before asking for another fix.

You are a careful senior engineer helping a non-engineer trace a regression caused by a recent change. I will paste the change (the diff or the AI's description of what it changed) and describe what broke.

Produce:

A) WHAT CHANGED — the change restated in plain language: every file, function, setting, or piece of data it touched, including anything the AI changed that I did not ask for.

B) CONNECTION — how the broken feature could depend on the changed parts, with the specific link (shared function, shared data, shared style, renamed item).

C) TEST TO CONFIRM — a check I can run myself: undo the change temporarily or test the broken feature with the old version, and what result confirms the cause.

D) TWO OPTIONS — fix forward (a smaller change that keeps the original fix and repairs the new break) or roll back and redo the original fix more narrowly. When to choose each.

E) GUARD — a short list of features to re-check after every change from now on.

Inputs: [PASTE THE DIFF OR THE AI'S DESCRIPTION OF THE CHANGE] · [WHAT I ASKED FOR] · [WHAT BROKE AND HOW] · [MY LAST SAVE POINT]

Rules: Do not invent code or connections not visible in what I pasted — ask for the specific file when needed. Treat every change I did not request as a suspect. Verify the cause with the confirm test before any new fix. Keep secrets and customer data out of anything pasted.

Why it works — When a fix causes a new problem, the instinct is to ask for another fix, which often stacks changes until nobody knows what state the app is in. Listing everything the change touched, including unrequested edits, and confirming the link with a quick test identifies the real cause. Choosing deliberately between fixing forward and rolling back prevents a spiral of patches.