Vibe coding and strategic software: why trusting amateur developers can cost you dearly

Something has shifted in the software development world over the past two years. With the arrival of AI coding assistants, it has become possible to build working applications without writing the code line by line. You describe what you want in plain language, the AI generates it, you paste it, you check whether it "works". The community has started calling this vibe coding.

It's a powerful evolution, and for certain contexts — rapid prototypes, side projects, experiments — it's a genuine revolution. But over the last few months something more ambiguous has emerged: agencies and freelancers without a solid engineering background have started selling business-critical software products built almost entirely this way, pitching them to clients as traditional development work.

The outcome, for the buyer, is almost always the same: a demo that impresses, a price that feels like a bargain, and 6 to 12 months later a system nobody can evolve without breaking it.

The term was popularised by Andrej Karpathy in 2025 and entered the industry vocabulary almost overnight. The working definition is simple: writing software while letting the AI lead, without actually reading or understanding the code it produces. You describe an intent, you accept the output, you eyeball-test the result. If it works, you move on.

For prototypes, it's brilliant. For MVPs you need to validate in a week, equally so. For an internal tool used by one person, where nothing breaks if it falls over, it can be perfect.

The problem starts when the same approach gets applied to a strategic digital product: the ERP that runs production, the app your customers use every day, the platform handling orders, payments and sensitive data. At that point the rules of the game change completely — and almost nobody explains this during the sales conversation.

The pitch is seductive: "We'll build it in three weeks, for a third of what a traditional agency would quote." Technically, it's true. But what you're buying is a version of the product where only the visible elements are present — the interface, the features shown in the demo, the main flow — and where almost every layer that a serious piece of software needs to survive over time is missing.

The left column is what the vendor shows the client. The right column is what determines whether the product will last three years or turn into a permanent emergency. In unsupervised vibe coding, the right column often simply doesn't exist — not because someone cut it to save money, but because whoever built the system doesn't even know it should be there.

It's the difference between a house that looks finished and a house that also has foundations, code-compliant utilities and structural inspections. The first one is cheaper and you can move in immediately. The second one lasts fifty years.

The initial quote is almost always the smallest part of what you'll spend on a software product. What really matters is the total cost of ownership across the 24 to 36 months that follow: bug-fixing, performance, feature evolution, possible rewrites.

The pattern is almost always identical. Vibe coding starts out far cheaper — sometimes less than half the price — but pushes the cost forward into every subsequent phase. Bugs surfacing in production because no tests were ever written. Performance collapsing as soon as user numbers grow, because queries and architecture were generated "by feel". Technical debt piling up with every new feature, because each change is layered onto the previous one without an overall design view.

And eventually, almost always, the moment of truth arrives: adding a feature becomes more expensive than rewriting from scratch. That's the moment the client discovers, the hard way, that they've paid twice for the same product.

To really understand the difference, you have to look at what happens to the code after launch. That's where the most underestimated problem of unsupervised vibe coding shows up: the speed at which the AI produces code is exactly the speed at which it produces inconsistencies, duplications and invisible dependencies. Without someone who understands what's entering the codebase, every new generation adds entropy to the system.

The first months feel perfect. That's the most powerful commercial advantage of vibe coding: in the early phases it genuinely does look faster, more responsive and cheaper. But somewhere around month 9 to 12, something shifts: every small request takes longer, every bug-fix creates a new one, and nobody can give a confident estimate for any intervention.

A team with a solid engineering culture — code review, automated tests, documentation, monitoring — costs more upfront but keeps technical debt under control. The product continues to evolve at a predictable pace even two years in, because every technical decision was made with full awareness of what was being built.

When a software product handles real data, transactions or business processes, the absence of engineering control isn't just a quality problem — it's a risk exposure problem. The main ones are worth looking at closely.

Security. AI-generated code can contain known vulnerabilities that nobody has reviewed — hardcoded credentials, queries unprotected against SQL injection, fragile session handling. These are mistakes a senior engineer would catch in code review, but someone who has only steered the AI in plain language often doesn't know to look for them.

Regulatory compliance. If your product handles personal data (GDPR), health data, financial data or issues tax documents, there are precise obligations about how that data must be processed, recorded and protected. A system built without anyone who understands how those regulations work is a system exposed to penalties.

Continuity. When the system breaks at 10pm on a Saturday night, someone needs to know how it's built, where to look at the logs, how to restore the data. If the product was built without documentation, without monitoring and without anyone who genuinely understands it, every incident turns into a crisis.

Vendor lock-in. Opaque code, written quickly and without structure, is code that only the people who generated it can touch. Switching vendors becomes practically impossible, because any other team looking at that code will — quite rightly — suggest rewriting the whole thing.

It would be a mistake to read all of this as a crusade against AI in software development. AI is a remarkable tool, and the best engineering teams use it heavily — precisely because they can read, evaluate and correct what it produces.

The difference isn't between "hand-written" and "AI-generated". It's between code generated and supervised by someone who knows what's happening and code generated and accepted by someone who doesn't. The first amplifies the productivity of a competent team. The second builds castles that only stand as long as nobody touches them.

The companies doing this well today use AI in three specific ways: to accelerate the mechanical parts of development, to explore architectural alternatives quickly, and to reduce the time spent on repetitive tasks. But the responsibility for the product, the architecture, the quality and the security stays human — and engineering-led.

For anyone choosing a technical partner for a strategic product, a handful of simple questions separate genuine engineering from disguised vibe coding very quickly.

How do you handle version control and code review? A vague answer, or the absence of a clear peer-review process between developers, is an early signal.

What test coverage do you have on your recent projects? You don't need a perfect number. You need the question not to surprise the person hearing it for the first time.

How do you monitor the product in production? Logging, alerting, metrics, observability dashboards. If the answer is "the client calls us when something doesn't work", you're talking to someone selling a product, not running a service.

What happens if the person who wrote this module leaves the company? A solid answer mentions documentation, shared code review, code conventions. A weak answer is silence.

Can I see the code? For a custom product, the client should always have access to the source code. If this isn't obvious, you have a positioning problem before you have a technical one.

Vibe coding isn't the enemy. It's a tool, and like every powerful tool it can do wonderful things in the right hands and damage in the wrong ones. The risk isn't that AI writes code — it's that the speed and apparent simplicity with which it produces visible results hides the absence of everything else.

For a strategic digital product — the one carrying a piece of your business, handling your data, talking to your customers — the question to ask isn't "how much does it cost?", but "who's thinking about what this software will look like in three years, and what tools do they have to guarantee it?".

If the answer isn't there, or it's vague, the low quote in front of you isn't a saving. It's a debt you've just signed without knowing it.