Things Will Break — That's Normal

The first time your code does something unexpected, your instinct might be to think you did something wrong, that you are not cut out for this, or that you broke something permanently. Every one of those thoughts is a lie. Every programmer who has ever shipped software — from a sixth-grader making their first website to the engineers who built the apps on your phone — has stared at broken code. Breaking things is not a sign you are failing. It is a sign you are building.

Why Bugs Exist at All

Software is built from instructions, and instructions are written by humans. Humans make mistakes: typos, logic errors, forgotten steps, wrong assumptions. A bug is simply a mismatch between what you told the computer to do and what you actually wanted it to do. That mismatch is normal because human thinking is not perfectly precise, and computers are ruthlessly literal. Consider this analogy: if you text a friend 'meet me at the park' and they show up at a different park, was that a catastrophic failure? No — there was a gap in communication. A bug works the same way. You said something; the computer heard it precisely; the result was not what you meant. Your job is to close that gap.

Here is a real example. A student building a quiz app wrote code that was supposed to show the score at the end. Instead it showed zero every time. Nothing crashed. Nothing exploded. The computer just followed the instructions perfectly — and the instructions said to display a variable that was never updated. The student fixed it in two minutes once they spotted the gap. The bug was not scary; it was just a missing step.

The Debugging Mindset

Professional programmers talk about the debugging mindset — a specific way of thinking when things go wrong. It has four moves: 1. Stay curious, not defensive. The bug is not accusing you. It is giving you information. 2. Assume the computer is doing exactly what you told it. The error is in the instructions, not the machine. 3. Narrow the problem down before trying to fix anything. Guessing randomly wastes time. 4. Change one thing at a time. If you change five things and the bug disappears, you still do not know what fixed it. This module will teach you each of these moves in detail. For now, the most important thing is the first one: stay curious.

Debugging with AI Changes the Game

When you build with AI tools, you have a collaborator available around the clock who has seen millions of bugs. That is powerful. But it does not change the mindset you need — it amplifies it. If you panic and dump confused descriptions at the AI, you will get confused answers. If you approach bugs with curiosity and precision, the AI becomes a remarkably useful thinking partner. The lessons ahead will show you exactly how to do that: reading error messages, describing bugs clearly, asking for fixes in a way that actually works, and — crucially — checking whether the AI's answer is actually right. The goal is not to get the AI to do your debugging for you. The goal is to be a sharp debugger who uses AI as a tool.