The Vibe Coding Trap: Working Software, Missing Expertise

An application can show a polished login screen, return a user's records, and still expose someone else's data through a direct request to its backend. A working demonstration only proves that one path worked. It does not prove that the system enforced the access boundary on every path.

That gap sits at the center of the vibe-coding discussion. The concern begins when a prototype becomes a service and nobody accountable for release can explain how its protections work or show evidence that they hold.

I support using AI to extend professional capability. I also expect an accountable person to evaluate the work before it carries consequences for customers, employees, or the public. A good prompt and an attractive result do not establish that a system is ready to handle customer information.

I learned that lesson the hard way. Seeing an application work is a poor substitute for understanding the assumptions, permissions, and failure paths beneath it. That experience made me more careful about what I approve and who carries the technical responsibility for it.

The ability to request software is different from the ability to approve its security.

What vibe coding means in this article

People often use "vibe coding" to describe any software built with help from AI. That definition hides a useful distinction. Software developer Simon Willison describes vibe coding as using an LLM to build software without reviewing the code it writes. His standard for production AI-assisted programming is simpler: the developer reviews and tests the code and can explain what it does to another person. Simon Willison

The amount of machine-written code does not measure engineering discipline. Qualified engineers can use AI extensively while they establish requirements, inspect important changes, test risky behavior, and remain accountable for the result. A self-taught builder who can demonstrate those practices has stronger grounds for confidence than someone who accepts generated changes without scrutiny.

Vibe coding becomes risky when appearance and immediate functionality become the acceptance criteria. Errors go back into the assistant, suggested changes are accepted until the symptom disappears, and the software grows beyond the operator's ability to evaluate it. That pattern can catch an experienced programmer as well as a new builder.

A working feature can conceal a broken boundary

Consider a customer portal. Authentication establishes who a user is. Authorization establishes which invoices, cases, or records that user may access. The portal can authenticate correctly while its backend accepts a different record identifier and returns another customer's data.

OWASP calls this Broken Object Level Authorization, or BOLA. It describes an API risk where an attacker manipulates an object identifier in a request and receives access to an object they should not control. OWASP recommends authorization checks for every function that uses client input to access a record, plus tests that evaluate the authorization mechanism. OWASP API Security Top 10

The practical test follows from the risk. A test showing that Customer A can retrieve Customer A's invoice is incomplete. The release evidence also needs to show that Customer A cannot retrieve Customer B's invoice. Tests written from the implementation alone can reinforce the implementation's assumptions, so security-sensitive acceptance criteria need an independent basis in the system's requirements and risks.

Evidence from testing and a production exposure

Veracode's July 2026 benchmark reported a 56 percent average security pass rate across four testing snapshots and more than 100 models. Under the report's standardized code-generation tasks, with no security-specific prompting, the tested models failed security checks nearly 44 percent of the time. The benchmark evaluates models in a controlled setting. It does not measure the breach rate of deployed AI-built applications or settle whether every AI-assisted team produces less secure software. It does show why successful code generation cannot serve as a security assessment. Veracode 2026 GenAI Code Security Report

The Moltbook disclosure supplies a concrete example of why access controls need review. Wiz reported in February 2026 that it found a misconfigured Supabase database that allowed read and write access to platform data. Wiz reported exposure of 1.5 million API authentication tokens, 35,000 email addresses, and private messages. It also reported that the Moltbook team secured the issue within hours. Wiz's disclosure

The lesson does not rest on hiding a key in browser code. Supabase documents that browser applications may use a publishable key, while Row Level Security and access policies protect the data. Service-role credentials require separate handling because they bypass those protections. Supabase secure-data guidance

Wiz documented the exposed database and its own verified access. The disclosure does not establish that every exposed record was taken by criminals, and it does not prove that AI alone caused the failure. It does show a real service reaching users with inadequate access controls.

Generated dependencies need the same scrutiny

AI-generated code can also introduce supply-chain risk through package recommendations. A USENIX Security 2025 paper generated 576,000 code samples using 16 models. Its analysis found 2.23 million package references, of which 440,445, or 19.7 percent, were classified as hallucinated under the researchers' method. Those results describe the models, prompts, languages, and measurement method in that study. They are not a universal rate for current code assistants. USENIX Security paper

The risk is straightforward. An attacker can publish a package under a name that a model invents, then wait for a user to install it. A public registry listing only confirms that a package name exists. It does not establish the publisher, provenance, or safety of the dependency.

For an operator, an installation command can look like an ordinary step toward a working feature. For the organization, it introduces someone else's code into a trusted environment. Dependency review, provenance checks, and locked versions belong in the release decision regardless of who suggested the package.

Agents raise the consequence of weak oversight

An assistant that proposes code has less authority than an agent that can alter files, call APIs, or access a production system. When an agent acts on a mistaken or manipulated instruction, the outcome can become an operational event before anyone examines the result.

OWASP identifies excessive functionality, permissions, and autonomy as root causes of excessive agency. Its guidance calls for minimum necessary tools and permissions, granular functions instead of open-ended execution, and independent approval for high-impact actions. OWASP LLM06: Excessive Agency

Coding tools also need ordinary vulnerability management. Cursor's August 2025 advisory for CVE-2025-54135 described a chain in which an indirect prompt injection could create a sensitive MCP configuration file and lead to code execution without approval. The advisory lists version 1.3.9 as patched. It documents a disclosed tool vulnerability, not a finding about whether AI generated the tool's code. Cursor advisory GHSA-4cxx-hrm3-49rm

Written instructions remain useful, but a prompt cannot enforce production safety by itself. The connected systems must enforce access boundaries, approvals, and least-privilege permissions. Reviewers also need enough context to identify when a proposed action requires escalation.

Use AI within your competence

My operating rule is straightforward: use AI to accelerate work you are qualified to judge. When the work moves beyond your expertise, bring in qualified supervision before it carries real consequences.

A network engineer can evaluate a proposed routing change against the actual topology, maintenance window, and recovery plan. A software engineer can challenge a generated implementation's assumptions about state and access. A business owner may understand a scheduling workflow deeply while still needing an engineer to approve its database permissions and internet-facing deployment.

This leaves room for newcomers to learn and build. AI can support isolated prototypes, synthetic-data experiments, and guided practice. Before a project handles sensitive information or becomes a service other people depend on, the work needs an accountable technical owner and evidence that the safeguards work.

NIST's Secure Software Development Framework makes a related point. It says readers do not need secure-development expertise to understand its practices, while implementation of the recommended practices requires that expertise. NIST SP 800-218

What responsible AI-assisted development requires

An AI-built prototype should cross a clear threshold before it becomes an operational service.

1. An accountable technical owner. A qualified person needs authority to reject a release and responsibility for the design, failure modes, and operating risks.
2. A controlled execution environment. Development agents need only the access required for the assignment. Development and production should remain separate, credentials protected, and high-impact actions placed behind enforceable approvals.
3. Independent verification. Review security-sensitive changes, test denied access as deliberately as successful access, and verify dependencies before introduction. Automated analysis can help, but it does not replace accountable review.
4. An operating and recovery plan. Establish who maintains the service, how changes are recorded, how failures will be detected, and how the team restores or rolls back a failed change.

These controls preserve the speed that makes AI useful. They also make it possible to distinguish a useful acceleration from a project that has simply shifted its risk to the person who must investigate the next failure.

Keep accountability as the speed increases

Vibe coding becomes dangerous when the ease of producing an application hides the expertise required to approve and operate it. A polished result can arrive before its owner has the judgment to recognize a missing security boundary.

Organizations should encourage professionals to use AI where they can evaluate the contribution. They should also be candid when an experiment becomes a service that carries obligations to other people.

Faster delivery with verifiable control is the standard worth pursuing. When nobody qualified can explain why a system should be trusted, connecting it to customers and their data accepts uncertainty on their behalf. Better prompts do not remove that responsibility.