Vibe Coding in the Enterprise: The Security Gap Nobody Owns

Vibe coding is the practice of building software by describing what you want to a model, accepting what it generates by feel and outcome, and shipping the result without reading it line by line. Andrej Karpathy named it in a February 2025 post: a kind of coding where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." Within months it stopped being a joke about throwaway projects. Collins Dictionary made "vibe coding" its 2025 Word of the Year, and the practice moved into real enterprise workflows. That migration is where vibe coding security stops being a matter of personal taste and becomes an organizational one.

From weekend hack to internal tool#

Start with the honest part: vibe coding works. A non-engineer can stand up a dashboard, a data-cleanup script, or an internal approval flow in an afternoon instead of waiting a quarter for the platform team. Adoption is well past fringe. Roughly 85% of developers now use AI coding tools regularly, per the JetBrains survey cited by the Cloud Security Alliance, and the same reflex has spread to analysts, ops staff, and product managers who never wrote production code before.

The trouble starts after that. The afternoon project gets an API key so it can read the CRM. It gets a database credential so it can "just pull the numbers." It ends up wired to real systems and real customer data, and nobody ever decided it should be. It was never reviewed, it has no owner on the org chart, and there is no record of what it touched.

The vibe coding security gap#

The code itself is a known quantity, and the data isn't reassuring. Veracode's 2025 GenAI Code Security Report tested more than 100 models across 80 tasks and found that 45% of AI-generated samples introduced an OWASP Top 10 vulnerability. Crucially, that number held steady as models improved. They got better at writing code that works while the security numbers stayed flat. The failure modes are the ordinary ones: broken access control, injection, hardcoded secrets, missing validation. Familiar bugs, reintroduced at machine speed.

The deeper gap sits outside the code, in the missing boundary around it. A vibe-coded internal tool typically runs with whatever credentials the person who built it happened to have, talks to whatever it can reach, and logs nothing an auditor could use. When something goes wrong, the question "what ran against our data, and who approved it?" has no answer. That is the gap nobody owns, and it has less to do with the model's output than with the missing place for the software to run.

Why "just review it" doesn't scale#

The obvious answer, having a human read every AI-generated app before it touches production, collapses on contact with the volume. Generation is instant and effectively free. Careful security review is slow and expensive. In codebases where AI writes most of the commits, monthly security findings have jumped from around a thousand to more than ten thousand, according to the Apiiro analysis summarized by the Cloud Security Alliance, with privilege-escalation paths up 322%.

Review also assumes a reviewer. The whole appeal of vibe coding is that the person building the tool never had to understand the code, which leaves them poorly equipped to vet its authorization logic, and there is often no engineer assigned at all. "Just review it" quietly relocates the entire problem onto a team that never sees these apps until after an incident.

Why banning it fails#

The opposite instinct, banning AI-built internal tools outright, fails for a simpler reason: it doesn't work. The productivity is real enough that people route around the policy, and the tool moves off the record into a browser tab or a personal laptop. The risk survives, your visibility into it does not, and a governable practice turns into shadow AI. Prohibition trades a visible problem for an invisible one.

So the framing is wrong on both ends. You cannot review your way to safety at this volume, and you cannot ban your way out without losing the upside and the visibility together. The durable move is to stop trying to make every artifact trustworthy and make the place it runs trustworthy, regardless of what the model wrote. Hand the model a set of approved capabilities where raw keys would have gone and the compliant path becomes the default one, which is the job of a layer like the Overnight SDK. Then let people keep vibe coding.