Vibe Coding Is Not Engineering

There's a term going around: "vibe coding." The idea is you describe what you want to an AI, it writes the code, you ship it. No need to understand what's happening under the hood. Just vibes.

I've built an entire product with heavy AI assistance. KrakenProbe — a security scanner with 10 parallel scanners, AI analysis, OAuth, PDF export, a blog, and a dashboard — was built faster than anything I've ever shipped. AI wrote a lot of the code. And I'm here to tell you: vibe coding is dangerous nonsense.

The demo looks great. The production app doesn't.

AI is phenomenal at generating code that looks correct. It compiles. It runs. The demo works. You post it on Twitter and people are impressed.

Then a real user shows up. They paste a URL without https://. They click the button twice. They're on a phone and the input zooms the entire screen. They have an ad blocker that breaks your analytics. They're behind a corporate proxy that strips headers. They're in the EU and your PostHog instance is pointing at US servers, violating their CSP.

Every single one of these happened to KrakenProbe. AI didn't catch any of them. I did, because I've spent years watching users break things in ways nobody anticipated.

AI doesn't know what it doesn't know

Here's a real example. I asked AI to set security headers on my Netlify-hosted Next.js site. It generated a perfectly valid netlify.toml configuration. I deployed it. The headers didn't appear.

Why? Because the @netlify/plugin-nextjs plugin handles SSR routes itself and bypasses netlify.toml entirely. The headers need to go in next.config.js instead. This is a Netlify-specific gotcha that isn't in most documentation. AI confidently generated the wrong solution because it didn't know what it didn't know.

A vibe coder ships the netlify.toml, sees no errors, assumes it's working, and moves on. An engineer verifies the headers actually appear in the response. That's the difference.

The illusion of speed

Vibe coding feels fast because you skip the understanding step. You prompt, you get code, you paste it. Fifteen minutes and you have a working feature.

Except you don't have a working feature. You have a feature that works in the demo. The next three hours are spent debugging edge cases the AI didn't consider, fixing security holes it introduced, and refactoring the unmaintainable mess it generated because it has no concept of your codebase's architecture.

I tracked this building KrakenProbe. AI-generated code that I understood and could evaluate? Huge time saver. AI-generated code in areas I didn't understand? It cost me more time than writing it myself would have, because I had to debug code I couldn't reason about.

What AI is actually good at

I'm not anti-AI. I used it constantly building KrakenProbe and I'll keep using it. But I'm clear-eyed about what it's good at and what it isn't.

AI is brilliant at: generating boilerplate you'd write anyway, writing first drafts of functions when you can clearly describe the inputs and outputs, spotting patterns across large codebases, explaining unfamiliar APIs, writing tests for code you've already written, and turning rough ideas into starting points you can refine.

AI is terrible at: architecture decisions, understanding your specific deployment environment, security (it will confidently generate vulnerable code), knowing when not to build something, debugging production issues with incomplete information, and understanding why users do weird things.

The security problem nobody talks about

This is the part that worries me as someone who builds security tools. Vibe-coded apps are shipping with no CSP, no HSTS, no rate limiting, hardcoded API keys, exposed .env files, and CORS set to allow-all. Not because the developers are lazy — because they genuinely don't know these things exist.

AI won't add security headers unless you ask for them. It won't add rate limiting unless you ask. It won't think about what happens when your OpenAI API key gets scraped from your client-side bundle unless you've experienced that pain before.

I scanned KrakenProbe with itself and found 6 security issues — and I was actively thinking about security the entire time I built it. Imagine what a vibe-coded app looks like when the builder has never heard of Content-Security-Policy.

Experience is the moat

The uncomfortable truth for the "anyone can code now" crowd: AI makes experienced engineers much faster, and it lets inexperienced people produce things that look like software but break under real-world conditions.

Knowing how to type code was never the bottleneck. The hard parts are: knowing what to build, knowing what not to build, knowing where things will break, knowing how to debug when they do, knowing what "secure" actually means in practice, and knowing when the AI is confidently wrong.

AI doesn't replace any of that. It just makes the typing part faster. And the typing was never the slow part.

The way I actually use AI

Here's my actual workflow. I decide what to build and why. I sketch the architecture. I ask AI to generate the first pass. Then I read every line, because AI is a junior developer who's extremely fast but has no context and no judgment. I refactor. I test edge cases AI wouldn't think of. I check security. I deploy and verify.

That's not vibe coding. That's engineering with better tools. The AI is a force multiplier, not a replacement. The moment you stop understanding what it's generating, you've lost control of your own product.

Build things. But know what you're building.

If you're using AI to learn and build — great. Seriously. Building things is the best way to learn, and AI lowers the barrier to getting started. That's genuinely good.

But don't skip the understanding part. Don't ship code you can't explain. Don't put users' data behind security you've never verified. And don't let Twitter convince you that prompting is the same as engineering.

The vibes will only get you so far. After that, you need to actually know what you're doing.