Here is a config an AI coding tool handed me, barely changed:
DATABASE_URL = "postgresql://admin:SuperSecret123@db.internal:5432/app"
API_KEY = "sk-live-4f9a..." # committed straight to the repo
It runs. That is the whole problem. It runs, the demo works, the reviewer nods, and that secret is now in your git history forever, readable by everyone on the team and anyone who ever breaches the repo.
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 move files around. What I have built, the entire time, is the ground the application runs on -- the hosts, the network, the databases, the plumbing. So when AI coding tools showed up and I started building again, I had to work out why my experience felt nothing like the failures everyone posts about.
Andrej Karpathy coined "vibe coding" in early 2025 and meant it honestly: give in to the vibes, stop looking at the code, let it grow past the point where you understand it. He was describing throwaway weekend projects. The internet kept the "forget the code exists" part and quietly upgraded it to "forget the system exists." Those are not the same thing. You can ignore the code. You cannot ignore the system, because the system is what is actually running.
What the model can't see
Every example below is something an AI tool suggested to me in a real session, and overrode -- not because I out-code the model, but because I had stood on that layer before and it had not.
It proposed Windows as the OS for a security app. Fine technically, wrong on cost and footprint -- a licensed Windows Server host where a free Ubuntu box did the same job lighter. The model has no concept of the bill, because the bill lives a layer below the code.
It reached for MySQL as the database. Also fine technically. But I am the one operating this thing long-term and at scale, and my experience is in Postgres, not MySQL. The model does not know who owns the system at 2am a year from now. Picking the engine I can actually run under pressure is an operational call, and operations is invisible from the application code.
It wired up auth and stopped at "login works." Working is the easy 20%. The locked-down version meant the single sign-on going through Microsoft Entra ID (formerly Azure AD) and fenced in with Conditional Access -- so "authenticated" means a trusted device, an allowed location, the right conditions, not just anyone holding a valid token. You do not discover Conditional Access by vibe coding a login form.
And networking. In the earlier days the confident move was always the same: open the port.
# what makes the connection work
ufw allow 22 # SSH, open to the entire internet
# what should have happened
ufw allow from 10.0.5.0/24 to any port 22 # scoped to the management network
Both versions connect. Only one of them is safe, and the difference is invisible from the application layer -- it lives in the network, which the model treats as someone else's problem.
Which brings it back to the secrets it tried to hardcode. The fix is not complicated. It is just a layer the model does not reach for on its own:
import os
DATABASE_URL = os.environ["DATABASE_URL"]
API_KEY = os.environ["API_KEY"]
Pulled from the environment at runtime, or out of a real secrets store. Passwords hashed, keys and tokens encrypted, none of it in source control. The model will inline all of it into a file headed for the repo unless someone who knows better stops it. I am usually the someone.
Nothing is siloed
You already know the stack is not two boxes. Frontend, backend, API, auth, database, cache, object storage, queues, reverse proxy, DNS, and a dozen more layers under that -- each failing in its own way and taking its neighbors down with it. That is the part the burned vibe coders miss. They are not, mostly, writing bad application code; the model is 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 self-contained from where they are sitting. Nothing is self-contained.
Why I argue with the machine
When I vibe code, the AI writes the application layer and I am still building everything underneath it -- and, more to the point, I know enough to push back. When the model picks an approach I can ask why it chose that, whether the obvious alternative is better, what it is trading away that it did not mention. You cannot question an answer you could not have reasoned about yourself. That is the dividing line, and it has nothing to do with how much code you personally type.
It changes how I start, too. I do not open with "build me X" -- that is what produces the demo that detonates in production. I spend half an hour talking through the problem first: the constraints, the tradeoffs, where the bodies are buried. Then I have the model write the best prompt it can for what we just worked out, and hand that to the coding agent. It writes a better spec for itself than I can 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 what keeps the next two hours from being a cleanup job.
None of this is anti-vibe-coding. It got me building for the first time in my career and it is not going back in the box. The problem was never the vibes. The problem is the self-contained change made by someone who cannot see what it touches, shipped to a system they could not draw on a whiteboard. 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. It is whether you understand the thing your code is standing on. Everything else is just vibes, and vibes do not hold weight.
What is the override you keep having to make -- the one the model gets wrong in your stack every single time?
Originally published at blog.vertexops.org.
