Completing the Toolkit
In Lesson 3 you learned the three rules, the five habits, and walked through a full PRIMM-AI+ cycle with Claude Code. Two more tools complete the kit: a vocabulary for bugs, and a new kind of exercise called Parsons problems.
Five Kinds of Bugs
James runs his modified program and gets an error. "It's broken," he says. "I'll just ask Claude Code to fix it."
Emma stops him. "Before you do, what kind of problem is it?"
"How would I know? I just see an error."
"That is the first skill," Emma says. "Not every bug is the same. When something goes wrong, knowing what kind of problem it is tells you where to look. There are five kinds."
| Kind of Bug | What Went Wrong | Simple Example |
|---|---|---|
| Type Error | You gave the wrong kind of data | You wrote name + score but score is a number, not text |
| Logic Error | The code runs but gives the wrong answer | You printed the name where the subject should be |
| Specification Error | The code does what you asked, but you asked for the wrong thing | You built a greeting program when the task was a profile card |
| Data Error | The code breaks with unusual inputs | The name is empty, so the output starts with a space |
| Orchestration Error | The pieces run in the wrong order | You tried to print result before you created it |
James looks at his error message again: TypeError: can only concatenate str (not "int") to str. "It literally says TypeError. The + couldn't join text with a number. That's a type problem."
"Exactly," Emma says. "You just diagnosed the bug in ten seconds because you had a name for it. Now try the /bug command. It walks you through this same process."
James types /bug TypeError: can only concatenate str (not "int") to str in Claude Code. Claude Code shows the five categories, asks him to classify the error, and after he answers, confirms and shows the fix: wrapping score in str(). A single change.
"Next time, you'll find it even faster," Emma says.
You do not need to memorize this table now. You will practice finding each kind starting in Chapter 45. Just knowing that bugs come in different kinds helps you ask better questions when something goes wrong.
Parsons Problems
Emma shows James four lines of code, but they are in the wrong order. "Put these back in the right sequence," she says.
James stares at them. He knows what each line does from the lessons so far. But arranging them correctly requires something deeper: understanding why the order matters.
A Parsons problem gives you the correct lines of code in scrambled order. Your job is to rearrange them into a working program. This tests whether you truly understand the program's structure, not just what it does, but why the lines must go in a specific order.
Try this one:
# These four lines are scrambled. What is the correct order?
print(label)
temp = 32
label = city + ": " + str(temp) + "C"
city = "London"
Reminder:
+joins text together.str()converts a number to text so+can use it.
Output (when correctly ordered):
London: 32C
Hint
Think about which variables must exist before other lines can use them. Which line creates a value that no other line depends on?
Answer
city, then temp, then label, then print. The reasoning: city must exist before label can use it, temp must exist before label can use it, and label must exist before print can display it.
You will see Parsons problems in later chapters as a bridge between Investigate and Modify. They check your structural understanding before you attempt free modifications. You can also generate fresh Parsons problems in Claude Code using the /parsons command. Type /parsons @lesson.py to scramble an existing file, or /parsons string concatenation to generate a new puzzle on any topic.
What Every Chapter Looks Like
Starting in Chapter 45, every programming lesson follows the same five-step pattern you practiced in Lessons 1 through 3. The structure stays the same; only the code gets harder.
| Step | What you do | Slash command |
|---|---|---|
| 1. Predict | Read the code, write your prediction, rate confidence | /predict |
| 2. Run | Type python file.py yourself, compare to your prediction | (you run it, not Claude Code) |
| 3. Investigate | Explain in your own words, then ask questions | /investigate |
| 4. Modify | Change the code yourself, predict the new output, run it | /modify |
| 5. Make | Write a spec, build something new, verify it works | /make |
After two chapters, this pattern becomes invisible. You stop thinking about which step comes next. You just do it. And if you ever want to practice the full cycle on any topic, type /primm.
Try With AI
Prompt 1: Classify Three Bugs
You already diagnosed a Type Error in the lesson above. Now try two different kinds. In Claude Code, type:
/bug My program prints "Sarah" where it should print "Python"
Classify it before Claude Code shows the fix. Then try this one:
/bug NameError: name 'result' is not defined
What you are learning: Each bug type points to a different kind of fix. The first is a Logic Error (code runs but gives the wrong answer). The second is an Orchestration Error (using something before it exists). Naming the kind narrows your search.
Prompt 2: Generate and Solve a Parsons Problem
In Claude Code, type:
/parsons string formatting with two variables
Solve it. Then ask Claude Code to generate two more Parsons problems on the same topic, harder each time.
What you are learning: Parsons problems test structural understanding. The scrambled lines force you to reason about data flow: which variables must exist before others can use them.
Prompt 3: Walk a Full Cycle Without Looking
In Claude Code, type:
/primm string concatenation with three variables
Walk all five stages. Do not look back at Lesson 3 for the steps. Let Claude Code drive. After you finish, write down which stage felt easiest and which felt hardest.
What you are learning: Whether the PRIMM rhythm feels natural now. If you got through all five stages without looking back at Lesson 3, the pattern has landed. You are ready for Chapter 43.
James closes his notebook. "Five kinds of bugs so I know what I'm looking for. Parsons problems to test whether I really understand the order. And every chapter follows the same five steps." He pauses. "It is like a standard operating procedure. When I ran distribution centers, we had a written procedure for every process. New hires never had to wonder what to do next."
"After two chapters, the five-step rhythm becomes invisible," Emma says. "You stop thinking about predict, run, investigate, modify, make. You just do it."
"So what comes next?" James asks.
"The ten axioms," Emma says. "Professional principles for building software with AI. You'll learn them the same way: predicting, investigating, and eventually writing programs that embody them."