A perfectly-tested, perfectly-deployed feature that nobody wanted. Every rung of the ladder from Part 1 passed clean, and it still failed, because the failure was sitting above the top of the ladder the whole time, not anywhere inside it. On the business side, the same shape shows up as a fully-executed launch: the landing page converted, the ads ran on budget, checkout worked fine, and the product still didn't sell. Nobody checked demand before building any of it.

Tying back to the ladder

Every rung in Part 1's ladder, and the queue sitting behind it, only has value if the thing waiting in that queue was worth building in the first place. This post is about a check that sits above rung one, before anything even enters a queue. Skip it, and you can end up with a perfectly small, perfectly fast queue, full of work absolutely nobody needed.

Not the same thing as shift-left

Shift-left testing says catch the bug closer to where it was introduced, and that's still an idea operating inside a given loop. What we're talking about here sits a level above that: check whether this loop should exist at all before you enter it. In business terms, it's the difference between QA on a campaign and asking whether the campaign should run in the first place.

Most process advice moves bottom-up: better unit tests, better integration tests, better deploys. On the business side it's the same climb — better copy, tighter targeting, faster follow-up. We'd argue for checking top-down first instead. Sanity-check the business idea, or the customer demand, before you spend effort making something correct that never should have been built or sold at all.

Why this is newly urgent

Two writers landed on almost the same name within a month of each other in mid-2026, so we're citing both instead of picking one. Addy Osmani's "Loop Engineering" (June 8, 2026, later republished on O'Reilly Radar) lays out the progression first: prompt engineering in 2023 gave way to context engineering in 2024, then use engineering in 2025, and now loop engineering in 2026, systems that find work, delegate it, verify it, and iterate largely without a human standing in the middle of each step. Vikas Udasi's essay of the same name, published about six weeks later, tracks the identical progression and quotes Boris Cherny of Anthropic: "I don't prompt Claude anymore. I have loops running that prompt Claude."

Once that's true, the bottom of our ladder — syntax through deploy — can run on its own for hours before a human even looks at it again. On the business side, cheap ad platforms, no-code tools, and outsourced agencies are already doing the same thing: they make it just as fast to fully execute a bad idea as a good one. Either way, getting the top of the ladder wrong — the idea itself — now accounts for most of the total waste. The bottom no longer slows anyone down enough to force a second look.

There's a necessary complication here. Maxi Contieri's response piece, "The Dirty Secret Behind Loop Engineering" (HackerNoon, late June 2026), argues the loop itself isn't new at all. It's Kent Beck's red-green-refactor cycle from 2003, just handed to an agent instead of a person: "What changed isn't the technique. What changed is who runs the loop." That's a fair check on both Osmani and Udasi. It doesn't undercut the point here. If anything it sharpens it: the loop was always going to run, cheaply and fast, whether or not the idea inside it deserved to.

A simple check before you descend

Three or four cheap questions. Asked before writing a line of code, or before a campaign, a hire, a new market. Does this serve a real user? Is this the least effort for the outcome? Would skipping it cost more than doing it?

We've each got our own version of this. Ian's: a short "Growth Gate" before any engineering work starts, three questions, answered in writing, before a line of code gets written. Parni's is slower and more skeptical by design, because a research org can burn a whole quarter chasing a bottleneck that turns out not to matter: is this barrier real, is removing it actually tractable, and would the removal matter to anyone who isn't us. Neither gate does the same work. Both stand between an idea and the machinery that would otherwise just go execute it.

"Wasting time," "wasting tokens," and "wasting budget" are now the same sentence in an AI-native org. Checking first principles is a real cost control on an engineering budget and a marketing budget alike, not just a good habit worth having.

Checking the idea at the top is one loop. Building the machine that lets you check ideas and ship them at all is a different loop entirely, and mixing the two up is where both engineering roadmaps and business roadmaps go wrong. That's Part 4.

First Principles Before Feedback Loops