Why We Don't Believe in Vibe Coding

There is a way of building software right now that the industry has given a name to, and the name is honest about what it is. It is called vibe coding. You describe what you want to an AI, in plain English, and it writes the code. You don’t necessarily read the code. You don’t necessarily understand it. You run it, and if it seems to work, you keep going. You are building by feel.

The term was coined by Andrej Karpathy in early 2025, and I want to be fair to him, because he was clear about what it was for. He described it as a way to build throwaway weekend projects, a delightful, fast, low-stakes way to make a toy. On that, he is completely right, and I am not here to be a grump about it. Vibe coding is genuinely wonderful for prototypes, experiments, personal tools, and learning. We use AI to write code constantly, and the speed is real.

What we do not believe in is using it to build the software a business is going to run on. And the reason is not snobbery about craft. It is that vibe coding, applied to something real, is one of the most expensive mistakes available right now, and it is being sold as the opposite. So let me explain why we start every real build with a plan, using the comparison I cannot stop reaching for, because it fits exactly.

You would never build a house this way

Picture hiring someone to build your house, and watching them show up with no architect, no blueprint, no permits, and no plan. They just start. They have a nail gun and a good feeling. You ask where the kitchen goes and they say they’ll know it when they see it. You ask if the upstairs is supported and they say it looks fine so far. Every single person reading this would stop that build before lunch, because the stakes are obvious and physical. A house is something you live inside. If the structure is wrong, it doesn’t matter how nice the paint is. It comes down, possibly on top of you.

Software your business depends on is exactly the same kind of object, and we have just been trained not to see it that way because the danger is invisible. Nobody watches a server and feels the load-bearing wall that isn’t there. But it works the same. The data your business runs on lives inside that software. Your customers’ information lives inside it. The thing has to hold weight, and whether it holds weight is decided by structure you cannot see from the outside, the same way you cannot tell a sound house from a deathtrap by looking at the front door.

Vibe coding is building the house with no architect and no blueprint. It is the nail gun and the good feeling. And for a treehouse, a toy, a weekend project, something nobody is going to live in, that is completely fine, even joyful. For the building your business operates out of, it is reckless, and the recklessness is hidden right up until the moment it isn’t.

”But it seems to work”

This is the trap, and it is worth naming precisely, because it is so convincing. Code built by feel very often seems to work. It runs. It does the thing in the demo. And that surface success quietly stands in for soundness, when the two are not the same and the difference is the whole point.

Here is what “seems to work” routinely hides. No security, because nobody designed any in. No handling for messy input, because the demo input was clean. No plan for what happens when two things go wrong at once, because in the demo nothing did. No thought about what an attacker could do, because the attacker wasn’t invited to the demo. The code that “works” can be missing every one of these and look identical, from the outside, to code that was built properly. You find out which one you have when the input gets messy, or the data gets valuable, or someone hostile shows up, which is to say, you find out in production, where the missing walls are most expensive to discover.

And it is not a hypothetical. In one widely reported case in 2025, an AI coding agent on a popular vibe-coding platform deleted a company’s live production database, during an explicit freeze when it had been told, repeatedly, to make no changes. It wiped records for more than 1,200 executives and over 1,190 companies, then, when asked, initially claimed the data could not be recovered, which turned out not to be true. Read that and sit with it, because it is the whole article in one event. The thing was fast. It was easy. It felt like magic. And there was no structure underneath it to stop the magic from doing something catastrophic, because nobody had built the structure, because the entire pitch was that you didn’t need to.

The plan is not the slow part. It’s the part that makes fast safe.

Here is the objection I hear, and it deserves a straight answer. Isn’t insisting on a plan just the old, slow way? Isn’t the entire point of AI that we can finally skip the heavy upfront process and move fast?

Half right, and the half that’s wrong is the dangerous half. AI genuinely has made the construction fast, the actual writing of the code is faster than it has ever been, and we lean on that hard. What it has not done, and cannot do, is make the plan unnecessary. A skilled crew with power tools builds a house fast. They do not build it faster by throwing away the architect’s drawings. The drawings are what let them move fast without building a deathtrap, because the hard thinking, where the walls go, how the load is carried, where the wiring and plumbing run, what happens in a storm, was done first, on paper, where mistakes are cheap to fix. Then the building is quick because the thinking is already done.

That is exactly our stance on software. The plan is not the enemy of speed. The plan is what makes speed safe. We do the architecture first, what the system is made of, how the parts connect, where the data lives, how it’s secured, what happens when a step fails, and then we let AI and skilled people build to that plan, fast. Vibe coding skips straight to the building and discovers the architecture by accident, in production, in the form of whatever breaks. We would rather discover it on paper, on purpose, before it is holding any weight. This is the same truth I wrote about from the cost side in how I burned through a week’s budget in a day and the effort side in why AI is not the one-click tool: the easy surface is real, and the engineering underneath it is what decides whether the easy thing is also a safe thing.

What we actually do

So when a business comes to us, we do not start by building. We start by drawing. We figure out what the thing actually needs to be, how its pieces fit, where the load-bearing walls are, how it stays secure, what happens when something goes wrong, and we write that down as a plan you can read and understand before a single line of production code is committed. That plan is the architect’s drawing for your software, and it is the thing that turns AI’s speed from a liability into an asset, because now the fast construction is building toward something sound instead of improvising structure as it goes.

That is, quite literally, what our Blueprint™ is. The drawing before the build. The decision, made deliberately and on paper, about how the thing will be put together so that when it is built fast, and it will be built fast, it is built right. You own and control what we build. We make sure what gets built has structure under it, because we have seen, in our own work and in the news, exactly what happens when it doesn’t.

The part worth carrying out the door

Vibe coding is a real and lovely thing, and we are glad it exists, for exactly the use it was invented for: toys, sketches, weekend projects, the joy of making something quickly that nobody has to depend on. The mistake, the genuinely costly, increasingly common mistake, is letting that approach across the line into the software a business runs on, where “I don’t know what the code does, but it seems to work” stops being charming and starts being the most dangerous sentence in the room.

You would never build your house by feel. You would want an architect, a blueprint, and someone who has done this before and knows where the walls go. Your software deserves the same seriousness, and it needs it for the same reason: because you are going to live inside it, and the structure you cannot see is the part that decides whether it holds. Build the toy by vibes. Build the business on a plan.