The art of watching AI code

1. The skill nobody taught you

When you watch the model write code, three things can happen. It writes what you wanted. It writes something close to what you wanted but slightly off. It writes something completely wrong but plausible-looking.

The third one is dangerous. The second one is where most of your work lives. The first one is what you're hoping for, and it happens more often than people admit, which is also dangerous, because it teaches you to stop watching.

Watching AI code is the most important new skill in this chapter. Not because it sounds hard — it sounds like you're just sitting there. It's hard because the failure mode is not noticing. Code that looks right but isn't is the most expensive kind of code there is.

2. This is not laziness

The instinct from school is that watching is cheating. You're supposed to do the work, not watch someone else do it. That instinct is wrong for this job.

Watching is the work. The model is a junior engineer with infinite patience, perfect recall of every library, and a small but persistent tendency to confidently make things up. Your job is to be the senior engineer who reads what the junior produced and catches the part where they confidently made things up.

A senior engineer reviewing a pull request from a junior is not lazy. They're doing the most leveraged thing they can do — preventing a bug from reaching production. You are now doing that, except the junior types faster and the PR arrives in the middle of your sentence.

3. Watching while it streams

Most modern tools stream the code token by token, left to right, top to bottom. You can read along.

That sounds inefficient. It's actually the point. Reading along, you'll feel the wrong assumption form before the code is done. The model imports the wrong library — stop it. The model picks the wrong data structure — stop it. The model writes the loop one off — stop it. The earlier you catch the divergence, the cheaper the fix.

The reflex to build: read the first three lines of any generated block before letting the rest land. That's where most of the wrong-direction errors are. The first line of the implementation usually tells you whether the model understood the spec. If it didn't, kill it and rewrite the spec.

4. Steering mid-stream

The conversation is two-way. You don't have to wait for the model to finish.

Things you'll find yourself saying out loud (or typing into the chat):

• "Show me the type of result here."
• "Why did you import that? We don't use that library."
• "What happens if the array is empty?"
• "That looks like it'll allocate on every call. Can it be lazy?"
• "Stop. The spec said no network calls."

Each of those is a course correction. The model's first instinct is often a reasonable instinct for a generic version of the problem you described. Steering pulls it toward the specific version you actually have.

5. Reading code you didn't write

This is the part that takes practice. You're going to read more code than you write — by a lot. Reading code is a different skill from writing it.

When you write code, you build the model of the system as you go. When you read code, you have to build that model from the outside. You're reconstructing the author's intent from their output. With AI code, the "author" had no intent — it pattern-matched. So you're reconstructing intent that was never there. You're putting it there yourself, as you read, and then checking that the code is consistent with the intent you imagined.

Get good at this. Read other people's code in real codebases. Read the standard library of the language you use. Read open-source projects you depend on. Every hour you spend reading code makes you faster at the new loop.