1. Your own code is read from memory, someone else's is not
After lunch, Tommy, as usual, grabbed coffee, but came to Alex with a very specific annoyance:
— Listen, I don't understand. I open my own code and immediately see what is what. But I open this contractor-written code — and it is like fog. The letters are the same, but I can't read it. Why?
— Think about what you use to read your own code, — Alex replies. — Not your eyes. Memory. You wrote it yourself. You remember where everything is, why this line is here, how one thing is tied to another. Your eyes just glide over your own code — and that's normal, because the map is already in your head. You are not reading; you are remembering.
— And here there is no map, — Tommy says slowly.
— Right. You can't read someone else's code from memory — there simply is none. And the nastiest part is that the habit of "the eye glides" does not go away. You glide over someone else's code too — and miss things that you would know by heart in your own. In your own code, that is safe. In someone else's, it is not. That is why someone else's code is read differently from your own. Slowly and suspiciously. You weigh each piece separately instead of skimming through it with a "looks fine" attitude. The speed that saves time in your own house lays a mine in someone else's. Oliver already told you that; I'm just explaining why.
2. The object of reading is not the file, but the change
Tommy is startled by the practical side:
— Wait. Slowly and suspiciously the whole file? I'd be sitting here for a week. It's huge, and I still won't understand half of it — that's the contractor's logic, and I'm not getting into that.
— And you don't need to, — Alex reassures him. — Here is the main shift. When you are editing someone else's code, you should read not the whole file. But each change.
— What do you mean, change?
— Look. Reading and understanding a whole foreign file from start to finish is slow, and often completely impossible, you're right. But checking what the agent just changed specifically is realistic. It is a small piece. It is the diff — the list of what changed. That is what you read — slowly, suspiciously, every line. For each piece of the change, ask one question: is this for the task — or "while we're at it"?
Tommy tries to apply it to himself:
— So I'm not trying to understand the whole foreign module. I'm only looking at the trace the agent left. At what changed.
— Yes. The object of your attention is not "the whole code", but "what exactly is changing". That is doable — and it is exactly what helps you work on any task. You will not hold the whole file in your head. But your own diff of ten lines — easily.
Tommy remembers the morning comic — the door and the repainted apartment — and grins, no longer as if it were just a joke.
— Listen, that's literally the picture from the chat. Paint the door, not the whole apartment. My job is to leave in the diff only the door. And everything else, even if it "looks neater" and "has been renamed more logically", is by default not mine.
— See, it's sinking in, — Alex says back.
3. Three classes of changes
— And how do I understand which piece of the diff to reject and which not? — Tommy wants a fundamental solution right away. — By eye?
— Not by eye. There are three boxes into which you sort every change, — Alex says, laying it out. — The first is unnecessary. That is when the agent "while it was at it" reformatted something, moved indents around, polished the neighboring code. It doesn't seem to break anything directly. But it bloats the diff and hides the real fix — you can't see the substance through the cosmetics. In someone else's code, that is especially harmful: you drown in the polished stuff and do not see what actually changed.
— That's exactly what Sam dumped on me, Tommy realizes.
— Exactly. The second box is dangerous. That is when it touched the wrong area, hit neighboring code, deleted something needed. The most expensive class of mistakes — because that is what silently breaks something that was working. Oliver was just telling you about that, remember? Then something suddenly stops working, and now go and figure it out. In someone else's code, the danger is highest of all: after all, you do not know what was important here.
— And the third?
— The third is unexpected. That is when the agent did more than was asked for. It added an "improvement" you did not request. An uninvited animation, a new feature, something else. And here is the subtle part: this is not always bad. Sometimes the improvement really is useful. But it always requires a conscious "yes" — not something that slips through while you blink.
Tommy puts the picture together himself:
— So I take the diff, go through the pieces, and throw each one into one of the three boxes. Unnecessary — overboard. Dangerous — overboard for good. Unexpected — I decide separately whether I need it right now or not.
— That's how the diff stays clean, — Alex nods. — Only what is needed goes into the project. And sorting things into boxes is no longer philosophy. It's work. And now I'll show you how that is done in Claude Code. This is where the interesting part begins.