AI Vibe Coding

What is AI vibe coding?

AI vibe coding is an informal term for building software by describing the desired behaviour to an AI coding assistant, accepting generated code, and iterating by feel rather than by working from a precise design, test plan, or security model. The phrase is often used casually, but the practice can range from harmless prototyping to risky production development.

At its best, AI-assisted coding helps developers move faster. It can draft boilerplate, explain unfamiliar code, generate tests, translate between frameworks, or explore an approach. At its worst, vibe coding can produce code that appears to work in a demo but has unclear ownership, weak error handling, missing authentication, insecure dependencies, or behaviour no one can explain.

For site owners and platform teams, the concern is not that AI writes code. The concern is unreviewed code reaching public websites, APIs, admin tools, build pipelines, or security controls without the usual engineering checks.

Why does it matter?

AI-generated code can be convincing. It often uses plausible names, common patterns, and confident comments. That makes it easy to overlook subtle problems: an endpoint that trusts a client-supplied role, a cache key that ignores the current user, a regular expression that backtracks under load, a retry loop that amplifies traffic, or a data export that lacks authorisation.

The risk increases when the person driving the tool does not understand the surrounding system. A generated change may compile but violate local conventions, bypass central helpers, duplicate security logic, or introduce a new dependency where a standard library function would have been safer.

Vibe coding can also create operational risk. Generated code may not include useful logging, metrics, feature flags, rollback paths, or migration safety. When the code fails under production traffic, the team may not know which assumption was wrong.

Security teams should treat AI-assisted code as code, not as a special category that bypasses review. The same standards for threat modelling, testing, access control, dependency review, and observability still apply.

Where does vibe-coded risk appear?

Public request paths are the most important place to look. A generated handler for login, checkout, search, upload, password reset, webhook, or API access can expose real users and data. If an AI assistant creates an endpoint without understanding authentication and authorisation boundaries, the resulting bug may be severe.

APIs are especially sensitive because their contracts are often consumed by automated clients. Weak schema validation, excessive data exposure, missing rate limits, and inconsistent error handling can create abuse paths. See what is API security and what is REST API security for the broader API control model.

Build and deployment scripts are another area. Generated CI changes can leak secrets, skip tests, publish the wrong artifact, or run commands with broader permissions than intended.

Security configuration is also risky. AI-generated WAF rules, bot policies, redirects, CORS settings, CSP headers, or access-control snippets may look reasonable but fail in edge cases. A small configuration mistake can block users, expose internal routes, or leave an origin unprotected.

Common failure modes

The first failure mode is missing context. AI tools may not know the full codebase, current architecture, production constraints, or local threat model. They may generate a pattern from general examples that conflicts with the application.

The second is hallucinated capability. A model may call a function that does not exist, assume a library validates input when it does not, or invent a configuration option. Some errors are caught at compile time; others become runtime or security bugs.

The third is shallow tests. Generated tests may assert the happy path and mirror the implementation instead of checking the contract. They may miss unauthenticated access, cross-tenant data access, malformed inputs, race conditions, high-volume traffic, and rollback behaviour.

The fourth is dependency sprawl. AI may suggest packages that are outdated, unmaintained, overpowered for the task, or incompatible with the organisation's supply-chain policy.

The fifth is unclear accountability. If no person understands the generated code well enough to maintain it, the team has accepted hidden technical debt.

Practical evaluation checklist

Before merging AI-assisted code, teams should ask:

• What user, system, or attacker capability does this change create?
• Which authentication, authorisation, validation, and rate-limit rules apply?
• What data can the code read, write, cache, log, or expose?
• Are failure paths, timeouts, retries, and rollbacks explicit?
• Does the implementation use established project helpers and patterns?
• Are tests checking security boundaries and error cases, not only the happy path?
• Were new dependencies reviewed for licence, maintenance, and vulnerability risk?
• Can operators observe the change in logs, metrics, traces, or dashboards?

If the author cannot answer these questions, the code is not ready for production review, even if it runs locally.

Safer AI-assisted development practices

AI coding tools are most useful when the human supplies structure. Start with a short contract: what the code must do, what it must not do, which files own the behaviour, and which tests will prove it. Ask the assistant to work within existing patterns rather than inventing a new architecture.

Use small changes. A generated five-file refactor is harder to review than a narrow helper, test, or endpoint update. Keep security-sensitive changes behind review gates, feature flags, or log-only modes where appropriate.

Treat generated output as a draft. Read it. Run it. Test the edge cases. Check the dependencies. Remove comments that merely restate the code. Confirm that error handling and logging are useful to the people who will operate the system.

For platform teams, governance should define which AI tools are approved, what data may be pasted into them, whether prompts and code are retained, and how AI-assisted work is identified during review. The goal is not to ban useful automation. The goal is to make sure speed does not erase engineering responsibility.

AI vibe coding becomes risky when it replaces design, review, and verification. Used with those disciplines intact, AI coding assistance can improve productivity without weakening application security.

Related learning

• How To Get Started With Vibe Coding
• AI Misuse
• Prompt Injection
• OWASP Top 10 Risks for LLMs