The Hidden Risks of Vibe-Coding Business Apps

GUEST OPINION: Generative AI has done something genuinely new for small business. A non-technical person can now describe what they want in plain English and, in an hour or two, have a working internal application. Customer intake forms, quoting tools, dashboards, even small customer-facing portals which are the kind of software projects that used to need a six-week engagement with a development agency are now being built by SME owners over a weekend. The practice has acquired a name: ‘vibe coding’.

Vibe coding is fantastic for producing ‘minimum viable products’. The accessibility is remarkable, and for genuinely internal prototypes it has been a useful unlock. But the data coming out of independent security research over the last twelve months is hard to ignore, and the costs of getting vibe coding wrong are not always visible until something has already gone badly wrong. Below are the five risks I find SME owners most consistently underestimate.

1. Most vibe-coded apps ship with vulnerabilities by default

Veracode’s 2025 GenAI Code Security Report tested code generated by more than 100 large language models across 80 common coding tasks. Forty-five per cent of the AI-generated samples contained at least one OWASP Top 10 vulnerability. Cross-site scripting failed 86 per cent of the time. Log injection failed 88 per cent. Java code from these tools failed security checks more than 70 per cent of the time. The same report found AI-generated code carries roughly 2.74 times the vulnerability rate of human-written code.

None of this is a sign that the underlying models are badly built. It is a sign that producing code that works is a fundamentally different problem from producing code that is safe to deploy, and the AI tools are optimised for the first not the second.

2. Secrets and customer data are getting exposed in production

Security firm Escape. tech scanned more than 1,400 vibe-coded production applications in 2025 and found that 65 per cent had at least one security issue and 58 per cent contained at least one critical vulnerability. The scan also identified more than 400 exposed secrets including API keys, database credentials, payment tokens and 175 separate instances of personally identifiable information that had been left publicly accessible, including bank account data.

For an Australian SME bound by Privacy Act obligations or holding customer financial information, exposures of that kind are not a security inconvenience. They are a notifiable data breach in waiting.

3. AI tools hallucinate dependencies, and attackers exploit it

Around 20 per cent of AI-generated code samples reference software packages that do not exist. The model has invented a plausible-sounding library name. Attackers have already worked this out and are now actively registering the hallucinated names as malicious packages, hoping someone’s vibe-coded app installs them on the way to production. The community calls this ‘slopsquatting’. It is not a hypothetical problem.

CVE counts attributable to AI-generated code jumped from 6 in January to 35 in March 2026, and Georgia Tech researchers estimate the true open-source number is several hundred. The risk is not just the code the AI wrote. It is the code the AI told you to install.

4. There is no audit trail, no version control and no review

Traditional software development includes safeguards that are easy to take for granted: another engineer reviewing the change, a record of who altered what and when, the ability to roll back when something breaks. A weekend vibe-coding project usually has none of these. The owner does not know which version of the app is in production. There is no log of which prompt produced which feature. There is no security review before deployment.

When something does break, the only person who can possibly debug it is the person who built it — and even they may not understand what the AI generated on their behalf. That is fine for an internal scratchpad. It is a serious problem for any application customers, staff or regulators will actually use.

5. The legal liability sits squarely with the business

The Air Canada chatbot case in 2024 established the principle clearly. When a tribunal in British Columbia ordered the airline to honour incorrect bereavement-fare information provided by its customer-facing chatbot, the ruling noted simply that ‘it should be obvious to Air Canada that it is responsible for all the information on its website.’ The same principle applies to a vibe-coded quoting tool that mis-quotes a customer, a chatbot that promises a refund the business will not honour, or a customer portal that exposes someone else’s data.

The owner does not get to point at the AI tool. Australian consumer law, privacy law and now APRA’s recent industry guidance on AI risk all assume the human business is accountable for what its software does.

None of this is an argument against using AI to build software. It is an argument for treating any vibe-coded application that touches a customer, a staff member or a piece of regulated data with the same seriousness as software built by a development team. That usually means an independent code review before release, a clear policy on what kinds of data the app can touch, a deliberate choice of which AI tools and packages are sanctioned, and someone other than the original builder who can explain what the application does.

AI can write code in minutes. The consequences last years.