Class 51 gave you a trail to follow: structured logs, request IDs, and the habit of reading the right layer before asking AI to do anything. Class 52 turns that trail into a discipline. The temptation when something breaks is to describe it to AI and hope for a patch. Resist that. A bug you cannot make happen on demand is a bug you cannot prove you fixed.

The debugging loop

Debugging with AI works when you stay in a tight loop and keep each step small enough to check. Memorize this order:

reproduce → collect evidence → locate boundary
  → form hypothesis → make smallest change
  → test → inspect diff → checkpoint → handoff

Each arrow matters. Reproduce means you can trigger the failure with written steps. Collect evidence means logs, request IDs, screenshots, and status codes — not recollections. Locate boundary means naming the layer where the failure appears: browser, API route, policy, database, provider, or worker. Only then do you form a hypothesis about cause. The smallest change is one fix, in one place, that you can undo. Test means running the reproduction again plus the relevant checks. Inspect diff means reading exactly what changed. Checkpoint means committing or stashing a known state. Handoff means writing down what is proven and what is still unknown.

Skip a step and AI fills the gap with a guess. The loop keeps its speed pointed at facts.

A useful rule: no code changes until you have written down the reproduction. If you cannot write the steps, you are not ready to fix anything.

Deterministic versus intermittent

Some bugs happen every time. Most of the painful ones do not.

A deterministic bug reproduces on demand: same steps, same result, every time. Click Save on an empty watchlist title and the route always returns 400. These are straightforward. Write the steps once, and anyone can confirm the fix.

An intermittent bug happens sometimes. It fails on Tuesdays, on phones, for one test account, after the session expires, or only under load. These punish hasty fixes, because a patch can appear to work simply because the bug did not show up that time.

When a failure is intermittent, stop trying to explain it and start recording its conditions:

Write "unknown" rather than inventing a value. "Frequency unknown — tried twice" is honest evidence. "Probably the database" is not. Your goal is a table that lets someone else reproduce the same flakiness.

A scenario: the watchlist save that sometimes fails after sign-in

Take the Research Desk case from the outline. A tester reports: "Saving to my watchlist sometimes fails right after I sign in."

The undisciplined response is to tell AI "fix auth" and accept a rewritten session helper. Do this instead:

1. Create a dedicated test account with a known watchlist state — one saved company, one unsaved ticker. Never debug with your real account or real customer data. 2. Reproduce with a script of clicks. Sign out. Sign in. Open /brief/AAPL. Click Save. Wait five seconds. Record the outcome. Repeat ten times and count successes and failures. 3. Capture both paths. For one success and one failure, save the network request and response: method, URL, status code, requestID, time, and body. A success returning 201 beside a failure returning 401 is the investigation's starting point. 4. Compare the logs by request ID. Does the failed request reach the API route? Does it fail at identity verification, the ownership policy, validation, or the database write? Note the exact line. 5. Compare the conditions. Did failures follow a fresh sign-in within seconds, suggesting the session had not propagated? Did they follow a long idle period, suggesting expiry? Did they cluster around a slow provider refresh that blocked the route?

At the end you have something durable: "With test account debug+07, Save fails 4 times in 12 tries, always within 60 seconds of sign-in, always 401, server log shows session_not_found for those request IDs, successes show watchlist_insert_ok." That paragraph is worth more than a page of AI speculation.

Know when to stop and shrink the task

Some bugs require you to slow down before AI touches anything. Shrink the task and require human review when the bug touches:

• Authentication or sessions — a wrong fix can lock users out or let the wrong users in.
• Billing, quotas, or paid provider calls — a retry loop can multiply cost.
• Production data — never reproduce by editing real customer records.
• Secrets or credentials — never paste keys into a prompt or log them for evidence.
• Destructive migrations — a schema change can destroy data that no rollback restores.
• A wide unknown area — failures across many routes, many users, and many error types at once.

Shrinking means: reproduce on a copy, limit the AI to read-only investigation, forbid changes to the sensitive files, and require a named reviewer before any fix is applied. Write the boundary into the task: "Do not modify auth helpers, environment files, or migration files. Investigate only."

Write the bug report another person can use

Turn every reproduction into a BUG-REPORT.md file in the repository or task folder. The file is the finish line for this lesson. It must let a stranger reproduce the bug without your chat history.

# BUG-REPORT — Watchlist save fails after sign-in

## Expected
Signed-in user clicks Save on /brief/AAPL and sees
a saved confirmation within 3 seconds.

## Actual
4 of 12 tries return an error toast and no saved state.
Status 401, server event `session_not_found`.

## Steps to reproduce
1. Sign out. Sign in as debug+07 (password in test vault).
2. Open /brief/AAPL. 3. Click Save. 4. Repeat 12 times,
   signing out and back in every 3 tries.

## Evidence
- Success: 14:03:11 UTC, requestID req_ok_91, 201, log `watchlist_insert_ok`
- Failure: 14:04:02 UTC, requestID req_fail_44, 401, log `session_not_found`
- Screenshot + HAR saved under /evidence/2026-05-11/

## Scope
Only POST /api/watchlist within 60s of sign-in.
GET /api/brief and existing watchlist reads unaffected.

## Impact
Medium. New users hit it on first save; retry usually succeeds.

## Recent changes
- Auth provider SDK bumped in commit a3f9c1e (2 days ago).
- Session TTL changed from 60 to 15 minutes (see DECISIONS.md).

## Unknowns
- Whether failure follows slow session propagation or short TTL.
- Frequency on mobile browsers not yet measured.

Notice what the report does not contain: no proposed fix, no blame, no "probably." Expected versus actual, steps, evidence, scope, impact, changes, unknowns.

Exercise: file one real bug report

Pick a real or simulated bug in your project — a failed save, a stale list, a confusing error.

1. Reproduce it three or more times and record frequency and conditions using the table above. 2. Capture one success and one failure with request ID, status, time, and the matching server log line. 3. Write BUG-REPORT.md with all eight headings: expected, actual, steps, evidence, scope, impact, changes, unknowns.

Done means: a file another person can follow to see the same failure without asking you questions. Verify: hand the steps to a second session or a teammate and confirm they get the same result. Common failure: a report that says "sometimes broken" with no request IDs — that is a complaint, not a reproduction.

Check your understanding

• Why must reproduction come before hypothesis?
• What seven conditions should you record for an intermittent bug?
• Which kinds of bugs require you to shrink the task and require review before fixing?

In the next lesson you will hand that report to AI the right way: as a read-only investigation with ranked hypotheses, not an invitation to spray patches.