The AI Learning Hub Journal

Run the Whole List Every Time

You changed one thing — that is not the only thing that changedan AI editing your project can touch places you were never told aboutyou asked for one change:"fix the booking form"the booking formthe email stepthe sign-inthe change ripples intoplaces you never lookedTHE CORE LOOP — RUN THE WHOLE LIST, NOT JUST THE PART YOU TOUCHEDchange one thingcheck every itemsave a copyrepeatthe point is catching the break you were not looking for — the one that otherwise reaches a real userFOUR CHANGES, THEN ONE CHECKa failure now has four suspects andno evidence — you are back to guessingguessing is the doom loop's front doorONE CHANGE, THEN A CHECKa failure has exactly one possiblecause — the fix is usually obviouswhile you still know what you didKEEP A ONE-MINUTE LOG — DATE · WHAT CHANGED · WHAT PASSEDit turns "I think it used to work" into "it passed Tuesday, and I changed the email step Wednesday"AFTER EVERY CHANGE, RUN EVERYTHING — THEN SAVE A COPYchange one thing, check everything, save, repeat — there is nothing more clever underneath
After every change, run the whole list — the change you asked for is not the only thing that changed.

The Change You Made Is Not the Only Thing That Changed

Here is the most useful idea borrowed from professional practice, stripped of everything technical. After any change, check the whole list, not just the part you touched. It is tempting to test only the new bit. You changed the booking form, so you test the booking form. But an AI editing your project may adjust things elsewhere, and shared pieces get touched in ways you were not told about. The entire value of running the full list is catching the break you were not looking for. That is precisely the break that otherwise reaches a real user, because by definition it sits in a place you had no reason to look.

  • Check every item after every change, not just the part you altered
  • Changes have effects in places you were not told about
  • The point is catching the break you were not looking for
  • Unwatched areas are exactly where a break survives long enough to reach users

Check Immediately, Not Later

Run the list right after each change, while you still know what you did. Make four changes and then check, and a failure gives you four suspects with no way to choose between them. You are back to guessing. Checked immediately, a failure has exactly one cause, and the fix is usually obvious. This is the same habit as changing one thing at a time, seen from the other end. Together they form the core loop of building without being able to read the code: change one thing, check everything, save a copy, repeat. It is unglamorous, and it is genuinely what makes the difference.

  • Change one thing, check everything, save a copy, repeat
  • Four changes then a check gives you four suspects and no evidence
  • Immediate checking is what keeps the cause identifiable
  • This loop is the whole discipline; there is nothing more clever underneath

Write Down What You Saw

Keep a plain note of each run: the date, what you changed, and which items passed. It takes a minute, and it gives you something you otherwise never have — a history. When something is wrong next week, you can see when it was last known good and what happened in between. That usually points straight at the cause. It also protects you from a specific unpleasantness: not being sure whether something ever worked. A short log turns "I think it used to work" into "it passed on Tuesday, and I changed the email step on Wednesday". That is a completely different quality of information.

  • Log the date, the change and the results in a plain file
  • A history tells you when something was last known good
  • It turns "I think it worked" into a specific date and a specific change
  • One minute per run buys you the only record of your project you will have

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.