Sean describes how he reads code in multiple passes rather than front-to-back.

I’ll take a function or a piece of data and try to figure out how it’s used, fanning out to multiple call-sites (including ones outside the diff) as I go. […] I try to be ruthlessly focused on just the thing I’m looking at right now: everything else gets treated as a black box.

I thought everyone does it like this. I definitely do. For complex code bases I even make a diagram in diagrams.net to not lose the thread.

The interesting part of the blog post is his experience reviewing LLM code:

But having read a bunch of AI-generated code this year, I can say that you definitely still have to read it. I routinely find massive errors in AI-generated code. These are not bugs — the code typically does what the AI wanted it to do — so much as they’re problems of alignment. As a recent example, a small change to thread an extra value through some existing code ballooned out into a complex three-thousand-line diff, because the agent noticed a race condition and built a complex machinery to “fix” it. In fact, this race condition was harmless by design: two pieces of unrelated data could become briefly out of sync, with no customer impact.

I noticed exactly this edge-case obsession as well. The coding agent gets overly focused on an edge case and tries to cover it even if it can never occur by design or constraints of the domain (not part of the codebase).

I also noticed the same behaviour in legal analysis. In a contract I reviewed with Claude it really emphasized a particular problem that it saw in the contract. However the lawyer convinced me that the flagged problem wouldn’t ever be relevant in the real world due to legal precedent ruling it out (not part of the contract).