Spin the Wheel: The Ground Reality of Rushed Applied AI

"Is this it? Is this what the AI hype is about?"

I hear it often from frustrated Boards and CEOs, and it usually arrives with the same story. A handful of engaged employees have become LLM power users. Two existing vendors bolted an AI layer onto their SaaS product and raised the subscription. Then someone approved a prototype. A freelancer, a few days, a small invoice, and a working solution arrives.

It works for a week. Then the outputs start to differ from one day to the next and nobody can explain why. The run cost stays a mystery until the charge for extra credits lands. A data source changes, an API moves, and the solution stops. The freelancer is on to the next job already.

I picture the situations businesses land in with AI as a wheel of misfortune. Opaque logic, cost overruns, data leakage, pilot purgatory, and six more segments like them. Rushed applied AI is a spin of that wheel, and it has no winning segment. The only open question is where the pointer stops first. Spin it yourself and see where you land.

In defence of the two-day build

I like vibe coding, and I use it. Andrej Karpathy gave the practice its name in early 2025, and I know of no cheaper way to settle one question: can this be built? A proof of concept that once needed a quarter and a steering committee now needs a champion on the team and two days. Every business should have vibe coding in its arsenal for prototyping.

The pattern I see goes wrong one sentence later, when someone in the meeting says, "It works, so let's roll it out."

A homeowner can ask an LLM how to change a fuse and will manage it. Nobody concludes that the same homeowner should rewire the house. We call a licensed electrician, because wiring has failure modes that stay hidden until something is already on fire. Software that runs a live process in an established business is wiring. It sits inside pricing, claims handling, credit decisions and service recovery, and it touches customers, regulators and the P&L every hour.

Jason Lemkin, the founder of SaaStr, documented his own version in public. As TechTarget reported, his Replit agent acted without permission during a code freeze and deleted the production database. Replit's CEO responded by pledging automatic separation between development and production databases. Lemkin's project was a test, and he said so. An established business running a live process on the same kind of build has no such cushion.

A prototype proves an idea can be built. Whether the business can run on it is a separate question.

The vibe coding invoice is just the start

The small invoice covers the build. Running it is a separate bill, and that bill has no end date.

Picture an agent that spends €1 of inference to search a static file on every run, when a simple lookup would cost a fraction of a cent. Quick builds make this choice constantly. They reach for the most powerful tool available over the right one, because nobody was thinking about unit economics at build time. Usage then multiplies the miss. The more people rely on the prototype, the more the original shortcut costs, and the business ends up penalised for its own adoption. That is the cost overruns segment, and most teams land on it before they know the wheel exists.

What nobody vetted

Ask where the two-day build runs. The usual answer is a personal account on a platform nobody in the business has reviewed, with customer data passing through it and credentials sitting in a file.

A Board that would never allow an unvetted supplier near customer data lets this one through because it arrived labelled as innovation. Data leakage is the one segment where the pointer can stop without anyone noticing. The exposure exists from the first run, whether or not anyone has been caught.

One laptop, one person

The inconsistent outputs have a simple explanation. Nothing in the build was instrumented, so nothing recorded why Tuesday's answer differed from Monday's. Quick builds run on a single machine with no load handling, no redundancy and no separation between environments. They fail often, and they fail in ways that resist diagnosis. Opaque logic and inconsistent performance sit side by side on the wheel for good reason.

Six months in, with no tests, no documentation and no architecture, every change is a gamble and every fix is a walk through someone else's unlabelled wiring. The speed that impressed everyone in week one has by then cost the business more time than it saved.

The outcome that worries me most is the conclusion the Board draws. It watches the prototype die and decides that AI does not work for this business. The technology takes the blame for the way it was approved, and the next good idea never gets funded.

What to ask before you approve the next AI build

Here is the good news in every one of these stories. The business learned, for the price of a small freelancer invoice, exactly what was missing: an AI owner and an intentional AI design. That is cheap tuition, and the freelancer who delivered it did what was asked.

Before you approve the next AI build, ask for three things. Each one takes segments off the wheel.

The owner. One named person inside the business who owns the solution, fixes it and improves it, with the time to do so written into their role. An owner is the difference between a solution that stops and one that gets repaired by Thursday.

The one number. The single metric AI has to move, agreed before the build starts and measured after. If nobody can name it, "no clear ROI" is already the result.

The design. An AI design that is intentional, transparent and pressure-tested, with the levers a business must control: cost, logic and an audit trail. A good design answers four questions on paper. Will this run reliably in six months? Will it survive an audit? Will it handle our real data volumes? Does it work without one person's laptop?

Then do one thing this week. List every AI build running in the business today and mark each one a demo or an initiative. Most leadership teams I work with are surprised by how many demos are quietly doing production work.

Keep the two-day builds coming. They remain the fastest way to find out what is worth designing properly.