The previous lesson left you with a reproduction another person can run: steps, request IDs, success and failure logs, scope, and unknowns. Now comes the moment most AI-assisted debugging goes wrong. The builder pastes the symptom into a chat and approves whatever patch comes back. Three patches later the original bug is hidden under three new ones, and nobody can say what changed or why.

"It broke, fix it" versus a disciplined request

Compare the two prompts:

This gives AI no reproduction, no logs, no contract, and full permission to rewrite. It will guess — often by widening permissions, adding retries, or reformatting code — and the guess will look confident.

The second prompt does four things the first does not. It freezes editing so investigation cannot silently become a rewrite. It supplies the reproduction and logs so AI reasons from your evidence. It points at the contract so AI checks behavior against the agreement, not against its own assumptions. And it demands a stopping point — a table you approve — before any change is proposed.

Keep an explicit no-edit phase for every non-trivial bug. Investigation and patching are separate jobs. When they run together, the patch always wins and the evidence loses.

Rank hypotheses, then name the discriminating observation

Require AI to return hypotheses in a table with three columns: hypothesis, evidence for, evidence against. Then require a fourth element: the discriminating observation — the single cheapest check that would support one hypothesis and weaken the others.

For the watchlist-after-sign-in bug, the table might look like:

Each hypothesis then gets its discriminator: "Read the failed request's cookie header and the server's parsed session value for req_fail_44 — if the cookie is present but parsing returns empty, hypothesis 3 wins." Or: "Add temporary debug logging of session age at the route — if failures show age under 60 seconds, hypothesis 2 loses."

This is the skill. An investigation without discriminators produces three plausible paragraphs and no next step. An investigation with discriminators produces one cheap observation you can run.

Search the codebase for evidence, not vibes

Tell AI exactly where to look and how to cite what it finds. The search path for most app bugs is the same:

1. Route — the API entry point and its middleware order. 2. Component — the button, form, or page that sends the request. 3. Schema and policy — the database table, ownership rule, and validation that govern the write. 4. Error string — every file that emits or matches the observed error. 5. Call chain — the sequence from UI handler through route to database or provider.

Ask for exact cites: file path, function name, and line range. And require AI to separate observed facts from inference:

• Fact: "POST /api/watchlist in app/api/watchlist/route.ts:18–42 returns 401 when getSession() returns null."
• Inference: "Therefore the SDK bump probably changed what getSession() reads."

Facts can be checked. Inferences must earn their place in the hypothesis table. When AI cannot find something, require it to say so: "No ownership check found in the route; searched for owner_id across app/api/watchlist/." An honest "not found" is evidence too.

Rollback can be the best first fix

When a focused recent change caused a production regression, the bravest and most professional move is often to undo it first and investigate second. Rolling back is not admitting failure. It restores the known-good state customers relied on while you think on a branch instead of under pressure.

Rollback fits when three conditions hold: the regression is focused (one feature broke, not the whole system), recent (a small set of commits separates good from bad), and reversible (no destructive migration or billing side effect stands in the way). The watchlist bug qualifies if commit a3f9c1e is the only change in the window and reverting the SDK bump restores saves. A data-loss bug after a destructive migration does not qualify — there rollback can make things worse.

The sequence is: restore the last known-good deploy, confirm the reproduction now passes, then branch and investigate the reverted change at leisure. Record the rollback as its own commit with cause and evidence, the same way you would record any fix. Lesson 52.3 covers the repair sequence in full.

Give the models roles and keep one owner

For a bug that matters, split the work on purpose:

• Investigator (read-only): searches the codebase, builds the hypothesis table, names discriminators. No write permission.
• Proposer: after you approve one hypothesis, drafts the smallest patch on a branch.
• Reviewer (a different model or a human): reads the diff against the bug report and the contract, and lists what could still be wrong.

Do not multiply agents beyond what the bug needs. Three agents with no owner produce three confident opinions. One integration owner — you, or a named teammate — approves the hypothesis, authorizes the patch scope, and accepts or rejects the diff. Write the authorization down: "Approved: investigate session parsing in route.ts only. Do not touch auth config or migrations."

Exercise: write an investigation prompt that forbids modification

Using your BUG-REPORT.md from Lesson 52.1:

1. Assemble the packet: bug report, relevant API contract, the last known-good commit, changed files since then, and the exact log lines for one success and one failure. 2. Write a prompt that orders AI to make zero file modifications, cite exact files and functions, separate fact from inference, rank three hypotheses with evidence for and against, and name one discriminating observation per hypothesis. 3. Run it, then approve or reject the table before authorizing any patch.

Done means: an investigation note with a chosen hypothesis, explicitly rejected hypotheses, and a written authorization for the next smallest change. Verify: check one cited file and line yourself — if the citation is wrong, the investigation is not ready. Common failure: letting the model "just fix it while you're in there." That sentence is how regressions are born.

Check your understanding

• What four things does a disciplined prompt do that "it broke, fix it" does not?
• What is a discriminating observation, and why does it matter more than a plausible explanation?
• When is rollback the right first fix, and when is it the wrong one?

Next you will make the fix itself: the smallest change that addresses the cause, proven by tests, a clean diff, and a handoff that leaves the system better than you found it.