It's Not the Speed That Kills You

There's an old comedy sketch that simulates Peter Solberg being interviewed about rally driving in bad English. He's asked if he's afraid of the speed. He answers: "You know -- it's not the fart that kills you, it's the smell."

In English that sounds like something else entirely. But in Swedish you hear what he actually means: it's not the speed that kills. It's the crash.

And that's exactly what's happening in the AI world right now.

The Speed Is Real

What's happening is genuinely impressive. A project manager connects Claude to a project management tool and builds a dashboard that automatically compiles capacity, velocity and budget outcomes -- work that previously took hours every week. Someone else builds a tool with a name configurator, marketplace and payment flow in a morning. Things are being created that didn't exist before.

That's not hype. It's real acceleration. And it works -- not because Claude is magical, but because the person behind it knows exactly what they want to achieve. That knowledge is what makes the instructions precise. The tool is not the reason. The person is.

What the Crash Reveals

It's not the vibe-coding that's the problem. It's what happens when it stops working.

A payment gets stuck. A configuration disappears after an update. A bug appears in an edge case nobody tested. The Jira connection loses data. The infrastructure that was never set up properly.

Who handles it? Who tracks down the bug in code that AI generated but you don't fully understand? Who reconfigures the environment when it fails?

That's not a hypothetical problem. That's the crash. And in the crash you find out who actually owns the system -- and who was just along for the ride when everything went right.

The Last Mile Can't Be Faked

You can build quickly to seventy percent. That's real. Impressive. Worth celebrating.

But the last mile -- the production environment, the error handling, the scaling, the accountability when something doesn't add up -- that requires you to understand what you're delivering. Not because you had to write every line. But because you need to be able to step in when it stops. Find where. Understand why. Make a decision.

The last mile is not a technical problem. It's a domain knowledge problem. It's the difference between having driven a car and understanding what happens under the hood when it breaks down.

What This Actually Means

This is not an argument against building. It's an argument for knowing what you own and what you don't.

Build. Experiment. Prototype in a morning. That's right. But don't put a production system into service if you can't answer: what happens if this breaks? Who fixes it? Have I understood every part well enough to own the consequences?

It's not the speed that kills. It's the crash.

And it's in the crash you get the answer to whether you actually own what you built.

See also: The One Who Succeeds With AI Isn't Who You Think (series 18) and You Can't Validate What You Don't Understand (series 6).