The most detailed free FDE + DevOps library: 140+ lessons, 70+ labs and 80 long-form articles, in English and Turkish. Start learning →

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.

Log in to track progressFree account: stores only your lesson progress and quiz results.