{"slug": "vibe-coding-is-not-software-development-and-it-s-starting-to-show", "title": "Vibe Coding Is Not Software Development — And It's Starting to Show", "summary": "A developer's colleague built a production app using AI-generated code without understanding its stack, highlighting the risks of 'vibe coding'—a term coined by Andrej Karpathy for accepting AI code wholesale. The practice can lead to security vulnerabilities, performance issues, and maintainability problems when shipped to production, as non-developers lack the expertise to validate architecture, security, and scalability. The developer argues that even spec-driven development requires a software engineer to review AI-generated implementations, challenging the notion that AI fully democratizes software development.", "body_md": "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.\n\nThen I asked him a simple question: *\"What stack is it running on?\"*\n\nHe didn't know.\n\nNot \"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.\n\nThat conversation stuck with me.\n\nFor 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.\n\nFor throwaway prototypes, weekend experiments, or personal scripts? Fine. Go for it.\n\nThe problem is when people start shipping this to production. Or building a business on top of it.\n\nI want to be precise here because this is where most critiques of vibe coding miss the point.\n\nThe 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**.\n\nWhen 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.\n\nThe 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.\n\nA 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.\n\nThat's genuinely better practice. I'd recommend it to anyone building with AI assistance.\n\nBut 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.**\n\nA 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.\n\nThe 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.\n\nSpec-driven development shifts the problem. It doesn't eliminate it.\n\nThis is the part nobody in the \"AI democratizes software\" conversation wants to say out loud.\n\nNo 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.\n\nThat means:\n\n**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?\n\n**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.\n\n**Scalability review.** Does this system have obvious bottlenecks? Are the database queries reasonable? What happens at 10x current load?\n\n**Dependency review.** What packages are being pulled in? Are they maintained? Do they have known vulnerabilities? Does the project actually need all of them?\n\nNone 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.\n\nThe 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.\n\n\"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.\n\nMy 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.\n\nThis 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.\n\nThe 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.\n\nThe tool doesn't confer the expertise. The expertise shapes how the tool is used.\n\nAI 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.\n\nIf you're a non-developer building something with AI and you want to do it responsibly:\n\nThe vibes don't cover you when something goes wrong. Engineering judgment does.", "url": "https://wpnews.pro/news/vibe-coding-is-not-software-development-and-it-s-starting-to-show", "canonical_source": "https://dev.to/vmsfigueredo/vibe-coding-is-not-software-development-and-its-starting-to-show-2mfc", "published_at": "2026-06-26 17:23:59+00:00", "updated_at": "2026-06-26 17:33:43.264673+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-safety", "ai-ethics", "developer-tools"], "entities": ["Andrej Karpathy", "Claude", "GPT-5"], "alternates": {"html": "https://wpnews.pro/news/vibe-coding-is-not-software-development-and-it-s-starting-to-show", "markdown": "https://wpnews.pro/news/vibe-coding-is-not-software-development-and-it-s-starting-to-show.md", "text": "https://wpnews.pro/news/vibe-coding-is-not-software-development-and-it-s-starting-to-show.txt", "jsonld": "https://wpnews.pro/news/vibe-coding-is-not-software-development-and-it-s-starting-to-show.jsonld"}}