The hate on vibe-coding, and why I think is an overreaction

An anecdote: the first time I used this meme was in 2012 right after my robotics exam. I passed, but you can maybe guess if I really knew why.
While scrolling on LinkedIn, I’ve seen 2 camps… one that loves vibe-coding and seems to not fully understand its value, and the other outraged by the idea of using prompting to ship production code without fully understanding what’s under the hood. The criticism is often sharp: “This is reckless. This undermines engineering discipline. This is dangerous.”
But here’s my honest take: I don’t really get the outrage.
Haven’t we been putting MVPs into production for decades? Shipping fast, testing in real environments, fixing later? It’s always been a tradeoff between speed, cost, and quality (or what my mentor Thomas and I call “the good enough line”). The only difference now is that AI has made the shortcut faster and a lot more visible.
But let’s go back to the pre-AI days… When I first moved into full-time development, Stack Overflow was the average developer’s lifeline. We were shipping features with snippets copied from strangers, patched into codebases we didn’t fully understand. And yet, things moved forward. Some projects thrived, some crashed. Can we blame the code? Or the coder?
Nobody called it “vibe-coding” back then. We just called it agile . This idea of failing fast was widely supported, and if you were not trying stuff quickly, you were left out.
So I struggle with the framing that AI has suddenly created a dangerous new behavior. In reality, bad code has always existed, and it has never been the fault of the tool.
To me, this hate on vibe-coding and vibe-coders is just arising from developers that are either insecure of their future (and rightly so, don’t get me wrong… the market is cold and the tech is moving fast) or outright against AI (this I do believe to be a problem).
So, here’s my take on what has actually changed: AI is exposing the fundamentals gap.
- Developers who understand their stack use AI to remove grunt work and accelerate delivery. BAD
- Developers who don’t understand their stack now ship broken code faster. BAD
- Developers who understand their stack, and use AI effectively, can get the boring stuff out of the way quickly and innovate. GOOD
That visibility is uncomfortable, but it’s not a reason to panic. It’s a reason to double down on fundamentals and ownership.
For organization leadership, this isn’t a binary question of whether vibe-coding is “acceptable”. The questions should be:
- Where does AI-driven coding make sense in our organization?
- How do we set up guardrails (reviews, testing, pipelines) so speed doesn’t turn into long-term technical debt?
- And how do we keep investing in fundamentals, so teams know when AI is helping versus when it’s misleading?
This isn’t about hype. It’s about governance, enablement, and strategic use of tools.
tl;dr
Bad production apps aren’t the result of vibe-coding. They’re the result of bad vibe coders… just as bad production apps 10, 20, or 30 years ago weren’t because of Stack Overflow, or frameworks, or compilers.
AI isn’t replacing fundamentals. It’s making the gaps visible. And in the right hands, that visibility isn’t a threat: it’s a competitive advantage.