Anyone can build software now. Open a browser, describe what you want, watch code appear. No CS degree. No bootcamp. No Stack Overflow tab graveyard. Just vibes.
That’s exciting, I use these tools myself. The feeling is real, is powerful. Vibe coding is the practice of building software by describing what you want in plain language, rather than writing code line by line. You describe a problem, and something that would have taken hours just… appears. But as someone who’s spent years designing systems (like Billing systems) that can’t afford to break, there’s a conversation we need to have.
AI tools are excellent at solving the problem you describe. They have no idea what problem you didn’t think to describe. They don’t know your service boundaries, your data contracts, your retry policies, or the architectural decision three years ago that still quietly governs how this system behaves. They generate code that’s correct in isolation and coherent on the surface. The issues surface months later under load, under pressure, after the team that built it has moved on.
I’ve observed that even well-intentioned, fast-built architectures with skilled teams often share recurring AI-assisted delivery issues: logic crossing boundaries, hidden service coupling at the data layer, events lacking consumer contracts, and retry storms without backoff. These problems don’t surface in demos but emerge months later under heavy event loads.
The difference between a coder and an engineer isn’t syntax. It’s judgment. An engineer asks: what happens when this fails? Who calls this at scale? What does this look like in 18 months? Vibe coding answers the question you typed. Engineering answers the questions you didn’t know to ask.
So the response isn’t to lock down the tools. It’s to raise the bar on thinking.
That means defining system shape before writing a line of code – boundaries, data ownership, sequence flows. Not bureaucracy; the constraints that make generated code land in the right place. It means reviewing AI output for structure, not style: does this belong here, does this service know too much, is this decision being made in the right layer? And it means treating AI the way you’d treat a brilliant junior with zero institutional memory, great execution, no knowledge of your postmortems. You wouldn’t let that person push to production unsupervised. The same rule applies.
The floor for building software has dropped to near zero. That’s not the risk. The risk is a generation of systems that nobody fully understands, assembled piece by piece, each piece reasonable, the whole thing fragile.
The vibe gets you started. The engineering determines whether it lasts.
Written by Edgar Mateus
