The Vibe-Coding Risk Nobody Is Talking About

A term has emerged in development circles for code produced quickly, largely with AI, and without deep scrutiny of what was actually generated: vibe-coded.

The developer trusts the output, tests its surface behaviour, and moves on. This is not necessarily reckless. AI coding tools are genuinely impressive and can significantly accelerate development. But they also drastically increase the volume and speed at which unfamiliar code is introduced into an enterprise application.

The risk itself is not entirely new. Engineers have always worked with third-party libraries, inherited legacy systems, and code they did not write themselves. AI-assisted development, however, creates greater distance between the person approving the output and the logic actually being deployed.

It is entirely possible to publish an application that functions perfectly for its intended purpose while simultaneously:

• Exposing software version metadata to external reconnaissance tools.
• Introducing broken access control (BAC) vulnerabilities.
• Leaving administrative interfaces publicly accessible to the internet.
• Allowing unauthorised cross-tenant data access across multi-client environments.

The developer did not introduce those vulnerabilities intentionally. The rapid development pipeline did not flag them as risks. And because the application worked when tested, nobody thought to look further.

What We Found When We Checked Our Own Work

To rigorously evaluate this threat vector, we recently set up a isolated Kali Linux environment in AWS, connected it to Claude, and ran automated penetration tests against our own internet-facing services.

Claude was given a strictly defined scope, an approved suite of Kali Linux testing tools, and a structured brief. Under the active supervision of our security engineers, it executed continuous security-testing playbooks against our applications.

What came back was not catastrophic, but it was deeply instructive.

One of our secondary platforms was actively exposing version information. It was not revealing internal database assets, but it was leaking enough metadata for a sophisticated adversary to identify the precise software build and cross-reference it against known Common Vulnerabilities and Exposures (CVE) databases.

The remediation took less than an hour. Had we not proactively looked, however, we would have had no way of knowing the exposure existed. The lesson is not that our applications were dangerously insecure—the lesson is that, without an independent check, no organization can reliably prove its security posture.

This is the core principle behind managed cybersecurity done properly: not assuming that an environment is safe because nothing has visibly broken, but actively searching for what hasn’t been found yet.

The Software Supply-Chain Dimension

This is not merely an internal development problem. Enterprise security teams are simultaneously fighting escalating software supply-chain risks. Malicious or compromised software packages can be distributed through public repositories such as npm and GitHub, then pulled into corporate dev environments by engineers who have no immediate reason to distrust them.

The code installs. It compiles. It executes cleanly. Yet somewhere buried deep inside the dependency tree, an unverified package may be executing unauthorised background actions.

AI-assisted development amplifies this exposure vector by accelerating package selection, snippet generation, and library integration—especially when AI recommendations are accepted without manual code audits. The common thread in all these scenarios remains identical: someone assumed that because something worked, it was safe.

That assumption becomes exponentially more dangerous as AI accelerates the pace at which code is written, integrated, published, and deployed.

Building Independent Checks Into Your Process

At Si Futures, our operational policy is to run AI-assisted penetration tests against our internet-facing infrastructure as a standing practice. This is not a static, one-off audit. It is a continuous methodology where high-risk assets are prioritised, testing scopes are formally authorized, findings are triaged by our senior engineers, and vulnerabilities are closed before they can affect client operations.

We also enforce an AI-assisted peer-review workflow across our internal development platform. Pull requests are independently scanned for architectural flaws before being merged, while final remediation choices remain firmly in the hands of our human developers.

The rule governing both practices is the exact same one we enforce for client networks: You cannot rely on the person, team, or system that built something to be the only entity checking whether it is secure.

If your organization is leveraging AI to build software or accelerate operational workflows—whether internally or through external development partners—the vital question for IT leaders is not merely whether the application functions.

It is who is auditing the work the AI produced, what parameters they are checking it for, and how frequently that validation occurs.