The blindfolded painter

Commission a portrait from an artist who must work blindfolded. Each brushstroke is placed according to where they believe the previous one landed. They cannot step back, cannot see the emerging whole, cannot notice that one eye has drifted a centimetre south of where it should be. They are working entirely from an internal model of what they have done so far.

That is text generation. One token at a time, each choice conditioned on everything before it, no capacity to look at the finished thing while producing it, because the finished thing does not exist until the last word is placed.

Once you have seen it this way, a great deal of frustrating behaviour becomes obvious rather than mysterious.

Why your quality instructions do nothing#

Look at what you are actually asking when you write "ensure this is high quality" or "check for consistency" or "do not make assumptions" into a prompt.

You are asking for an assessment of something that has not been produced yet. The system cannot evaluate the document while generating it, because at the moment of each decision there is no document, only the part already committed. And committed is the operative word: once it has gone a particular way through the space of possible outputs, there is no reversing without starting again.

So the instruction does something, but not what you intended. It nudges the statistical tendency of what follows. It does not create a review, because a review requires a finished object and a reviewer standing outside it, and you have neither.

This is why a long document from a single pass so often starts strongly and drifts. The opening is tightly conditioned on your instruction. By the middle, it is mostly conditioned on itself, and by the end it may be quietly repeating a point made three sections earlier, having lost track of the shape it was meant to be filling.

The fresh pair of eyes#

Now give that finished output to a completely new instance, with no memory of producing it.

Something genuinely different happens, and it is not marginal. This one receives the whole thing at once, as an object, the way a reader would. It can see that section three contradicts section one. It can notice that a claim in the summary is not supported anywhere in the body. It can spot that the argument stopped being about what it said it was about, roughly two thirds of the way down.

None of this is available to the original, and not through lack of ability. It is structural. The first instance was inside the thing.

The detail that matters most, and the one most people get wrong, is that it has to be genuinely fresh. Continuing the same conversation and asking it to review its own work does not work, because the reviewing instance is still conditioned by everything that produced the output, including whatever led it astray. It will defend its choices, in the sense that it will find them plausible, because they were plausible from where it was standing. Start a new session. Paste the output cold. Tell it nothing about how it came to exist.

That last part matters more than it sounds. Prime it with context about the intent and you have reintroduced exactly the bias you were trying to escape.

It applies to everything, not just code#

Developers usually grasp this immediately, because they already accept that authors should not be the only reviewers of their own work, and the practice of a second pair of eyes predates all of this by decades.

But the same structure applies to every kind of output. A strategy document generated in one pass captures the ideas; a second pass finds the assumption that was never stated and the recommendation that does not follow. A financial analysis compiles correctly; a second look tests whether the executive summary actually reflects the detail underneath it, which is the failure that costs the most and gets caught the least. Marketing copy finds its voice on the first pass and its discipline on the second, once someone can see the whole and notice that the actual point arrived in the final paragraph.

Technical documentation is perhaps the clearest case. The author knows the system, so they cannot see what they have assumed. A reviewer approaching it cold finds the gap in about forty seconds.

The economics, briefly#

You will use meaningfully more processing to do this. Perhaps a third again, sometimes more.

Against that, count what disappears. The rounds of human correction. The document that came back from a colleague with questions you could have answered yourself. The version that reached a client with an internal contradiction in it, which cost you something that does not appear on any invoice.

Human attention is the expensive input in this equation and always has been. Anything that reduces the number of times a person has to pick the work back up is worth several times its processing cost, and the calculation is not close enough to require a spreadsheet.

Try it this afternoon#

What I like most about this is that there is nothing to buy. No platform, no procurement, no integration work, no meeting.

Generate something the way you normally would. Open a completely new session. Paste it in with an instruction to review and improve it against whatever criteria matter, and be specific about the criteria, because "make it better" is as empty here as it is anywhere else. Read the two side by side.

I have watched people who were sceptical of this become quietly evangelical inside a week, which is the correct response to discovering something that costs nothing and works.

The people who insist a sufficiently well-crafted single prompt should be enough are making an argument about how the technology ought to behave rather than how it does. It is the same instinct that said spell-checkers would end the need for editors. The tool got better. The reason for the second pair of eyes never had anything to do with the tool.