The winners were the easy ones to check

Building software got cheap, and the advice adjusted fast. Execution is a solved problem now, the argument goes, so your edge lives upstream, in discovery: figuring out which problem is worth solving. Get good at choosing, and the cheap machine downstream turns good choices into results. Knowing what to build is the whole game.

Then look at the companies playing it. Atlassian, the maker of Jira and Trello, surveyed executives in 2026: 89 percent said AI made their teams faster, and only 6 percent could point to AI paying off across the organization [reported]. The work sped up. Choosing got easier. The return never showed.

The shift underneath all of this is simple to state. For a long time the expensive part of building was doing the work: writing the code, drafting the copy, running the analysis. AI collapsed that cost toward nothing. But making a thing and knowing the thing is any good are two different jobs, and only one of them got cheap. Somebody still has to look at what the machine produced and decide whether it’s right, and that still takes a human’s time.

Three economists, Catalini, Hui, and Wu, put this on paper in 2026 under the flat title “Some Simple Economics of AGI.” They model the transition as two cost curves racing each other. The cost of generating output drops off a cliff, halving toward zero. The cost of verifying output barely moves, because it’s pinned to something that doesn’t scale: a person’s time and attention [verified]. The distance between the two curves is what they call the Measurability Gap, and they argue it’s what decides which kinds of AI products can ever make money [verified].

The AI products that broke out share something duller than good product instinct: their output is cheap for a human to check. That, more than any sense of what to build, is what sorted the winners from everyone else.

Look at what reached the frontier first: chatbots, image generators, coding assistants. They got there for an unglamorous reason. You can look at their output and know right away whether it’s any good [reported]. A wrong answer in a chat is obvious. A bad image is obvious. Code either passes its tests or it doesn’t. The output is cheap to inspect, so the whole product is cheap to run, so the economics close. The hard-problem story had little to do with it.

Martin Fowler, a veteran software-engineering writer, puts the practitioner version plainly. As the cost of generating drops to almost nothing, he says, the question stops being “how cheaply can we produce this?” and becomes “how do we check it at a scale that works?” [reported]. He sees three ways checking scales: you automate it with tests, metrics, and external audits; you let it mature, leaning on user feedback and benchmarks as the product grows; or you route it to experts who can look and know [reported]. A category that reaches one of those paths can be a business. One that can’t stays expensive to run no matter how capable the underlying model gets [reported].

That splits the world in a way the discovery story doesn’t see. Some outputs are cheap to check: code with a test suite, data pulled from a document, a formatted file. In those categories the old advice holds. Building is cheap, checking is cheap, and knowing what to build really is the constraint that separates winners. Other outputs resist checking: a strategy memo, a radiology read, a design nobody can put a number on. Subjective, high-context, high-stakes work only a scarce expert can judge. In those categories, every ounce of discovery discipline just produces more well-chosen things nobody can afford to confirm actually worked.

The fair objection is that none of this is a contradiction. Discovery and verification aren’t rivals; they’re two steps in one line. You decide what to build, you build it, then you check it. Naming the third step doesn’t erase the first. And the discovery bottleneck is real: teams do pour effort into the wrong things, and a separate survey of 500 product professionals, run by the product-tool maker airfocus, found the same shift toward deciding-what-to-build as the new hard part [reported]. For plenty of the chain, that reconciliation holds.

It breaks on the order. Verification isn’t the step after discovery. For whether a product can pay off at all, it comes first. You can’t rank options you can’t afford to check, so a category where checking is ruinously expensive was never viable, and no amount of disciplined choosing rescues it. Measurability is a gate in front of the whole discovery motion, not a stage you reach once you’re through it. That reframes the 6 percent. The companies showing real returns probably aren’t the ones with the best sense of what to build. They’re disproportionately the ones who happened to be working where the output was easy to check. Measurability sorted the winners before discovery got a vote.

This misdirects one team in particular. A company staring at a cheap-to-build product line that won’t turn a profit gets told to invest in discovery discipline. If its real problem is that its category’s outputs can’t be checked without burning a scarce human on every one, it will build a sharper prioritization process and watch the returns stay flat. More prioritization is spend against the wrong constraint. The barrier is a verification cost, and no roadmap closes it.

Hold the confidence where the evidence sets it. The two-curve mechanism is on solid ground [verified]. The claim that checkability beats good discovery for deciding what pays off is an argument built on that ground, not a measured result. The verification-first case rests on one economic paper and one practitioner essay, both days old, and its own authors admit they don’t yet know whether measurability predicts a product’s success before it launches [reported]. The account of which products clustered at the frontier is reported, not audited. All of that is plenty to retire “do you know what to build?” as the entire contest. It isn’t enough to call discovery a distraction.

So the question worth arguing now is a straight race. Does a team with mediocre discovery in a checkable category beat a team with excellent discovery in an uncheckable one, measured on durable returns instead of speed? The old view and the new one both hang on that single comparison, and it’s one somebody can actually run. Until it’s run, the useful move is to find out which side of the gate your own product sits on. Is there a test, a metric, or an expert who can glance and know whether the output is right? That one property may say more about whether the thing ever makes money than the quality of anything on your roadmap.