Why Most AI Projects Fail Before They're Built

A few years ago I watched a small company spend four months building something they did not need. They had money, they had talent, and they had one of the better models available at the time. What they did not have was a clear sentence describing what the thing was for. Every meeting produced a new feature. Every new feature produced a new question. By the fourth month the product had grown a settings page with nineteen switches, and nobody could explain what happened when you turned any of them off.

The postmortem blamed the technology. It usually does. The model was too slow, the outputs were inconsistent, the tooling was immature. All of that was partly true and none of it was the cause. The cause was that the project had been built before it had been decided.

Most failed projects were never really attempted. They were guessed at, repeatedly, in expensive increments.

Speed exposes the absence of intent

AI-assisted development has removed a friction that used to protect us. When building was slow, ambiguity surfaced early and cheaply. You could not write ten thousand lines of the wrong thing in an afternoon, because you could not write ten thousand lines in an afternoon at all. The cost of construction acted as an unintentional editor. It forced a certain amount of thinking, simply because thinking was cheaper than typing.

That editor is gone. A vague instruction now produces a working artifact in minutes. The artifact looks finished. It has navigation and states and a plausible empty screen. And because it looks finished, it invites feedback about the wrong things — colors, copy, placement — long before anyone has agreed on what the product is supposed to do for the person using it.

This is the quiet trap of the current era. The tools are good enough to make undecided work look decided. Teams mistake the appearance of progress for progress, and they keep mistaking it until the day they try to ship.

What is actually missing

When I am brought into a stalled project, I look for four absences, and I almost always find at least three of them.

The first is a stated purpose that survives contact with a stranger. Not a mission, not a tagline — a sentence that a person outside the company could read and correctly predict what the software does and who it helps. If two people on the team write that sentence separately and the sentences disagree, the project is not ready to be built. It is ready to be discussed.

The second is a described user in a described moment. Not a persona with a stock photograph and a favorite coffee order, but a specific human at a specific point in their day, with something specific going wrong. Software is a response to a moment. If the moment is fuzzy, every decision downstream becomes a matter of taste, and matters of taste are settled by whoever is loudest.

The third is a decision record. Every project accumulates dozens of small choices that seem obvious when made and inexplicable three weeks later. Why does onboarding ask for a phone number? Why is the free tier limited by projects rather than seats? Without a written record, teams relitigate these constantly, and each relitigation costs a day and a little more trust.

The fourth is a definition of done that is not a feeling. Done is not when the backlog empties. Done is a described state of the product: these flows work, these edge cases are handled, this is what a good first session looks like. Teams without this definition drift, because there is nothing to drift away from.

The blueprint

What I write before building is not a specification in the old sense. Specifications tried to describe every screen and every branch, and they failed because software is discovered as much as it is designed. A blueprint is smaller and more durable. It fixes the things that should not change and deliberately leaves loose the things that should.

It contains the purpose sentence. It contains the user and the moment. It contains the shape of the information — what objects exist in this world, what they are called, how they relate. It contains the voice, because voice is a structural decision and not a coat of paint. It contains the boundaries: what this product will never do, which is often more clarifying than what it will. And it contains the sequence, because the order in which you build determines what you learn and when.

Writing it takes a few days. Those days feel unproductive to people who measure productivity in commits. They are the highest-leverage days in the project, and the evidence is unambiguous: a project with a blueprint absorbs a change of direction in an afternoon. A project without one absorbs it in a rebuild.

A blueprint does not slow you down. It moves the confusion earlier, where it is cheap.

The instruction is the interface

There is a particular reason this matters more with AI-assisted work than it did before. When a person builds something for you, they compensate for your ambiguity. They notice the contradiction between what you said on Tuesday and what you said on Thursday, and they ask. Compensation is invisible labor, and we relied on it more than we realized.

A model does not compensate. It resolves ambiguity confidently and silently, in whatever direction the phrasing happened to lean. Every unstated assumption becomes a decision made on your behalf. This is not a flaw to be engineered away; it is the nature of the interaction. The remedy is upstream. If you want a system to build the thing you meant, you have to have meant something precise.

Which is why I have stopped thinking of the written plan as project management. It is the interface. It is the part of the work where the product actually gets designed. The construction that follows is real work, but it is downstream work, and its quality is capped by the clarity above it.

A smaller way to start

None of this requires ceremony. If you are about to begin something, try one exercise before you open an editor. Write the first session. Not a feature list — a narrative. A named person arrives at your product for the first time. Describe what they see, what they do, what happens, and how they feel at the end of four minutes. Write it in plain prose, a page at most.

The page will be difficult to finish, and the difficulty is the point. Every place you stall is a place where the product is undecided. Most people discover, somewhere in the third paragraph, that they do not know what the product is for. Discovering that on a page costs an hour. Discovering it in month four costs the project.

The company I mentioned at the start eventually shipped. They shipped after they threw away the settings page, wrote a single sentence about who they were serving, and rebuilt in five weeks what had failed to converge in four months. The model they used was, by then, a generation behind the newest one. It made no difference at all.

If you are in the quiet weeks before a build and you are not sure the thinking is finished, that uncertainty is worth taking seriously. It is usually correct. I am always glad to talk through what a project is really for, whether or not anything comes of it.