Vibe engineering: the responsible way to build with AI

Vibe coding is fast until it breaks. This is the alternative.

The moment everything changed

Sometime in 2023, writing code became something anyone could do — or at least, something that felt like anyone could do. You describe what you want, the model produces something that looks right, you paste it in, and it runs. Sometimes on the first try. The speed is genuinely shocking. I've used it to build things in two hours that would have taken me two days.

That's not a criticism. That's a real capability shift, and pretending otherwise would be dishonest. The question isn't whether AI changes how software gets built — it obviously does. The question is what kind of engineer you need to be in response to it.

Part of what makes that speed real is giving the AI accurate context. I use MCP servers — small processes that connect Claude to live documentation for the specific SDKs in use. When the model can look up the actual API, it stops hallucinating methods that don't exist.

What vibe coding actually means

Andrej Karpathy coined the term in early 2025 and it spread quickly because it named something real: a practice of accepting AI output without really reading it, shipping code you don't understand, and treating the process like a conversation rather than an engineering discipline. The “vibe” is that if it seems to work, it probably works.

There's a version of this that's harmless — rapid prototyping, throwaway scripts, personal projects where you're the only user and reliability doesn't matter. I've done all of that. But there's another version being sold to non-technical founders and overwhelmed teams as a way to build production software. That version has a problem.

Why it breaks

Code you don't understand accumulates. The model makes plausible-sounding decisions that aren't correct for your specific context. It invents APIs that don't exist. It misses edge cases that only appear under production load. It introduces security patterns that look reasonable but aren't. These aren't hypothetical failures — they're the ones I see when clients come to me after a vibe-coded system has become unmaintainable.

The deeper problem is ownership. If you can't explain what a system does, you can't debug it when it fails, you can't extend it when requirements change, and you can't hand it to another engineer. You've built something that works until it doesn't, with no one who knows how to fix it.

What vibe engineering is

Vibe engineering starts from the same place — AI as a powerful tool that accelerates what a trained engineer can do. The difference is who's in charge. The engineer uses the AI, not the other way around. The output of the model is a suggestion, not a solution. Every suggestion gets read, understood, tested, and either accepted or changed.

It's not slower. That's the part people misunderstand. When you own what you ship, you debug in minutes instead of days. When you understand the architecture, you extend it in hours instead of weeks. The discipline isn't the cost — it's the compounding advantage that makes speed sustainable.

The principles

What vibe engineering looks like in practice

Ship what you understand

Before a line ships, I know what it does and why. Not at a summary level — at the level where I could write it again from scratch. If I can't explain it, it doesn't go out.

AI as leverage, not replacement

The model helps me move faster. It doesn't decide what to build, how to structure it, or whether it's correct. That judgment stays with the engineer. The moment the model is in charge, the output is untested intuition.

Production is the only test that matters

Demos and local runs are necessary but not sufficient. The real bar is a system that holds up under real users, real load, and real edge cases. Everything we build is designed to pass that bar — not just the one in the acceptance criteria.

Rigor without ritual

Good engineering practice isn't bureaucracy. Tests where they catch real failures. Documentation that surfaces what the next person needs to know. Reviews that find what automated checks miss. No more, no less.

Every shortcut has a cost

Taking a shortcut isn't always wrong — sometimes it's the right call given constraints. But every shortcut is a debt entry, and debt has to be tracked. We name the shortcuts we take and account for them.

How we apply this in practice

In concrete terms: when I'm building with AI assistance, I read every function the model produces before it goes into the codebase. I push back on architectural suggestions that I can't defend. I write the tests myself — not because the model can't, but because writing tests is how I verify my own understanding. I document the decisions that future-me or a future client engineer will need to understand, not the ones that are obvious from the code.

When a client reviews the output of a Null Island Co engagement, they get a system they can operate. Not a magic box that works until someone asks the wrong question. The codebase is readable. The infrastructure is documented. The edge cases are handled or explicitly acknowledged. That's what production-ready means.

The tooling enforces this automatically. Import boundaries between layers are defined in the ESLint config and caught as errors on every save. CI runs the same checks on every push — nothing that violates the rules reaches the main branch.

Why this matters for you

If you're a non-technical founder or a CTO evaluating AI development work, the question you need to ask isn't “how fast can you ship?” It's “how much of what ships do you own?” Speed without ownership is acceleration toward technical debt. You'll pay for it, just later.

Null Island Co's engagements are fixed-scope and fixed-price specifically because we know what we're agreeing to build. That confidence comes from understanding the systems we deliver, not from hoping the AI got it right.

Go deeper