Skip to main content
Building with AI (Vibe Coding)

⏱ About 15 min15 XP

Checking the AI's Fix

The AI replied. It gave you code. It explained the change with confidence. The explanation makes sense. Now what? The next move is the one that separates careful builders from people who end up with worse bugs than they started with: you test the fix before you trust it. A proposed fix is a hypothesis, not a guarantee.

Why Fixes Need Verification

An AI does not run your code. It does not see your full project. It does not know what other functions might interact with the one it just changed. It produces the most plausible fix based on what you shared — and most of the time that fix is correct. But 'most of the time' is not 'always.' A fix can fail in several ways: - It solves the immediate bug but breaks something else. - It solves the described symptom but not the underlying cause, so the bug reappears later. - It introduces a new bug that is harder to find than the original. - It simply does not fix the bug because the AI misunderstood the problem. None of this makes AI a bad tool. It makes testing a required step, not an optional one.

A Fix Is a Hypothesis

When the AI proposes a fix, treat it the way a scientist treats a hypothesis: plausible, worth testing, not yet proven. Your job is to run the experiment and check the result.

Here is a verification process that works: Step 1 — Understand the change before applying it. Read what the AI changed and why it says the change helps. If you cannot explain the change in your own words, you are not ready to apply it. Step 2 — Apply the fix to your code. Make only that change, nothing else. Step 3 — Test the specific scenario that was broken. Does the original bug still happen? Step 4 — Test nearby behavior. Does anything that used to work now fail? Step 5 — If the fix works, document what was changed and why. You will want to remember this. Step 6 — If the fix does not work, do not panic. You now have new information. The AI's reasoning was wrong somewhere — that is itself a clue about what the real cause is.

Match each verification step to its purpose.

Terms

Understand the change before applying
Test the originally broken scenario
Test nearby behavior
Document what changed and why

Definitions

Avoid applying code you cannot explain or defend
Build understanding so you can fix similar bugs faster later
Confirm the specific bug is gone
Catch regressions the fix may have introduced

Drag terms onto their definitions, or click a term then click a definition to match.

The Regression Problem

A regression is when a fix breaks something that was previously working. Regressions are common enough that professional development teams run automated tests specifically to catch them. When you apply an AI fix, think about what the changed code touches. If a function is used in five places and you changed how it works, all five places might behave differently. You need to check each of them, not just the one that was broken. If your project is small, this check takes two minutes. If your project is larger, take notes about all the places the changed code connects to before you apply anything.

Watch for Regressions

After applying any fix, test the things that were already working, not just the thing that was broken. A fix that solves one bug while breaking two others is a step backward.

What is a regression in software?

Why should you understand an AI's fix before applying it?

Apply, Test, and Check

  1. Find a small bug in a project you are working on, or use the sample buggy code your teacher provides.
  2. Step 1: Describe the bug using the three-part formula from Lesson 3.
  3. Step 2: Write (do not send) an AI fix request using the format from Lesson 4.
  4. Step 3: Your teacher or partner will provide a 'proposed fix' (a corrected version with one change).
  5. Step 4: Before applying the fix, read it and explain in one sentence what it changes and why.
  6. Step 5: Apply the fix.
  7. Step 6: Test the broken scenario. Does it work now?
  8. Step 7: Test two other things in the same code. Did anything break?
  9. Report your findings: Did the fix work? Any regressions?