Vibe Coding vs Professional AI-Assisted Development: Why It Matters for Your Business

There's a new kind of software project appearing in NZ businesses. Someone's nephew discovered ChatGPT. A staff member spent a weekend with Cursor. A founder watched a YouTube tutorial on "building an app with no code." Three days later, there's a login page, a few forms, and a working demo — and someone is suggesting the business use it to handle client data.

This is called vibe coding. And it's both genuinely impressive and genuinely dangerous, depending on what you do with the result.

AI has made it possible to build software that looks production-ready without understanding what's actually under the hood. The problem is that looking production-ready and being production-ready are very different things — and for business systems handling real customer data, the gap between the two is where the serious risks live.

What Is Vibe Coding?

The term was coined by AI researcher Andrej Karpathy in early 2025. He described it as "fully giving in to the vibes," using AI to generate code by describing what you want in plain language — accepting the output, iterating until it seems to work, and moving on without needing to understand the code itself.

For personal projects, learning, and rapid prototyping, this is a legitimate and genuinely useful approach. Building a tool to organise your music collection? Vibe away. Experimenting with a new idea before investing in a proper build? Perfect use case. Creating something that will handle your clients' personal and financial data, send automated communications, or process payments on behalf of your NZ business? That's where vibe coding becomes a liability.

The issue isn't the AI. AI coding tools are excellent. The issue is the absence of the professional discipline that turns generated code into software that can actually be trusted with real-world consequences.

What Vibe-Coded Business Software Typically Looks Like

Walk through the anatomy of a vibe-coded business application and the gaps become clear.

Authentication that seems to work but isn't locked down. The login page exists. Users can create accounts and sign in. But the authorisation layer — the part that controls what each logged-in user can actually see and do — is often either missing or wrong. In a vibe-coded system, it's common for any authenticated user to be able to access any other user's data simply by changing an ID in the URL. This is called an Insecure Direct Object Reference vulnerability, and it's one of the most common and most serious flaws in quickly-built applications.

No error visibility. When something breaks in a vibe-coded application, nobody knows. There's no error monitoring. Errors are swallowed silently, logged to a console nobody reads, or surface only when a user reports that something "didn't work." In a production system used by real clients, this means failures are invisible — and invisible failures compound.

Hosting on whatever was convenient. Vibe-coded applications tend to end up hosted wherever was easiest at the time — a personal server, a shared hosting account, a free tier of something. No consideration for uptime guarantees, geographic data residency (relevant under the NZ Privacy Act 2020), disaster recovery, or the compliance certifications (SOC 2, ISO 27001) that serious cloud platforms earn through independent audits.

Dependencies that nobody updates. Every modern application depends on dozens of third-party libraries. Those libraries have vulnerabilities discovered regularly. In a professionally managed application, dependencies are monitored and updated systematically. In a vibe-coded application, the versions that were installed on day one are still running two years later — including any known vulnerabilities discovered in the interim.

No backup strategy. The database exists. There may not be automated backups. If there are, nobody has tested whether they can actually be restored. The first time anyone thinks carefully about backups is often after data has been lost.

Code nobody can maintain. AI generates code that works for the prompt it was given. It doesn't generate code that a different developer can pick up, understand, and extend six months later. When the person who vibe-coded the application moves on, or when the business needs change and new features are required, the codebase is often effectively a write-off — faster to rebuild from scratch than to modify safely.

What Professional AI-Assisted Development Actually Looks Like

Professional developers use AI tools too — extensively. GitHub Copilot, Cursor, Claude. These tools genuinely accelerate development, and any developer not using them is working at a competitive disadvantage. But there's a fundamental difference in how AI is used.

In vibe coding, the AI drives and the human accepts. In professional AI-assisted development, the developer drives and uses AI as a tool — the same way a surgeon uses better instruments to do their job more precisely and efficiently. The surgeon's expertise doesn't disappear because the instruments improved. Neither does the developer's responsibility.

Here's what that responsibility looks like in practice:

Security Is Designed In, Not Hoped For

A professional developer implements row-level security at the database level — meaning that even if there's a flaw in the application layer, users cannot access data that isn't theirs. This is non-negotiable for any system handling client data.

Every input the application accepts is validated and sanitised. Every API endpoint is authenticated and authorised. Rate limiting prevents automated attacks. Security headers are configured correctly. Dependencies are scanned for known vulnerabilities before deployment and continuously afterwards.

None of this happens automatically when you prompt an AI. It happens because a developer who understands the threat model made deliberate decisions to implement each control.

Errors Are Monitored, Not Invisible

Professional applications are instrumented with error monitoring from day one. Sentry is the standard tool — it captures every unhandled error in the application, records the full context (what the user was doing, what the system state was, what the error was), and alerts the developer immediately.

This matters for two reasons. First, errors that would otherwise be invisible are caught and fixed before they become user-facing problems. Second, security incidents — attempts to probe the application for vulnerabilities — show up as anomalous error patterns that can be investigated.

A vibe-coded application has none of this. When something goes wrong, nobody knows until someone complains.

Hosting Is Compliant, Not Convenient

Production business software belongs on infrastructure that has been independently audited for security. Vercel and AWS — the platforms used for professionally built web applications — hold SOC 2 Type II certification, meaning an independent auditor has verified their security controls, availability commitments, and data handling practices.

This isn't just about ticking compliance boxes. For NZ businesses subject to the Privacy Act 2020, where data is stored and how it's protected are genuine legal obligations. Hosting client data on a personal server or unvetted hosting platform isn't just a technical risk — it's a compliance risk.

Supabase, used for database management in professional builds, provides automated backups, point-in-time recovery, and data encryption at rest and in transit. When a backup is needed, it exists and it works. This is verified, not assumed.

The Application Can Be Maintained and Extended

Professional code is written with the next developer in mind — whether that's the same developer returning after six months, or a different developer taking over the project. Clear architecture. Consistent patterns. Meaningful variable names. Comments where the logic is non-obvious. A test suite that catches regressions.

When a business's requirements change — which they always do — a professionally built application can be extended. Features can be added without breaking existing ones, because the structure supports it. A vibe-coded application, typically, cannot. The shortcuts that made it fast to build make it brittle to change.

The Real Cost Comparison

The upfront cost difference between vibe coding and professional development is real. A vibe-coded application might cost nothing if someone on your team builds it, or a few thousand dollars if a junior freelancer with AI assistance puts it together. A professionally built equivalent costs more.

But the comparison doesn't end at the invoice.

The average cost of a data breach for a small business in 2024 was over $100,000 NZD when you account for investigation, notification obligations, regulatory attention, and reputational damage. The NZ Privacy Act 2020 requires notification of serious privacy breaches to the Privacy Commissioner — and "we didn't know our system was exposed" is not a defence.

Vibe-coded business software that handles client data is a data breach waiting for a trigger. The question isn't whether the risk exists — it does — but whether the cost of the breach will ever materialise. Sometimes it doesn't. Often, by the time it does, the connection to the original software decision is hard to trace.

The other cost is momentum. A system that can't be maintained can't be improved. When your business grows, or your process changes, or you need to add a new feature, a vibe-coded system often can't accommodate it. You end up rebuilding — having paid twice for the same outcome.

How to Tell the Difference

If you're evaluating a software developer or reviewing an existing system, these questions separate professional from amateur work:

What error monitoring is in place? Sentry or an equivalent tool should be instrumented and alerting. "I check the logs occasionally" is not an answer.

Where is the application hosted, and is it SOC 2 compliant?Vercel, AWS, Google Cloud — these have compliance certifications. A personal server or generic shared hosting does not.

What's the backup and disaster recovery strategy? There should be automated daily backups, a tested restore process, and a clear recovery time objective if something goes wrong.

How is row-level security implemented? For any system with multiple users accessing shared data, row-level security should be enforced at the database level — not just in the application code.

How are dependencies monitored and updated? Automated dependency scanning (tools like Dependabot or Snyk) should be running. Libraries should be kept current.

What does the test coverage look like? Not necessarily 100% — but critical paths should have automated tests that catch regressions.

A professional developer has clear, confident answers to all of these. If the response is vague, or these concepts seem unfamiliar, you're looking at a system that was built with enthusiasm and AI assistance — but not with professional discipline.

AI Is the Tool. Judgement Is the Product.

The best custom software being built today uses AI extensively. That's not a compromise — it's what makes sophisticated systems deliverable at realistic price points for NZ small businesses. AI tools are genuinely transformative for development speed and quality.

But AI doesn't have professional judgement. It doesn't know your regulatory environment. It doesn't model threat actors. It doesn't design for the developer who will need to fix a bug at 11pm when your system is down. It doesn't think about what happens when your business doubles in size and needs the system to handle twice the load.

That's what you're paying for when you hire a professional developer: the judgement to use the tools responsibly, and the experience to know what "production-ready" actually requires. AI makes that expertise faster and more affordable to deliver. It doesn't replace it.

Vibe coding has its place. It's just not in your business's production systems.