Build with AI: From Zero to Your First App · Module 7: Debugging and testing
Break the Repeated-Fix Loop
The loop: same fault, third identical fix request, growing frustration. This lesson names the exit: hypotheses singly, escalation in order, rest as a tool.
9 min reading
Objectives
- Recognize the repeated-fix loop by its three signals
- Answer it with one hypothesis at a time, tested singly
- Escalate correctly: snapshot, summary, fresh chat, human
- State when to stop and sleep on it
Why this matters
Repeated-fix loops burn quotas, evenings and confidence at once. Each identical retry ("fix it again, differently") adds changes atop untested ones, burying the fault deeper. Recognizing the loop early saves all three: the exit is method, not effort. Trying harder inside the loop never worked; stepping out of it always does.
Concepts
Three signals. The same fault after two fixes. Requests getting vaguer ("just make it work"). Frustration rising while understanding stays flat. Two signals mean pause; three mean exit the loop now.
One hypothesis at a time. Write the single sentence under test ("save drops entries because storage is full"), change one thing for it, run the reproduction plus the routine. Confirm or kill the hypothesis, write the verdict, next hypothesis. Lesson M02L7 shrinking plus M06L21 singleness, now as debugging law. Never stack two hypotheses in one change.
Escalation order. Snapshot first (safety). Write the six-line report (clarity). Move to a fresh chat with summary plus report (new eyes). Ask a human with the same report (community, course forum). Each step costs little and brings new perspective; skipping to humans with "it broke" wastes theirs.
Stop rules. Three dead hypotheses mean a break: walk, sleep, return. Tired brains pattern-match phantoms. Morning-you with a caged reproduction beats midnight-you with five stacked changes, every time.
Worked example
Loop: order echo shows stale values after three "fix the echo" requests. Exit: signal check (same fault twice, vaguer requests: loop confirmed). Hypothesis one: "echo reads before save completes" (change order, test: still stale, killed). Hypothesis two: "echo renders a cached list" (re-render from fresh read, test: fixed, confirmed). Total: two single changes, two verdicts, one fix. The loop's third identical request would have rewritten the form and buried it.
Expected result: your next stuck fault handled with written hypotheses, single tests and verdicts, escalation or rest as needed.
The common wrong move
Varying the plea instead of the hypothesis ("please fix", "fix harder", "try again"). The tool answers the words; the fault answers the hypothesis. Change the test, not the tone.
Lab and next step
Lab A21 (paired with lesson 27) includes the loop drill: two dead hypotheses before the fix, verdicts written. Next, module M08 finishes: final project, pre-release checks, honest presentation.
Quick check
An optional 4-question self-check. Answers never leave your device, are not stored, and never count toward any assessment.
Lesson feedback
No published feedback yet.
Log in and complete the lesson to leave feedback.
Exercise
On your next stuck fault, write hypotheses singly with tests and verdicts (at least two). If three die, escalate or rest; record which you chose.
Pass criteria
At least two written hypotheses with single tests and verdicts; loop signals noted; escalation or rest decision recorded with reason.