Vibe Coding Isn't the Problem. Not Understanding the Stack Is.

I am not a developer. Twenty years in systems engineering and I have never shipped a real application, never owned a production codebase, barely wrote a shell script that did more than shuffle files from one place to another. What I have done, the entire time, is build the ground the application stands on. So when AI coding tools showed up and I found myself building things again -- actually building, not just keeping other people's builds breathing -- I had to sit with why my experience of it felt nothing like the horror stories.

Because the failures everyone is posting about are real, and it helps to remember where the term even came from. Andrej Karpathy coined "vibe coding" in early 2025, and his original description was the honest version: give in to the vibes, stop thinking about the code at all, let the thing grow past the point where you even understand it. He meant it for throwaway weekend projects. Low stakes, nothing load-bearing. That nuance did not survive contact with the internet. What survived was "forget the code exists," and a lot of people heard it as "forget the system exists." Those are not the same forgetting. You can ignore the code. You cannot ignore the system, because the system is what is actually running when the code does its thing.

Let me make this concrete, because I do not want to point at other people's wreckage from a safe distance. Every example below is something an AI tool suggested to me, in a real session, that I overrode. Not because I am smarter than the model, but because I had stood on that particular layer before and the model had not.

I was building a security app, and the first thing it proposed was Windows as the operating system. For this workload that was the wrong call on cost and resources both -- a licensed Windows Server footprint where a free Ubuntu host did the same job with less overhead. The model was not wrong that Windows could run it. It had no concept of the bill or the resource budget, because that lives a layer below the code. We are using Ubuntu, I told it, and we moved on.

On another build it reached for MySQL as the backend. Nothing wrong with MySQL on the technical merits -- it would have done the job fine. But I am the one maintaining this thing long-term and at scale, and my database experience is in Postgres, not MySQL. The model has no idea who owns the system after it is built. It optimizes for the task in front of it, not for the person who has to keep the thing running at 2am a year from now. Picking the database I actually know how to operate under pressure was the right call, and it had nothing to do with which engine is "better" in the abstract. That is an operational judgment, and operations is a layer the application code never sees.

I built a web page with authentication, and getting auth to work is the easy part. The model will happily wire up a login. Getting it locked down is the part nobody mentions. That meant making sure the Microsoft Entra ID single sign-on was actually configured correctly and fenced in with Conditional Access, so that "logged in" meant logged in from a sanctioned device under the right conditions, not just anyone holding a valid token. Conditional Access is not something you discover by vibe coding a login form. You either know that layer exists or you ship a door with a good lock and no walls around it.

The networking stack has saved me more times than I can count. In the earlier days especially, the confident advice was routinely to just open the port -- SSH to the world, reachable from anywhere, come one come all -- because that makes the connection work, and the model optimizes for the thing working. Knowing how the network actually fits together is what let me say no and scope the access down to where it should have been in the first place. The connection working and the connection being safe are two different success conditions, and only one of them is visible from the application layer.

And the one that comes up over and over: secrets in plain text. Tokens, API keys, passwords, dropped straight into a config file because that is the path of least resistance and it runs. Passwords belong hashed. Keys and tokens belong encrypted or in a secrets store, pulled in from the environment, never committed to source control. The model will cheerfully hardcode all of it into a file headed for the repo unless someone who knows better stops it. I am usually the someone.

Here is the thing those five have in common, and it is the whole argument. When most people say "full stack" they mean frontend and backend. A UI and the thing behind it. Two boxes. But the stack I have lived in for two decades has source control underneath it, and an application layer that splits into frontend and backend, and an API layer negotiating between them, and authentication and authorization deciding who is allowed to touch any of it, and a database, and a cache in front of that database because the database will fall over under real load without one, and object storage for the things that have no business being in a database, and a queue for the work that cannot happen inside a request, and a web server and reverse proxy routing every bit of it, and DNS so anyone can find the thing at all. That is not the full list. It is not close. There are several more layers under that, and every one of them fails in its own particular way, takes down the layers next to it in its own particular way, and has to be secured in its own particular way.

The vibe coders who get burned are not, mostly, writing bad application code. The model is genuinely good at application code now. They get burned because they think the application code is the system, when it is one floor of a building whose foundation they never poured and cannot see. The change looks siloed from where they are sitting. Nothing is siloed. That is the lesson the foundation teaches you, and it is the one you cannot get from the application layer looking down.

So when I vibe code, it is a different activity wearing the same name. The AI writes the application layer. I am still building everything underneath it, the way I always have, and -- more important -- I know enough to argue with the machine. When the model picks an approach, I can ask why it chose that one, whether the obvious alternative is better, what it is trading away that it did not mention. You cannot push back on an answer you could not have questioned in the first place. That is the real dividing line, and it has nothing to do with how much code you personally type. It is whether you can tell when the confident answer is wrong.

It shows up in how I start, too. I do not open a session with "build me X." That is the move that produces the demos that explode in production. I spend half an hour first, just talking through the problem -- what I am actually trying to do, what the constraints are, where the bodies are likely buried. Then I have Claude write the best prompt it can for the thing we just talked through, and I hand that prompt to Claude Code. The model is better at writing the spec for itself than I am at writing it cold, but only after a human has done the thinking the spec is supposed to capture. The thirty-minute conversation is not overhead. It is the part that keeps the next two hours from being a cleanup job.

None of this is an argument against vibe coding, and I want to be clear about that, because the easy read of a piece like this is "old infrastructure guy tells the kids to get off his lawn." That is not where I am. Vibe coding got me building for the first time in my career. It is a real accelerant and it is not going back in the box. The problem was never the vibes. The problem is the siloed change made by someone who cannot see what it touches, shipped to a system they could not draw on a whiteboard if you asked them to. Give the same tools to someone who knows the foundation, and the foundation is exactly what makes the vibes safe to follow.

The dividing line is not talent, and it is not how much code you write yourself. It is whether you understand the thing your code is standing on. Everything else is just vibes, and vibes do not hold weight.