When you ask an AI to analyze something against several criteria, the natural answer is a complete, clean table: every cell filled in and all of them with the same confident tone. It looks more useful. In reality it is less reliable, because you can no longer tell what it truly counted and what it made up.
The Problem With the Perfect Table
Imagine you ask for four data points for every finding in an audit: damage, radius, reversibility and precedence. Some can be answered by opening the code: how many places must be touched, in which file and on which line. There the model does well, because it can go and count. Others depend on information that is not in the repository: who uses that endpoint, what would happen to data already stored in production, whether there are external integrations. For those, a model that does not know usually answers anyway, confidently, filling in the most likely value.
The result is a table where what was verified and what was assumed look exactly the same.
The Instruction That Changes the Result
The fix is one sentence in the prompt: leave the cell blank when you cannot answer it by opening the code, and do not fill it in by approximation. With it, the agent separates what it has checked from what it cannot know, and the gaps become information: they show exactly where a person is needed.
It is worth adding other constraints: require the radius to be counted and listed with file and line (never "several"), and ask it not to sort the list or fix anything, so it does not skip steps that are your job.
What the Gaps Teach You
In practice the gaps tend to land in very revealing places: a design decision that has not been made yet (for example, how to identify the author of a comment without a session), data that only exists in production, a performance measurement nobody has taken. Each one tells you what to decide, what to measure or whom to ask.
You can also ask for one more step: explain why each blank cell was left empty. That explanation is easy to compare with your own judgment and saves you from interpreting the gap.
Two caveats. First, not all models or effort levels leave the same gaps: the threshold at which something counts as an approximation varies between runs. Second, a model that is overly cautious is usually preferable to one that invents, because it lets you focus your attention on what is genuinely undetermined.
Quick Summary
A complete table is not a reliable table. Ask for explicit gaps wherever something cannot be verified in the code, require counted rather than estimated data, and spend your time on the gaps: they are the part of the work that cannot be delegated.