バイブコーディングはソフトウェア開発ではない — その兆候が見え始めている

A few weeks ago, a colleague came to me excited about a side project he'd been building. He'd been using Claude to generate the entire codebase — no prior development experience, just prompts and vibes. He showed me the app — already live, already being used to run his business. Not a prototype. Not a demo. A real product with real users and real data. Then I asked him a simple question: "What stack is it running on?" He didn't know. Not "I'm not sure about the minor details." He genuinely had no idea what language the backend was written in, what database was being used, or how the authentication worked. He was running a business on a system he couldn't describe to another human being. That conversation stuck with me. What Vibe Coding Actually Is For those unfamiliar, "vibe coding" — a term coined by Andrej Karpathy — refers to the practice of building software almost entirely through AI-generated code, where the developer accepts suggestions wholesale without deeply reading or understanding what's being produced. You describe what you want, the AI writes it, you run it, it works (sort of), and you move on. For throwaway prototypes, weekend experiments, or personal scripts? Fine. Go for it. The problem is when people start shipping this to production. Or building a business on top of it. The Real Danger Isn't the Code Quality I want to be precise here because this is where most critiques of vibe coding miss the point. The danger isn't that AI writes bad code. Claude, GPT-5, and similar models can produce remarkably clean, idiomatic code for well-defined problems. The real danger is the absence of understanding at every layer of the system . When my colleague's app eventually breaks — and it will — he won't know where to look. When a security researcher finds an IDOR vulnerability because the AI never thought to scope queries to the authenticated user, he won't know what that means or how to fix it. When the database starts timing out under load because there are no indexes on the columns being queried, he won't understand why. The AI gave him a car. But he doesn't know how to drive, and more critically, he doesn't know how an engine works. That's fine until the engine catches fire. "Just Use Spec-Driven Development" Doesn't Solve This A common response to vibe coding risks is: be more disciplined about it . Write the spec first. Define your data model, your auth boundaries, your API contract. Treat the AI as a contractor, not an architect. That's genuinely better practice. I'd recommend it to anyone building with AI assistance. But here's what spec-driven development doesn't solve: you still need someone who can evaluate whether the implementation actually matches the spec — and whether the spec itself was sound in the first place. A non-developer writing a spec will define what the system should do. A software engineer reviewing that spec will immediately see what's missing: the race conditions that weren't considered, the authorization model with a gap, the data structure that doesn't account for deletion, the caching assumption that breaks under concurrent writes. The spec is only as good as the understanding behind it. And validating an AI-generated implementation requires knowing what correct implementation actually looks like. A non-developer can't do that review meaningfully — not because they're not smart, but because that knowledge takes years to build. Spec-driven development shifts the problem. It doesn't eliminate it. The Uncomfortable Truth: You Still Need a Software Engineer This is the part nobody in the "AI democratizes software" conversation wants to say out loud. No matter how good the AI gets at generating code, shipping software that people rely on — with real data, real security requirements, real scalability needs — requires a human who understands software engineering to validate it. Not to write every line. Not to be in every loop. But to be the final checkpoint between AI-generated output and production. That means: Architecture review. Is the structure of the system going to hold up? Are the boundaries between components sensible? Will this be maintainable in 12 months? Security review. AI models are optimistic. They solve the happy path and often miss adversarial inputs, broken access control, insecure defaults. An engineer who thinks like an attacker catches what the AI missed. Scalability review. Does this system have obvious bottlenecks? Are the database queries reasonable? What happens at 10x current load? Dependency review. What packages are being pulled in? Are they maintained? Do they have known vulnerabilities? Does the project actually need all of them? None of these are things a non-developer can reliably assess — even with a well-written spec and a capable AI. They require pattern recognition built from experience: having seen systems break in these exact ways before. The "It Works" Trap The most seductive thing about vibe coding is that it produces working software quickly. The demo works. The happy path works. You can click through the app and it does what you described. "Working" in a demo and "production-ready" are separated by an enormous gap that only becomes visible under load, under attack, or under the stress of real-world usage. My colleague's app wasn't a prototype. It was already in production, already processing real business data, already being relied upon daily. And 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. This isn't an "AI bad" take. I use AI-assisted coding daily. It's genuinely one of the most significant productivity multipliers I've seen in my career. But I use it knowing what I'm looking at, knowing when to push back on a suggestion, knowing when the generated solution is naive and needs to be redesigned. 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 a layperson trying to operate after watching a YouTube tutorial. The tool doesn't confer the expertise. The expertise shapes how the tool is used. 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. What This Means in Practice If you're a non-developer building something with AI and you want to do it responsibly: Use AI to prototype and explore. That's genuinely valuable and low-risk. Before going to production, get a software engineer to review it. Not as a one-time audit — as an ongoing checkpoint. Be honest about what you don't know. The most dangerous position is confidence without understanding. And if you're an engineer being asked to "just review" a vibe-coded system before it ships: look carefully. The gaps tend to be exactly where you'd expect — auth, input handling, data scoping, error cases. The happy path usually works. Everything else is a gamble. The vibes don't cover you when something goes wrong. Engineering judgment does. A few weeks ago, a colleague came to me excited about a side project he'd been building. He'd been using Claude to generate the entire codebase — no prior development experience, just prompts and vibes. He showed me the app — already live, already being used to run his business. Not a prototype. Not a demo. A real product with real users and real data. Then I asked him a simple question: "What stack is it running on?" He didn't know. Not "I'm not sure about the minor details." He genuinely had no idea what language the backend was written in, what database was being used, or how the authentication worked. He was running a business on a system he couldn't describe to another human being. That conversation stuck with me. What Vibe Coding Actually Is For those unfamiliar, "vibe coding" — a term coined by Andrej Karpathy — refers to the practice of building software almost entirely through AI-generated code, where the developer accepts suggestions wholesale without deeply reading or understanding what's being produced. You describe what you want, the AI writes it, you run it, it works (sort of), and you move on. For throwaway prototypes, weekend experiments, or personal scripts? Fine. Go for it. The problem is when people start shipping this to production. Or building a business on top of it. The Real Danger Isn't the Code Quality I want to be precise here because this is where most critiques of vibe coding miss the point. The danger isn't that AI writes bad code. Claude, GPT-5, and similar models can produce remarkably clean, idiomatic code for well-defined problems. The real danger is the absence of understanding at every layer of the system . When my colleague's app eventually breaks — and it will — he won't know where to look. When a security researcher finds an IDOR vulnerability because the AI never thought to scope queries to the authenticated user, he won't know what that means or how to fix it. When the database starts timing out under load because there are no indexes on the columns being queried, he won't understand why. The AI gave him a car. But he doesn't know how to drive, and more critically, he doesn't know how an engine works. That's fine until the engine catches fire. "Just Use Spec-Driven Development" Doesn't Solve This A common response to vibe coding risks is: be more disciplined about it . Write the spec first. Define your data model, your auth boundaries, your API contract. Treat the AI as a contractor, not an architect. That's genuinely better practice. I'd recommend it to anyone building with AI assistance. But here's what spec-driven development doesn't solve: you still need someone who can evaluate whether the implementation actually matches the spec — and whether the spec itself was sound in the first place. A non-developer writing a spec will define what t