Why 'Almost Right' Is the Worst Output

There is a peculiar disappointment that comes with receiving almost-correct work. An AI tool generates a function that does 90% of what you wanted, with a subtle issue in the remaining 10%. A design assistant produces a layout that's close to what you asked for, but slightly off in ways you can't immediately articulate. A code suggestion is almost the right pattern but inverts a condition. You sit there looking at it and notice that it would somehow have been easier if it were completely wrong.

That feeling isn't just psychological. It's structural. Nearly-correct output is, in a real sense, harder to fix than blank-slate output, and this has profound consequences for how teams work with generative tools.

The economics of "almost"

When you start from nothing, you make decisions one at a time. You know what you're doing because you're doing it. Each line of code, each element of layout, each word of copy is placed deliberately, and you remember why.

When you start from a near-right draft, you have to do two things simultaneously. You have to understand what the draft is doing. And you have to identify where it deviates from what you actually want. These are two distinct cognitive tasks, and the second one depends on completing the first. You can't fix what you haven't finished reading.

The naive assumption is that editing is cheaper than writing. For high-level structural decisions, this is true — it's easier to react to a draft than to produce one from scratch. But for fine-grained decisions, editing is often more expensive because you have to reconstruct the author's intent before you can even begin to modify their work. When the author is an AI with no actual intent, the reconstruction is an archaeology without a site.

The disfluency of near-matches

There is a specific cognitive pain that comes from a near-match. Your brain recognizes it as almost-what-it-wanted, but can't immediately locate the deviation. You look at a layout and know something is wrong, but you don't know what. You read a paragraph and know it isn't quite the right voice, but the words themselves are all acceptable.

This creates what psychologists call disfluency — a background cognitive friction that makes simple tasks feel hard. You spend minutes examining a two-line function because your brain won't let you accept it as correct without locating the specific issue. You re-read a paragraph three times. You scroll up and down a page looking for something that is irritating you but won't name itself.

Blank-slate work doesn't trigger this. You look at an empty page and you know where you stand.

Why AI loves the almost-right

The "almost right" output is not a bug in the AI. It's a consequence of how these systems are trained. They learn the shape of acceptable answers. They produce outputs that are plausibly shaped like the thing they were asked for. They optimize for the mean of what similar outputs look like, which is an excellent strategy for being mostly correct most of the time.

But "shaped like the right answer" is exactly the failure mode that triggers disfluency. The output is structurally right. It has the right ingredients. Its surface cues suggest it should be fine. It's the content underneath the surface that's subtly wrong.

The classic example: an AI writes a function that passes the tests you didn't write, fails the edge cases you didn't think of, and handles the common path perfectly. When the edge case bites in production three weeks later, you try to debug the function and discover that every line of it is superficially reasonable, which is why nobody caught the issue in review.

The cost multiplier

A useful way to think about this: when AI is wrong, the cost of fixing it scales with how close to right it is, not how far from it.

• Completely wrong output: throw it away, start over. Cost: the cost of doing it yourself.
• Mostly wrong output: use the structure, rewrite the contents. Cost: slightly less than doing it yourself.
• Almost right output: scrutinize every detail to find the 10% that's wrong. Cost: often more than doing it yourself, because scrutiny is slower than writing from scratch.

This is counterintuitive. We assume that quality output should be cheaper, not more expensive. But for generative tools, "quality" and "velocity" decouple at the margins. A merely competent AI can speed you up by taking the dull parts off your plate. A highly competent AI can slow you down by producing output that requires forensic examination.

Where this bites

Almost-right AI output is most costly in three specific places.

Visual layout. AI-generated UI is almost always structurally reasonable and aesthetically mediocre. It has the right components in the right order, and none of the surface polish that makes software feel considered. The specific deviations are hard to name because they're small — a gap that's two pixels too wide, a heading that's one weight too heavy, an icon that's aligned geometrically rather than optically. Each is individually trivial. The sum is what makes the output feel generic.

Configuration code. An AI writes a Terraform module or a Docker compose file that looks fine. It works in the happy case. Three weeks later, you find that it misconfigured a health check in a way that doesn't appear until production load, and the reason you didn't catch it is that the module is 200 lines of reasonable-looking declarations, each of which individually passes review.

Prose. Marketing copy, documentation, emails. The AI's version sounds like writing. It has paragraphs and sentences and topic structure. What it doesn't have is the specific voice of the person it's supposed to be from. You read it and it sounds like someone else wrote it, but you can't say why, so you either ship it and feel weird, or you rewrite it and wonder why the AI didn't just save you the time.

Strategies that actually work

If you're going to use generative tools, the useful question is not "how do I stop getting almost-right output?" — you won't. The useful question is "how do I reduce the cost of editing almost-right output?"

Some things that help:

Ask for more draft, less polish. A chunkier, more obviously-incomplete draft is easier to edit than a smooth, nearly-finished one. "Give me the rough structure of this, don't worry about the details" is often a more productive instruction than "make this production-ready."

Review with fresh eyes. Disfluency compounds with fatigue. Almost-right output needs a rested reader. The version of you at 4 pm cannot catch what the version of you at 10 am will.

Compare against a reference, not against intent. Humans are bad at catching deviations from an internal mental model. We are much better at catching deviations from an external reference. When possible, put the AI's output next to a known-good example of what it should be, and let your eye do the diff.

Ship it broken or don't ship it. The worst option is the midway state where the output is good enough to feel shippable but bad enough to feel wrong. Either commit to the remaining work and fix the output fully, or discard it and write the piece you care about yourself. Drifting in the middle is where most of the pain lives.

Develop taste explicitly. The ability to spot almost-right failure is a trainable skill. It's the skill of noticing. Practice happens by comparing drafts to finished work, by reading about what good looks like, and by building the vocabulary to name small deviations. The vocabulary is what lets you fix the output instead of just feeling that it's wrong.

The underlying point

Generative tools are extraordinarily useful. They are also subtly costly in a way the usual productivity narrative doesn't capture. The cost shows up in an editing phase that is harder than it looks, on work that is "almost done" in the way that something almost-done is the worst kind of done.

The remedy is not to stop using the tools. It's to accept that editing almost-right output is the main work, and to build the skills that make the main work fast. Reading quickly. Naming deviations. Keeping energy for the parts that matter. That work does not get outsourced. It is the work.