Fail Fast, Fail Often in the Age of AI
Hypothesis-driven innovation vs. build-first, ask-later.
What “fail fast” means, and where it came from
“Fail fast” is the idea that when something is going to go wrong, you want to find out immediately and cheaply, not late and expensively. It started as an engineering principle, and later became a business slogan.
The engineering version is older. In 1985, Jim Gray, writing about fault tolerance at Tandem Computers in Why Do Computers Stop and What Can Be Done About It?, described “fail-fast” modules: components that either work correctly or stop the moment they detect a fault, instead of limping along and corrupting everything downstream. Jim Shore brought the phrase to everyday programmers in his 2004 IEEE Software article “Fail Fast,” arguing that code should raise an error at the point of the problem, not several layers away where it is hard to trace.
The business version took off in the 2000s and 2010s, as Silicon Valley absorbed the lessons of cheap, rapid experimentation. Steve Blank's customer development and Eric Ries's The Lean Startup (2011) made the argument that a startup's job is validated learning: run the cheapest experiment that could prove you wrong, and change course quickly. Facebook's “move fast and break things” was the same instinct, in cruder form. “Fail fast, fail often” is the bumper-sticker version of all of it.
Both versions rest on the same condition: a failure only helps if you can see it and learn from it. Keep that in mind for what follows.
Why this matters now
Before AI coding tools, building was expensive. A new product or feature meant weeks of engineering time, real money, and a team betting its quarter on the outcome. That cost was a forcing function. It made us stop and ask the uncomfortable questions before committing:
- What do we believe is true?
- What would have to be true for this to work?
- What's the cheapest way to find out if we're wrong?
So we ran the smoke test, did the customer interviews, faked the button and counted clicks. We proved (or killed) the hypothesis first, then built.
The Zappos test
The best-known example is Zappos. In 1999, Nick Swinmurn had a hypothesis: people would buy shoes online, without trying them on first. Testing it the obvious way meant building an inventory, warehouse and fulfillment operation for a business that might not work.
He didn't do that. He went to local shoe stores, photographed the shoes on their shelves, and posted the photos on a simple website. When someone placed an order, he went back to the store, bought the pair at full price, and shipped it himself. He lost money on every sale, and it didn't matter. He wasn't testing logistics or margins. He was testing one question, whether strangers would pay for shoes they had only seen in a photo, and he got his answer before he had anything to sell.
The answer was yes. The site, first called ShoeSite.com, became Zappos, and Amazon bought it in 2009 for a reported $1.2 billion. Look at what the test had: a single belief, a cheap way to prove it wrong, and a result that couldn't be argued with. That is what a hypothesis buys you.
The opposite of Zappos: Humane
Humane's AI Pin is the other side of that story. The company had a big hypothesis: people would want to replace their phone's screen with a screenless, voice-driven AI device worn on a lapel. Tested honestly, that is a question about behavior. Will people talk to a pin in public, wait for it to answer, and give up the screen they already trust? You could have started answering that with a rough prototype and a few dozen real users carrying it around for a week.
Humane went the other way. It spent years and raised hundreds of millions of dollars on custom hardware, a laser display, and a cloud service, then launched at $699 with a monthly subscription in 2024. The first moment a customer could clearly say no was after the hardware existed, the inventory was built, and the money was spent. Reviews were harsh, and returns reportedly cut into sales. In February 2025, Humane sold its team and technology to HP for $116 million and shut the device down. The Pins stopped working within days.
The idea may well have been wrong. The problem was how long it took to find out. A fast, cheap test could have shown the same thing in weeks. Instead, the cost of being wrong was the whole company. Zappos paid almost nothing to learn that its hypothesis was true. Humane paid everything to learn that its hypothesis was false.
That is the lesson for the age of AI, and it has nothing to do with whether AI wrote the code. When building is cheap, you can run a Zappos-style test of nearly any idea. The Humane mistake is now a choice, not a necessity.
The other failure: 128 releases, zero users
Humane failed because testing the idea was expensive. There is a newer way to fail that only exists because building got cheap. In a postmortem published in August 2026, solo founder Gus Chiriboga described using AI coding agents to build a tool for supervising AI coding agents. He published 128 releases to npm and Homebrew, with CI, contract tests, documentation in two languages, and governance policies. He had zero external users.
His second attempt went the same way. He built an orchestration engine with 442 passing tests and 15 validation scenarios. Then he used it for real, and it broke in ways none of the tests had caught. Approval gates couldn't be approved, and the command line reported that work was complete while the pipeline sat stalled. By his own account, the tests checked the system against his own model of how it should behave, not against how anyone would actually use it.
After about two years, he diagnosed the problem himself: both projects stalled before reaching real users, and technical work was how he avoided that step. His words: “Agents make building so cheap that building becomes the procrastination.” And: “Tests validate your model of the system. Only strangers validate the system.”
This is the failure the title is about. Failing fast doesn't mean building quickly. He built quickly for two years and learned almost nothing, because he never put the work in front of anyone who could say no. His next milestone is a small one: get 25 people to leave their email. That is a Zappos-sized test of whether anyone cares, and it could have come on the first day.
Now building is nearly free
An AI agent can spin up a working prototype before lunch. Somewhere along the way, a lot of us quietly dropped the fundamentals. The new loop is: build it, ship it, see what happens. “We'll learn from the data.”
The problem is that you can't learn from data when you never wrote down what you expected. Without a hypothesis, every result looks like a signal, and nothing ever clearly fails. We end up with a graveyard of half-used features, each one “kind of promising,” none of them teaching us anything.
That is the catch in “fail fast, fail often.” Failing only counts if you can tell that you failed. Failing fast is cheap now. Failing legibly is still on you.
Thinking is the scarce resource
Cheap building didn't make thinking optional. It made thinking the only scarce resource left. The cost of a bad idea used to be engineering time. Now it's focus, maintenance, user confusion, and a product nobody can explain.
Before the next build
- Write the hypothesis in one sentence: “We believe [user] will [behavior] because [reason].”
- Define what success and failure look like before you ship.
- Pick a kill date.
Let the agents build fast, and fail fast and often. We still have to decide what's worth building, and to notice when the answer was no.
So write the hypothesis, set the kill date, and put your work in front of a stranger this week. Every small, honest failure is a course correction, and course corrections are how you reach the moon. You have the most powerful building tools anyone has ever had, so aim them at the right thing. Fail fast, fail often, learn something every time, and then watch what you build take off. See you up there. 🚀