Vibe Coding Is Not a Software Factory
The gap between "I made a thing" and "I can sustain a thing" is where most of this conversation falls apart.
Something is happening right now that I think deserves a careful, honest conversation. And I want to have it without being dismissive, because the thing happening is actually kind of wonderful — it's just being confused with something it's not.
People who have never written software before are building things. Real things. Apps that work. Websites that look professional. Tools that solve problems they've been living with for years. They're doing this with Claude Code, Cursor, Bolt, Replit, Lovable — whatever the tool of the week is — and they're doing it by describing what they want in plain English. No syntax. No stack traces. No three-month bootcamp. They speak, and something appears.
And then they deploy it. Vercel, Netlify, Cloudflare Pages — these companies have done a genuinely remarkable job at collapsing the DevOps burden into a button. What used to require understanding DNS, load balancers, SSL certificates, CI/CD pipelines, container orchestration, and a working relationship with your ops team is now "push to main." That's not a small thing. That's a decade of infrastructure engineering distilled into a developer experience that makes deployment feel invisible.
The combination of these two forces — an AI that writes code from conversation, and a platform that deploys it without friction — creates an experience that feels like magic. I mean that without sarcasm. If you've never built software before and you describe an idea and watch it materialize in front of you, running on the internet, with a real URL you can share? That's a powerful moment. I remember what that felt like twenty years ago with my first deployed site, and I had to work a lot harder for it.
So I understand the instinct that follows. The instinct that says: if I can do this, what do I need a software developer for?
I want to sit with that question honestly, because I think it reveals something important about where we are and where we're not.
What Vibe Coding Actually Is
Vibe coding — the term has stuck whether we like it or not — is the practice of describing what you want to a model and iterating on the output conversationally until it feels right. You're not writing code. You're not reading code. You're looking at the result, deciding whether it matches what you had in mind, and adjusting your description until it does.
This works remarkably well for a certain class of problems. A landing page. A personal tool. A prototype. A form that collects data and puts it somewhere. An internal dashboard that three people will use. Things where the primary question is "does this do the thing I want?" and the answer is immediately visible.
And for those problems, it's genuinely transformative. People who previously had to hire a developer, wait weeks, pay thousands of dollars, and then iterate through misunderstandings — they can now go from idea to working thing in an afternoon. That's not hype. That's real value being created.
But here's where the story starts to diverge from the one being told on social media.
The Part That Doesn't Show Up in the Demo
When someone vibes an app into existence and deploys it to Vercel, they have a working thing. What they don't have — and what nobody talks about in the demo — is everything else.
They don't have tests that describe what the software is supposed to do, which means when it breaks (and it will), there's no specification to debug against. There's just "it used to work, and now it doesn't."
They don't have architecture decisions recorded anywhere, which means when they want to add a feature in three months, neither they nor the AI has any memory of why the code is structured the way it is.
They don't have a security review. Not security perfection — nobody has that — but the basic question of "is this storing passwords in plain text, is this vulnerable to injection, is this exposing data it shouldn't be" hasn't been asked by anyone who knows what to look for.
They don't have performance characteristics they understand. It works with ten users. Will it work with ten thousand? They don't know, and they don't have the instrumentation to find out until it falls over.
They don't have compliance awareness. Depending on what the software does, there may be legal requirements — GDPR, CCPA, PCI, ADA accessibility, industry-specific regulations — that nobody thought to ask the model about.
And they don't have a maintenance strategy. The software exists, but who updates it when a dependency has a vulnerability? Who handles the edge case that the first real user discovers? Who decides what to do when the model produces a different architecture next time, and the old one no longer works?
None of this makes vibe coding bad. It makes it an early stage. It's a prototype that got deployed. And prototypes that get deployed have a name — they're called production systems, and they carry a different set of responsibilities than the afternoon you built them in.
What a Factory Actually Requires
I've been writing about software factories for the last few weeks — the dark factory concept, what it means for brownfield organizations, and what governance structures make AI agents reliable. And the more I dig into it, the more I realize that the gap between vibe coding and a software factory isn't a gap of degree. It's a gap of kind.
A factory is built with intent. Every machine on the floor has a purpose, a specification, a tolerance range, a failure mode that's been analyzed, and a maintenance schedule. The assembly line isn't a suggestion — it's a system designed to produce consistent outcomes that meet all requirements, not just the visible ones. The factory doesn't just produce things that look right. It produces things that are right — functionally, legally, structurally, sustainably.
When I think about what a software factory would actually require, the list looks nothing like what Vibe Coding provides:
Knowledge management. Not just what the code does, but why it's structured that way. Architectural decisions externalized into persistent artifacts. Domain knowledge captured so it survives across sessions, across team members, across years.
Behavioral governance. Not just functional requirements — does it do the thing? — but non-functional ones. Performance budgets. Accessibility standards. Security policies. Legal compliance. Data handling rules. These aren't nice-to-haves. They're the constraints that separate a thing that works from a thing that's safe to operate.
Feedback loops. Monitoring. Alerting. Error tracking. User behavior analytics. The ability to know when something is wrong before a customer tells you, and to trace it back to why. In manufacturing, this is quality control. In software, it's observability. In a vibe-coded app, it often doesn't exist.
Reproducibility. The same inputs should produce consistent outputs. The research I wrote about in The Brownfield Problem showed that ungoverned AI agents have the highest variance in output quality. A factory can't run on variance. It runs on constraints.
Resilience. What happens when it fails? Not if — when. Is there a rollback path? Are there circuit breakers? Is there graceful degradation? In a real factory, the safety systems are engineered with as much care as the production systems. They're not an afterthought. They're the first thought.
A vibe-coded app has none of this. And that's fine — for a prototype, for a personal tool, for a weekend project. But the moment someone starts making business decisions based on it, or serving customers with it, or handling data that matters, the absence of these things isn't a feature. It's a liability.
Why This Distinction Matters
I'm not writing this to gatekeep. I'm writing it because the conflation of vibe coding with software engineering is going to hurt people. Not developers — we'll be fine. The people who get hurt are the ones who believe they've built something production-ready because it looks production-ready. The ones who skip the security review because the model didn't mention it. The ones who learn about compliance requirements from a lawyer's letter rather than a planning session.
The tools are incredible. Vercel is incredible. Claude Code is incredible. What they've done for accessibility to creation is real and valuable. But accessibility to creation is not the same as readiness for operation. A microwave makes cooking accessible. It doesn't make you a chef. And nobody gets hurt when you microwave a bad meal. The stakes are higher when you're serving customers, handling their data, and making promises with software you don't fully understand.
I also worry about something more subtle. When vibe coding feels like software engineering, it devalues the discipline itself. It suggests that everything engineers do — testing, architecture, security review, performance optimization, maintenance planning — is overhead. Unnecessary complexity was invented by an industry trying to justify its own existence. And I get why it looks that way from the outside. Most of what engineers do is invisible when things work. It only becomes visible when things break.
But every line of that invisible work exists because someone, at some point, learned the hard way what happens without it.
Where This Leaves Us
Vibe coding has a place. A real, valuable, legitimate place. It democratizes creation. It lowers barriers. It lets people prototype ideas without a six-figure investment. It makes software more accessible to people who have been locked out of it by the steep learning curve and the gatekeeping culture this industry has sometimes embraced. I think that's genuinely good.
And software factories — the real ones, the governed ones, the ones built with the kind of knowledge management and behavioral enforcement and feedback loops I've been writing about — those are a different thing entirely. They're not vibe coding at scale. They're engineering at a new level of abstraction. The agents are a core component, but like any real factory, even the machines that provide the automation operate within defined scopes. Their failure modes are deeply analyzed. Safety and resilience are built into the process, not tacked on after the demo.
I just wanted to say this out loud because the conversation is getting muddled. The people who've never written code and are now making things? That's great. Keep going. But know that what you're building and what a software factory produces are different things, in the same way that cooking dinner and running a restaurant are different things. Both involve food. Both have value. But one of them requires systems, governance, and a fundamentally different relationship with risk.
And if you're an engineering leader watching this unfold, the question isn't whether vibe coding threatens your team. It doesn't. The question is whether you're building the governance structures that will let your organization use AI at the level where it actually transforms how software gets made — not at the level where it produces a nice demo that falls over in production.
That's the work. It's less exciting than a viral tweet. But it's the work that matters.
Cheers,
~ John