A few weeks ago, a colleague showed me his side project — already live, already running his business. Built entirely with Claude, no prior dev experience, just prompts and vibes.
I asked him one question: "What stack is it running on?"
He didn't know. Not vaguely — genuinely had no idea what language the backend was written in, what database it used, or how authentication worked. A real product, real users, real data. And he couldn't describe the system to another human being.
The Real Danger Isn't the Code Quality
Most critiques of vibe coding focus on code quality. That's not the point.
Claude and GPT-5 can produce clean, idiomatic code for well-defined problems. The real danger is the absence of understanding at every layer of the system. When the app breaks — and it will — he won't know where to look. When a security researcher finds an IDOR vulnerability because the AI never scoped queries to the authenticated user, he won't know what that means. When the database times out under load due to missing indexes, he won't understand why.
The AI gave him a car. He doesn't know how the engine works. That's fine until it catches fire.
"Just Use Spec-Driven Development" Doesn't Solve This
A common response is: be more disciplined. Write the spec first. Define your data model, auth boundaries, API contract. Treat the AI as a contractor, not an architect.
That's better practice. But it shifts the problem rather than eliminating it.
A non-developer writing a spec will define what the system should do. A software engineer reviewing it will immediately see what's missing: the race conditions, the authorization gap, the data model that doesn't handle deletion, the caching assumption that breaks under concurrent writes.
Validating an AI-generated implementation requires knowing what correct implementation looks like. That knowledge takes years to build. Writing a spec doesn't replace it.
The Uncomfortable Truth: You Still Need a Software Engineer
No matter how good AI gets at generating code, shipping software people rely on requires an engineer to validate it. Not to write every line — but to be the final checkpoint before production.
That means architecture review, security review, scalability review, and dependency audit. AI models are optimistic — they solve the happy path and miss adversarial inputs, broken access control, and insecure defaults. Catching what the AI missed requires pattern recognition built from experience: having seen these systems break before.
My colleague's app was already processing real business data daily. The person responsible for it couldn't tell you what database it was using. That's not a demo risk — that's a live incident waiting to happen.
AI Makes Good Engineers More Productive. It Doesn't Replace Engineering Judgment.
I use AI-assisted coding every day. It's one of the most significant productivity multipliers I've seen in my career. But I use it knowing what I'm looking at — when to push back, when the generated solution is naive, when the architecture needs to be redesigned before a single line gets written.
The difference between an engineer using AI as a tool and a non-developer vibe coding is the same as the difference between a surgeon using a robotic system and someone trying to operate after watching a YouTube tutorial.
AI can help a non-developer build something that looks like software. It cannot give them the judgment to know whether that software is safe to run.
If you're a non-developer shipping with AI: get an engineer to review it before it goes live — not as a one-time audit, but as an ongoing checkpoint. The vibes don't cover you when something goes wrong. Engineering judgment does.
