Reading Code You Didn't Write

Most code you encounter in your life will not be code you wrote. Some of it will be from teammates, some from textbooks, some from random pages on the internet, and an increasing amount from AI assistants. None of these sources are inherently trustworthy. Each of them needs to be read.

This chapter is the first of nine across the course where you focus specifically on the skills needed to work well with AI assistants. The skill for this part is the most foundational one: being a critical reader of code, not just a writer of it.

The Same Skill, A Different Context

In the previous chapter you traced programs line by line, kept track of the state, used debug prints to make hidden values visible, and learned to predict before running. That skill does not change based on who wrote the code. A program is a program. Tracing works the same way whether you wrote it yourself, copied it from a textbook, or accepted a suggestion from an AI assistant.

What does change is your stance toward the code in front of you.

When you write a program yourself, you usually trust it a little too much. You know what you were trying to do, so you assume the code does it. Tracing is what catches the gap between intent and behavior.

When you read code someone else wrote, the trust starts lower. You do not know what they were trying to do. You have to derive it from the code itself. Tracing is what lets you do that.

AI-generated code is in this second category, even when the assistant is confident and the code looks polished.

What AI Assistants Are Good At, and What They Aren’t

AI assistants are good at producing code that looks right. They have seen vast amounts of Python and can reproduce common patterns smoothly. For straightforward tasks like “print a greeting” or “convert this input to a number,” what they produce is often correct.

They are less reliable in three specific ways:

• They sometimes produce code that runs but does the wrong thing.
• They sometimes produce code that calls functions or uses parameters that do not actually exist.
• They confidently explain code, including their own, in ways that may not match what the code does.

None of these mean AI assistants are not useful. They mean that “the AI said so” is not a substitute for tracing. The fix is not to avoid AI. The fix is to keep being the person who reads carefully.

If you accept code from an AI assistant without being able to explain what it does, you are not really using the AI. You are gambling. Sometimes the gamble pays off, and sometimes it doesn’t. Tracing is what turns gambling into use.

A Practice Workflow

When you read a piece of code you did not write, here is a workflow that works well:

1. Skim for shape. How long is it? What kinds of things does it do? Input? Output? Arithmetic? Files?
2. Identify the inputs the program needs and the outputs it produces.
3. Trace the program with one specific input, step by step, the way you did in the previous chapter.
4. Predict the output before running it.
5. Run the program. Compare the actual output with your prediction.
6. Explain the program in one or two sentences of plain language.

The last step is the one beginners often skip. If you cannot explain what a program does in your own words, you do not yet understand it, regardless of whether you “got it to run”, or whether you got points from an exercise where you had to produce the code.

Understanding is not just about getting the right output. It is about being able to say what the program does.

A Small Example

Here is a short program of the kind an AI assistant might produce in response to “ask the user for two numbers and tell them the bigger one”:

a = int(input("First number: "))
b = int(input("Second number: "))

if a > b:
    bigger = a
else:
    bigger = b

print(f"The bigger number is {bigger}.")

You have not formally seen if/else yet — that is the next part’s topic. But even without knowing the precise syntax, the workflow from the previous section still applies.

1. Shape: nine lines. Two inputs. Some kind of comparison. One line of output.
2. Inputs: two numbers from the user. Output: a sentence with one of them.
3. Trace with a = 5 and b = 3. The comparison a > b is true, so bigger is set to a, which is 5. The program prints The bigger number is 5.
4. Trace with a = 3 and b = 5. The comparison is false, so the else branch runs and bigger is set to b, which is 5. The program prints The bigger number is 5.
5. In plain language: the program asks for two numbers and prints the larger of the two.

Notice that you found out what the program does without needing the AI to explain it. That is the goal. Explanations from any source — yours, a teacher’s, an AI’s — are easier to evaluate once you have already understood the code yourself.

first = int(input("First number: "))
second = int(input("Second number: "))
total = first + second
print(f"Total: {total}")

first = ...
second = ...
total = ...
output: ...
explanation: ...

Where AI-Generated Code Can Quietly Be Wrong

Even at the level of programs you can write in this part, AI-generated code has a few common failure modes. Knowing them helps you read with a useful kind of suspicion.

You will spend much of the next part on the last one, which is the most common in practice. For now, just notice that “looks right” is not the same as “is right,” and that the way to tell them apart is the same skill you have been practicing throughout this part: trace, predict, run, compare.

The First of Nine AI Skills

Across the course, you will develop nine distinct skills for working with AI assistants. They build on each other. This part’s skill — critical reading — is the foundation. The others, briefly, are:

Every one of these skills assumes you can read code, which is what you have been practicing in this part. The next eight parts will build on that skill.

A Note on Stance

This chapter is not asking you to be cynical about AI assistants, and it is not asking you to be enthusiastic about them either. It is asking you to be a programmer first.

A programmer reads code. A programmer traces what it does. A programmer notices when the explanation and the behavior do not match. None of that changes based on who or what produced the code. The skills you have built this part — tracing, predicting, running, comparing — are the same skills you will use to evaluate AI suggestions in the parts ahead.

If at any point during the course you find yourself accepting AI-generated code without being able to explain it, that is a signal worth taking seriously. It is the moment to slow down, run the code in the sandbox, and trace it by hand.

Check Your Understanding

1. Why is “the AI said so” not enough to consider a program correct?
2. Trace the following program with the input 5. What does it print?

n = int(input("Enter a number: "))
result = n * 2 + 1
print(f"Result: {result}")

3. List two of the common failure modes of AI-generated code from the table above. Describe each in your own words.