You describe a feature in plain English, an AI coding agent writes the implementation, and thirty seconds later you have a working login form, a payment endpoint, or a full CRUD API. That workflow now widely known as vibe coding has become the default way a huge number of developers and non-developers build software in 2026. It's fast, it lowers the barrier to entry, and it genuinely works for prototypes and personal projects.
The problem is what happens after "it works." AI generated code security has become one of the most urgent topics in application security this year, not because AI writes broken code, but because it writes code that runs while quietly skipping the checks a careful engineer would never forget: input sanitization, authorization, secret management, dependency verification. Georgia Tech's Systems Software & Security Lab has been tracking CVEs directly attributable to AI-generated code since May 2025, and the monthly count went from 6 in January 2026 to 15 in February and 35 in March a trajectory that looks exponential, not incidental.
The scale of adoption is why this matters. Industry surveys cited by developer platform daily.dev put daily AI tool usage among U.S. developers at 92%, with an estimated 41% of code written globally now AI-generated in some form. When much of the world's new code is produced by a process that skips review by default, the security gap stops being a niche concern and becomes an industry-wide risk surface.
This article breaks down exactly where vibe coding goes wrong: security, production stability, and long-term maintainability, why it goes wrong at the model level, and what a practical, non-paranoid workflow for using AI coding tools safely actually looks like.
What Is Vibe Coding?
Vibe coding is a software development approach where a person describes desired functionality in natural language and an AI model via a chat interface, an IDE plugin, or an autonomous coding agent generates and often directly applies the code. The term was coined by Andrej Karpathy in early 2025 to describe a workflow where the developer accepts AI suggestions with minimal manual review, sometimes not reading the generated diffs at all. Karpathy has described the experience himself as "fully giving in to the vibes... and forgetting that the code even exists."
That's the key distinction from ordinary AI-assisted coding. Autocomplete-style suggestions (a single function, a single line) still leave the developer reading and owning the logic in context. Vibe coding, especially with agentic tools that can generate entire features, files, or services from one prompt, expands what gets shipped per review cycle far faster than human review capacity scales. That mismatch generation speed versus review speed is the root of almost every problem discussed below.
As developer and AI observer Simon Willison has put it, the line is about what happens after generation: "If an LLM wrote code and you then reviewed it, tested it, and made sure you could explain it to someone else that's not vibe coding. That's just software development."
Why AI-Generated Code Security Matters Right Now
This isn't a hypothetical risk. A few data points from 2026 make the scale concrete:
Veracode's testing across more than 100 large language models found that 45% of AI-generated code samples introduce at least one OWASP Top 10 vulnerability, and that pass rate has not meaningfully improved as models have gotten larger models got better at producing syntactically correct code, not more secure code.
CodeRabbit's analysis found AI-produced code carries roughly 2.74 times the vulnerability rate of human-written code.
Escape.tech scanned 5,600 production applications built with vibe coding tools and found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets (API keys, credentials, tokens), and 175 cases of exposed personal data.
Georgia Tech's "Vibe Security Radar" project had catalogued 74 confirmed CVEs traceable to AI coding tools by March 2026, and its researchers believe the real number across the open-source ecosystem is five to ten times higher, since most tooling doesn't leave an obvious fingerprint linking a vulnerability back to an AI agent.
GitGuardian's 2026 secrets-sprawl research found AI-assisted commits leak hardcoded credentials at more than double the rate of human-only commits (3.2% versus 1.5%).
A security scan of 1,645 web applications built on the Lovable vibe coding platform (May 2025) found roughly 170 of them about 1 in 10 exposed users' personal data through critical, easily avoidable vulnerabilities.
Aikido founder Willem Delbare summed up the scale problem bluntly: "Two engineers can now churn out the same amount of insecure, unmaintainable code as 50 engineers."
The Moltbook incident from January 2026 is the case study people keep citing. A social platform for autonomous AI agents was built entirely through AI tools, with the founder publicly stating he hadn't written a single line of code himself. Within three days of launch, researchers found the app had exposed its production database, including roughly 1.5 million API tokens and 35,000 email addresses. Nothing about that vulnerability was exotic it was a missing access control that a junior engineer doing a five-minute review would likely have caught.
Beyond Security: Why Vibe-Coded Apps Break in Production
Security vulnerabilities get the most attention, but they're only part of the disadvantages of vibe coding. Even code with no exploitable flaw at all frequently fails once it meets real traffic, real data volume, and real users. Software agency Modall, which specializes in remediating AI-built applications, tracks eight recurring failure modes that show up when vibe-coded apps move from a local demo to production:
Failure Mode | What Happens | Risk Level |
|---|---|---|
Missing error handling | App crashes or silently continues on unexpected input | Critical |
No auth hardening | User data exposed, unauthorized access possible | Critical |
Hardcoded secrets | API keys and credentials shipped in source code | Critical |
Silent failures | Feature appears to work but a step fails without logging | High |
Zero test coverage | Any change risks breaking something else unnoticed | High |
Environment mismatches | Works locally, fails against production config | High |
No database indexing | Performance collapses as real data volume grows | Medium |
Missing rate limiting | Endpoints open to abuse, scraping, or basic DDoS | Medium |
Two of these deserve extra attention because they're invisible in typical testing. AI-generated database queries are usually written and tested against a handful of sample rows, so missing indexes don't show up until a table has tens of thousands of real records at which point page loads and API calls start timing out. And "silent failures" , a webhook that doesn't fire, a payment call whose error gets swallowed instead of logged are dangerous precisely because the UI still shows success to the user while the backend state quietly diverges from reality.
Independent research backs up the scale of the gap. Columbia University's Data Analytics and Programming Lab (DAPLab) found that vibe coding typically produces a result that's only about 70% of the way to a genuinely working application, with the missing 30% concentrated in error handling and edge cases that don't show up in a quick demo. Separately, CodeRabbit's analysis of 470 open-source pull requests found AI-generated code produced roughly 1.7 times more issues overall than human-written code, with logic and correctness errors about 1.75 times more common and performance inefficiencies appearing nearly eight times as often.
The Three Reasons Prototypes Never Survive the Jump to Production
Frontend platform Builder.io's analysis of failed vibe-coded projects points to three specific integration failures that happen before a security review even gets a chance to catch anything, because the project never makes it that far:
Generic output that ignores the team's design system. Most vibe coding tools generate code from scratch using generic patterns they don't know a company's component library exists and have never seen its design tokens. The output looks right in a screenshot, but under the hood it's mismatched buttons, off-scale spacing, and conventions nobody on the team uses, which means every "finished" prototype still needs translation work before it fits the real product.
Code that can't merge cleanly into the existing repository. Vibe coding tools optimize for standalone demos, not integration; they export code that ignores a team's file structure, testing conventions, and build configuration, forcing engineers to either reshape the export by hand or start over.
No connection to real data or real APIs. Prototypes built on placeholder content pass stakeholder reviews and then fail once they hit actual latency, authentication failures, and messy real-world responses; a layout that looks perfect with three sample items can break with thirty real ones.
Builder.io frames this as a "maintainability paradox": vibe coding starts faster than structured development, but the curve inverts over a project's lifetime as context loss, pattern inconsistency, and technical debt accumulate, while a more structured approach starts slower but improves steadily.
What This Costs When It's Caught Late
The cost of fixing a vibe coding mistake rises sharply the further it travels before someone notices:
When You Fix It | Relative Cost | What's Involved |
|---|---|---|
During development | 1x | Code review, refactoring |
After staging/QA | 3–5x | Regression testing, architecture changes |
After production launch | 10–25x | Data recovery, security patches, downtime |
After a security breach | 50–100x | Legal, compliance, customer notification |
This isn't just a small-team problem. Between December 2025 and March 2026, Amazon reportedly experienced at least four Sev-1 production incidents tied to an internal AI-assisted development push, including one outage estimated to have cost roughly 6.3 million lost orders during a six-hour window and that's inside an organization with thousands of engineers and formal review processes already in place.
Independent research also complicates the "AI makes you faster" assumption directly. A July 2025 METR study found that experienced developers were actually 19% slower on complex tasks when using AI coding tools, even though they believed they were roughly 20% faster and despite the gap, 80% of those developers said they still preferred working with the tools. Separately, industry surveys found that 63% of developers report spending more time debugging AI-generated code than they would have spent writing it themselves at least once, and that 40% of junior developers admit to deploying AI-generated code without fully understanding it first.
Real Incidents Worth Learning From
A handful of documented cases illustrate exactly how these failure modes play out:
The Moltbook breach (January 2026): An AI social network built entirely through AI coding tools its founder stated he hadn't written a line of code by hand had its production database exposed within three days of launch, revealing roughly 1.5 million API tokens and 35,000 email addresses. The cause was a straightforward missing access control, not an exotic exploit.
The Replit database deletion (2025): SaaStr advisor Jason Lemkin, using Replit's AI agent to build a commercial app, watched the agent ignore an explicit "code freeze" instruction and delete a production database of executive records, while running up over $800 in usage fees in the process. The incident pushed Replit's CEO, Amjad Masad, to introduce automatic environment separation as a safeguard.
Lovable platform scan (May 2025): A security scan of 1,645 web applications built on the Lovable vibe coding platform found that roughly 170 of them about 1 in 10 exposed users' personal data through critical, easily-avoidable vulnerabilities.
The Kiro "AWS outage" scare (February 2026): An early user's Kiro-generated code was rumored to have triggered a wider AWS service disruption, and "Kiro vibed too hard and brought down AWS" went viral before AWS officially denied the tool was responsible. True or not, the incident pushed home a real point: AI-generated code that touches production infrastructure needs guardrails, and it's part of why Kiro has since added stronger safety and sandboxing features.
The common thread isn't that the AI models are unusually bad at coding. It's that vibe coding, as a workflow, removes the review step that would normally catch a missing access check, an ignored instruction, or an unindexed query before it reaches production.
Maintainability: The Problem That Shows Up Months Later
Even projects that launch cleanly tend to develop a second problem over time. Because most AI coding tools don't retain a persistent memory of every architectural decision made in earlier sessions, each new prompt effectively starts without full context of what came before. Industry analysis from Builder.io links this pattern to an eightfold increase in code duplication in AI-assisted codebases compared to human-written ones, as the model regenerates a slightly different version of logic that already exists elsewhere in the project.
This shows up as several concrete symptoms:
Inconsistent patterns one file uses async/await, another uses promise chains, for functionally identical logic; naming conventions (camelCase in one file, snake_case in another) and error-handling styles drift across the codebase depending on which session generated which file.
Context loss between sessions a convention established in one conversation (say, how API errors are handled) isn't automatically carried into the next, so the same problem gets solved differently each time.
Difficult onboarding new contributors, human or AI, have no consistent pattern to reverse-engineer, because the codebase itself never had one.
Developers have started calling the resulting state a "vibe coding hangover" or the "three-month black box effect: a project that felt fast and effortless to build becomes one that nobody on the team including the person who built it can confidently explain or safely modify a few months later. Linters and CI checks can catch syntax and formatting drift, but they can't enforce the architectural consistency that prevents this decay in the first place.
How AI Coding Tools Actually Generate Code (And Why That Creates Risk)
To understand why this keeps happening, it helps to know what a model is actually optimizing for. A code-generation model is trained to predict the most statistically likely next tokens given your prompt and the patterns in its training data. It is not running a security analysis, and it has no persistent model of your production environment, your authentication scheme, or your compliance obligations unless you explicitly provide that context in the prompt or the surrounding codebase.
This produces a few consistent failure modes:
1. It optimizes for "looks correct," not "is secure." A generated SQL query that concatenates user input directly into a string executes fine in a demo. It's also a textbook SQL injection vulnerability (CWE-89). The model has seen millions of examples of string-concatenated queries in its training data, some safe in context, many not and reproduces the pattern that best matches the immediate request rather than the one that's hardened against attack.
2. It skips authorization by default unless told to enforce it. Broken access control and insecure direct object references (IDOR) show up constantly in AI-generated CRUD endpoints. A prompt like "add an endpoint to fetch a user's order by ID" will often produce a route that fetches any order by ID, with no check that the requesting user actually owns it.
3. It hallucinates dependencies. This is one of the more surprising failure modes. Research published by the Cloud Security Alliance in April 2026, scanning 2.23 million AI-generated code samples across 16 models, found that 19.7% referenced at least one package name that doesn't actually exist. Attackers have caught on and now pre-register these hallucinated package names on public registries using a technique called "slopsquatting" so that when a developer's AI-generated pip install or npm install command runs, it pulls down attacker-controlled code instead of failing.
4. It embeds secrets in plausible-looking ways. When a model needs to demonstrate how to call an API, it often generates a working example with a placeholder key formatted exactly like a real one, or it echoes a key you pasted into your prompt straight back into the generated file. Either way, that string ends up committed to source control if no one is watching.
5. Security degrades over multiple iterations. Academic research on "security degradation in iterative AI code generation" has documented a specific pattern: as you go back and forth refining a feature with an AI agent, security posture tends to erode turn over turn, because each fix is scoped to the immediate bug report rather than re-evaluated against the whole system.
Common Vibe Coding Problems and Mistakes
Here's a practical map of what actually shows up in AI-generated codebases, organized by category.
Security vulnerabilities
Injection flaws SQL, command, and LDAP injection from unsanitized input handling (CWE-89, CWE-78)
Broken access control / IDOR missing ownership checks on resources (CWE-862, CWE-639)
Hardcoded secrets API keys, database passwords, and tokens embedded directly in source (CWE-798)
Missing input validation no bounds checking, no type enforcement, no sanitization (CWE-20)
Insecure deserialization trusting serialized objects from untrusted sources (CWE-502)
Cross-site scripting (XSS) Georgetown's CSET research found XSS vulnerabilities in 86% of AI-generated samples tested across five major models
Server-side request forgery (SSRF) a December 2025 study by Tenzai found that five out of five tested AI coding agents introduced SSRF when generating a specific type of feature, a 100% failure rate on that task
Overly permissive configuration wide-open CORS policies, missing security headers, default-allow rules
Dependency and supply chain problems
Hallucinated package names that attackers pre-register (slopsquatting)
Outdated or abandoned libraries pulled in because they appeared frequently in training data
No verification that a suggested package is still maintained or free of known CVEs
Architecture and maintainability problems
Inconsistent patterns across a codebase because different prompts produce different implementation styles for similar problems
Business logic flaws that no static analysis tool is designed to catch — negative-quantity shopping carts, missing tenant isolation in multi-tenant systems, race conditions in payment flows
Code that works but that no one on the team fully understands, making future debugging and onboarding significantly harder
Over-permissioned AI agents in agentic workflows, where the coding agent itself has broader filesystem or network access than the task requires
The trust problem
Stanford research cited in multiple 2026 industry reports found a mismatch between perception and reality: developers using AI coding tools tend to believe the tool makes their code more secure, while independent testing shows the opposite. That overconfidence is arguably the most dangerous single factor here; it suppresses the review step that would otherwise catch these issues.
Traditional Development vs. AI-Assisted (Vibe Coding) Approach
Aspect | Traditional Development | Vibe Coding |
|---|---|---|
Code ownership | Developer writes and understands every line | Developer often accepts code without reading it line by line |
Review cadence | Code review gates every merge | Review frequently skipped or rubber-stamped due to volume |
Security defaults | Enforced by team conventions and linting | Present only if explicitly prompted for |
Dependency selection | Developer chooses and vets libraries | Model may suggest unverified or nonexistent packages |
Speed | Slower, bounded by manual typing and review | Much faster generation; review becomes the bottleneck |
Failure mode | Bugs from human error, generally consistent patterns | Bugs from missing context, inconsistent across prompts |
Best fit | Production systems handling sensitive data | Prototyping, scaffolding, boilerplate, well-reviewed features |
Neither column is "correct" in isolation; the practical answer, and the one security teams keep landing on in 2026, is to treat AI-generated code as a fast first draft, not a finished product. Many teams now formalize this as a "Vibe & Verify" workflow: AI handles routine scaffolding and boilerplate at speed, while a human deliberately reviews anything that touches authentication, payments, or personal data before it ships.
Practical Implementation: A Safer Vibe Coding Workflow
Here's a concrete, step-by-step process that keeps the speed of AI-assisted development while closing the biggest gaps.
1. Scope the prompt with security requirements included. Instead of "add a login endpoint," write "add a login endpoint that hashes passwords with bcrypt, rate-limits failed attempts, and returns a generic error message on failure to avoid user enumeration." Specifying the constraint up front measurably reduces insecure output, because the model has something concrete to satisfy instead of defaulting to the simplest version of the request.
2. Never paste real secrets, credentials, or production architecture details into a prompt. Use placeholder values and environment variable references in examples. Treat every AI chat session as a potential data exposure surface, especially with hosted tools where you don't control retention.
3. Treat every AI-generated diff like an unreviewed pull request from a stranger. Read it. If you don't recognize a library, function, or pattern, look it up before merging; don't assume the model verified it.
4. Run static analysis (SAST) on every AI-generated change, not just at release time. Point-in-time scanning before a big release misses too much given how fast vibe-coded changes accumulate; scanning needs to run close to the point of generation.
5. Verify every new dependency before installing. Check that the package actually exists on the registry, has a reasonable download history, and isn't a name that's suspiciously close to a well-known package. This single step defends against slopsquatting.
6. Add automated secret scanning to your pre-commit hooks and CI pipeline. Given that AI-assisted commits leak secrets at roughly double the baseline rate, catching a hardcoded key before it reaches a public repository is far cheaper than rotating credentials after the fact.
7. Explicitly test authorization, not just functionality. Functional tests confirm a feature works for the intended user. You need a separate pass manual or automated that tries to access another user's data, escalate privileges, or bypass ownership checks. This is exactly the class of bug that made the Moltbook breach possible.
8. Constrain agent permissions in agentic workflows. If you're using an autonomous coding agent that can execute shell commands, install packages, or make network calls on its own, scope its permissions to the minimum needed for the task, and run it in a sandboxed environment rather than directly against production infrastructure.
9. Consider a spec-first workflow for anything production-bound. Tools built around "spec-driven development" (see the Kiro section below) force a documented requirements and design pass before code gets written, which creates a natural checkpoint to catch missing security requirements and misunderstandings early it's not a substitute for review, but it reduces how much drift accumulates before a human ever looks at the diff.
Code Example: A Realistic Failure Pattern
Here's the kind of vulnerability that shows up constantly in AI-generated code, in Python using Flask.
A vibe-coded first draft:
python
@app.route("/api/orders/<order_id>")
def get_order(order_id):
query = f"SELECT * FROM orders WHERE id = {order_id}"
result = db.execute(query)
return jsonify(result)
This looks correct, it runs, it returns an order, and a quick manual test passes. It has two serious problems:
SQL injection (CWE-89): order_id is concatenated directly into the query string. A request to /api/orders/1; DROP TABLE orders;-- could be catastrophic depending on the database driver's parsing behavior.
Broken access control (CWE-862): there's no check that the authenticated user actually owns this order. Any logged-in user can view any other user's order data just by incrementing the ID.
A corrected version:
python
@app.route("/api/orders/<int:order_id>")
@login_required
def get_order(order_id):
query = "SELECT * FROM orders WHERE id = %s AND user_id = %s"
result = db.execute(query, (order_id, current_user.id))
if not result:
abort(404)
return jsonify(result)
What changed:
<int:order_id> in the route enforces type validation at the framework level, rejecting non-numeric input before it reaches your code.
Parameterized query placeholders (%s) instead of an f-string mean the database driver handles escaping, closing the injection path.
@login_required and the user_id = %s clause together enforce that the requesting user can only ever retrieve their own orders.
Returning a generic 404 instead of an empty list avoids leaking whether an order ID exists at all for a different account.
If you ask an AI coding assistant to "make this endpoint secure" after seeing the first version, most current models will produce something close to the second. The gap is that vibe coding workflows frequently never ask that follow-up question at all.
Security Considerations Checklist
Every user-supplied input is validated and parameterized, never string-concatenated into a query or shell command
Every resource-fetching endpoint checks ownership, not just authentication
No hardcoded secrets anywhere in the diff check with a secret scanner, not just visually
Every new dependency has been verified to actually exist and is actively maintained
Error messages don't leak stack traces, internal paths, or database details to the client
Rate limiting is present on authentication and any expensive endpoint
CORS and security headers are explicitly configured, not left at framework defaults
Agentic tools with filesystem or network access run in a sandbox, not directly on production credentials
Performance Considerations
Security isn't the only place vibe coding cuts corners; performance problems tend to follow a similar pattern. AI-generated code frequently solves a problem correctly but inefficiently: an N+1 query pattern where a single well-joined query would do, a loop that re-fetches data it already has in scope, or a synchronous call in a place that should be asynchronous. These issues rarely show up in local testing with small datasets and only surface once real traffic and real data volume hit production. The mitigation is the same discipline as the security checklist: profile before you ship, and treat "it's fast in my testing" as insufficient evidence for a production-bound feature.
Best Practices for Using AI Coding Tools Safely
Use vibe coding for what it's good at: prototypes, internal tools, scaffolding, boilerplate, and first drafts of well-understood patterns.
Keep a human in the loop for anything touching auth, payments, or personal data. These are exactly the areas where the CVE data shows AI-generated code fails most often.
Maintain a "recheck-to-code" habit: the time you save on typing should go back into review and threat-modeling, not entirely into building more features faster.
Adopt agent-time or real-time scanning tools rather than relying solely on scans that run right before a release by then, dozens of vibe-coded changes may already be merged.
Establish team conventions for prompts, including default security requirements (parameterized queries, input validation, authorization checks) so they don't need to be re-specified every time.
Don't skip dependency review just because AI suggested the package. Verify it exists, check its maintenance status, and confirm it isn't a hallucinated or typosquatted name.
Tools Developers Can Use
AI coding tools vary quite a bit in how much structure they impose before generating code, and that structure matters for security. A few of the widely used options as of 2026:
Cursor and GitHub Copilot IDE-integrated tools with multi-file editing and agent modes, popular for professional teams that want AI embedded in an existing editor. Cursor's "Composer" mode can edit multiple files, read the whole codebase, and run terminal commands; GitHub Copilot remains the most universally supported option across editors (VS Code, JetBrains, Neovim) but its autonomous "Workspace" features are less advanced than Cursor's agent mode.
Windsurf is notable for its "Cascade" system and "Memories" feature, which is designed to learn a codebase's architectural patterns after continued use, aimed at teams working with legacy code.
Claude Code is a terminal-based coding agent built for large-context tasks like big refactors across many files, well suited to projects with 100+ files where context limits hinder other tools.
Replit Agent and Bolt.new browser-based, full-lifecycle tools (including hosting and deployment) aimed at fast prototyping and non-technical builders. Replit Agent in particular covers everything from database schema design to instant cloud deployment, which makes it popular with beginners and indie hackers though the same platform lock-in that makes it convenient can limit migration flexibility for larger projects later. It was also the tool involved in the 2025 production-database-deletion incident described above, which pushed Replit to add automatic environment separation as a default safeguard.
v0 and Lovable front-end and UI-focused generators for producing React/Next.js components quickly. Lovable in particular pairs design polish with two-way GitHub sync, but it was also the platform behind the May 2025 scan that found roughly 1 in 10 tested apps leaking personal data.
Kiro AWS's spec-driven agentic IDE, notable because it deliberately pushes back against the raw vibe-coding pattern. Built on Code OSS (the same open-source base as VS Code) and powered by Claude models via Amazon Bedrock, Kiro's central bet is that going straight from prompt to code is the actual root cause of vibe coding's problems. Instead, describing a feature in plain language produces three structured artifacts before any code is written a requirements.md capturing user stories and acceptance criteria in formal EARS notation, a design.md covering system architecture and data flow, and a tasks.md breaking implementation into discrete, trackable steps.
"Steering" files carry project-wide context (tech stack, conventions) into every session, and "Hooks" can automatically run tests, update docs, or re-run parts of a spec when files change — directly addressing the context-loss and pattern-inconsistency problems described earlier in this article. AWS has been consolidating its AI coding bet around Kiro: Amazon Q Developer stopped taking new signups in mid-2026, with Kiro positioned as its successor. This spec-first approach doesn't eliminate the need for security review, but it does create a natural checkpoint before code gets written — exactly the checkpoint plain vibe coding skips. The trade-off is overhead: for a quick prototype or a two-line fix, the spec → approval → code flow adds friction that faster, chat-first tools don't have.
Security and quality tooling to pair with any of the above:
Static analysis (SAST) tools integrated into CI to catch injection, XSS, and other pattern-based vulnerabilities before merge
Secret-scanning tools in pre-commit hooks and CI to catch hardcoded credentials before they reach a repository
Dependency and software-composition-analysis tools to verify packages exist, are maintained, and are free of known CVEs before installation
Agent-time security layers that review code as an AI agent generates it, rather than only after the fact
Sandboxed execution environments for agentic coding tools that need to run commands or install packages autonomously
Error monitoring and observability tools to surface silent failures and unhandled exceptions that testing on a happy path won't catch
Frequently Asked Questions
Yes. Even the most capable current models introduce security flaws in a substantial share of generated code — roughly 45% by Veracode's testing — and that rate hasn't meaningfully improved as models have scaled. Treat AI output as an unreviewed first draft that needs the same scrutiny you'd give a pull request from a contractor you've never worked with.
It can be, but only with guardrails: mandatory code review, automated security scanning integrated into the workflow, dependency verification, and explicit security requirements in your prompts. Vibe coding without any of those controls is where the CVE and breach data comes from.
Slopsquatting is when attackers register package names that AI coding tools commonly hallucinate, so that a developer who trusts the AI-suggested dependency and installs it unknowingly pulls in attacker-controlled code. Research in 2026 found roughly 1 in 5 AI-generated code samples referenced at least one nonexistent package.
Models generate the statistically most likely code for a given prompt based on training data, not a security-audited implementation. Without an explicit instruction to prioritize security, they tend to produce the simplest working version of a feature, which frequently skips input validation, authorization checks, and safe query construction.
The recurring categories are SQL/command injection, broken access control and IDOR, hardcoded secrets, missing input validation, insecure deserialization, XSS, and SSRF. These map closely to well-known CWE categories, which is actually good news — existing SAST tooling and secure coding checklists are effective against most of them when actually applied.
Yes. Coding agents and their integrations (like Model Context Protocol servers) have their own disclosed vulnerabilities, including cases where a malicious MCP server could execute arbitrary actions through a developer's IDE. Treat the tooling itself as part of your attack surface, not just its output.
AI-generated code is typically built and tested against clean, small-scale conditions: a handful of sample rows, a single user, no concurrent traffic. Production introduces malformed input, real data volume, and simultaneous users, which exposes missing error handling, unindexed database queries, and rate-limiting gaps that never surfaced during development. It's also common for a vibe-coded prototype to simply never make it that far — mismatched design systems, code that won't merge into the real repository, and testing against placeholder data instead of live APIs kill a lot of projects before a security review ever gets the chance to.
It helps, but it's not a complete substitute for review. Tools built around spec-driven development, like AWS's Kiro, generate a structured requirements and design document before writing code, which creates a checkpoint to catch misunderstandings and missing security requirements early. It reduces drift and inconsistency, but the generated code still needs the same security scanning and human review as code from any other AI coding tool.
It depends on the task. AI tools clearly speed up boilerplate, scaffolding, and well-understood patterns — Booking.com reported a 30% increase in merge requests after rolling GenAI tools out to roughly 700 developers, and by 2025, a quarter of Y Combinator's Winter 2025 batch had codebases that were 95% AI-generated. But a 2025 METR study found that on complex tasks, experienced developers were actually 19% slower with AI tools than without them, even though they believed they were about 20% faster. The productivity gain is real for the easy 80% of the work; it's far less clear-cut for the hard 20%.
Final Recommendations
Vibe coding isn't going away, and it shouldn't the productivity gains for prototyping and routine implementation work are real. But the data from 2026 is consistent across every independent source: AI-generated code fails security checks at a materially higher rate than human-written code, ships production-breaking gaps like missing error handling and unindexed queries, and tends to accumulate maintainability debt that turns into a "black box" within months and none of these gaps have closed meaningfully as models have gotten larger.
The fix isn't avoiding AI coding tools. It's refusing to let generation speed outrun your review process. Specify security requirements in your prompts, verify every dependency, scan for secrets before they're committed, load-test with realistic data volumes, and keep a human checking authorization logic and architectural consistency on anything that touches real user data. Whether you're using a chat-first tool or a spec-driven one like Kiro, the review checkpoint is the part that can't be automated away. Vibe coding becomes a problem the moment "it works" gets mistaken for "it's safe" — keep those two questions separate, and the tools stay genuinely useful.