Vibe Coding Is Not Engineering

Vibe coding. The term showed up on Twitter six months ago and now every junior developer with a ChatGPT account calls themselves a prompt engineer. Describe what you want, let the AI generate the code, ship it. Fast, fun, and profoundly dangerous if you build anything someone relies on.

I use AI coding agents daily. Hermes writes most of my implementation code. The difference between what I do and vibe coding is simple: I read every line before it ships. Vibe coders do not.

What Vibe Coding Gets Right

The speed is real. A developer who could not build a REST API six months ago can now generate one in an afternoon. Prototyping velocity has increased by a factor of ten for teams that adopted AI tooling. The barrier to building software dropped, and that is not a bad thing.

AI excels at boilerplate, CRUD operations, test scaffolding, and code conversion. If the task is well-defined and the output is verifiable, an AI agent will outperform a human on speed every time.

What Vibe Coding Gets Wrong

The problem starts when the generated code encounters a domain the developer does not understand. A fintech API that looks correct can leak transaction data through improper error messages. A payment flow that passes unit tests can create duplicate charges under concurrent load. The code works. The system breaks.

I have reviewed codebases built entirely by vibe coding. They share a pattern: no error boundaries, no retry logic, no consideration for failure modes. The happy path works. Everything else is a production incident waiting to happen.

Engineering vs Prompting

Engineering is making decisions under constraint. You have a budget, a deadline, a compliance requirement, a team with specific skills, and a system that needs to stay up at 3 AM. The code is one output of that decision process. The architecture, the monitoring, the deployment strategy, the rollback plan — those are the engineering.

A prompt can generate a React component. It cannot tell you whether that component belongs in a server-side render tree or whether the data fetching pattern will cause waterfall requests on a mobile network. Taste and judgment come from building systems that broke in ways you did not expect and learning from the failure.

The Guardrails That Matter

If you use AI to write code, you need three things. First, a test suite that catches regressions before they reach production. Not generated tests — tests you wrote because you understand the edge cases the AI does not. Second, a review process that treats generated code with more skepticism, not less. Third, a monitoring stack that tells you when the shipped code misbehaves in ways the tests missed.

Vibe coding without guardrails is not engineering. It is gambling with someone else's uptime.