“You can't vibe code scale”: What the AI hype gets wrong about software engineering - Stack Overflow<br>Stack Overflow Business<br>Stack Internal : the knowledge intelligence layer that powers enterprise AI.<br>Stack Data Licensing : decades of verified, technical knowledge to boost AI performance and trust.<br>Stack Ads : engage developers where it matters — in their daily workflow.

In some quarters, there’s a sense that AI has democratized software creation to the point where deep engineering expertise is becoming somehow optional. Vibe coding—in theory, at least—lets anyone describe what they want and watch AI build it. It’s not that there’s nothing to this. Prototyping is faster, junior engineering tasks are more accessible to folks without extensive formal training, and iteration cycles have been compressed. Again in theory, this should give developers more time and mental energy for complex, higher-order work.<br>But (you knew there would be a “but”), there’s a big difference between building software and running software at scale. AI hasn’t closed that gap. As Braze cofounder and CTO Jon Hyman and Stack Overflow CPTO Jody Bailey discussed on last week’s episode of Leaders of Code, the AI explosion actually makes senior engineering judgment more, not less, valuable. Because someone still has to own the consequences of what gets built and whether it can function at scale.<br>What vibe coding gets wrong (and right)<br>Let’s give the Pollyanna case its due. AI really has lowered the barrier to building functional software. Product managers can spin up interactive mockups to inform their thinking and communicate the functionality they need to engineers. Designers can resolve UX issues quickly and independently. Small teams that couldn’t afford to staff for moonshot projects can start building right now. All of these breakthroughs are real and worth noting. But as useful as vibe coding can be, it has a ceiling.<br>Building software and operating software are two different disciplines. That distinction gets lost in most conversations about AI and productivity, and it's where the vibe coding narrative starts to break down.<br>A prototype doesn't have users, traffic spikes, cascading failures, or data pipelines that degrade quietly under load before anyone notices. It doesn't have the accumulated weight of three years of architectural decisions, some brilliant and some regrettable, all of which constrain what you can do next. The prototype is the easy part. What comes after—running software reliably, at scale, for real customers with real expectations—is where engineering judgment becomes absolutely indispensable. As AI takes on more of the execution layer, the gap between what a model can generate and what it can understand becomes ever-more consequential.<br>Scale has specific, unforgiving demands. Distributed systems fail in ways that are rarely obvious and almost never reproducible in a local environment. Latency compounds across service boundaries in ways that don't show up until the stakes are uncomfortably high. A database schema decision made in week two becomes a migration nightmare in year three. An architectural pattern that works elegantly for ten thousand users can collapse like a house of cards at ten million. These kinds of challenges are the day-to-day reality of engineering teams running productive systems. Solving for them demands knowledge that’s deeply contextual—hard-won through experience and distinctly human.<br>Jon Hyman, CTO of Braze, put it plainly: "You can't vibe code scale... Being able to run that at high complexity, high scale, high down use cases is something that requires a deep understanding of what you're doing, the business problem that you're solving, and then how all the systems work together."<br>AI models are getting remarkably good at reading code, but that’s not the same as understanding a system. Even with a million-token context window, a model doesn't contain your business processes, customer use cases, organizational constraints, or the reasoning behind decisions made long ago. AI sees the what; it rarely has access to the why. (That’s where Stack Internal comes in!)<br>The competitive fallacy<br>A new technology that makes everyone more productive? Of course some people are going to look at it as a cost-cutting opportunity. If your engineers can do twice as much, you need half as many engineers. Right?<br>Not so fast. Think about how the competitive advantage actually works. AI productivity gains aren't proprietary. Every company in your market got access to the same models, the same tools, and roughly the same multiplier on engineering output at roughly the same time. So if you use that multiplier to reduce headcount and hold output steady, you haven't improved your competitive position. You've just spent less money to stay in exactly the same place. Meanwhile, your competitors are using their multiplier to build more and ship it faster.<br>As Jon framed it: "Everyone instantly, globally, got this stepwise...