“Vibe coding” sounds like a phrase invented at 2 a.m. by someone wearing headphones, staring at a blinking cursor, and hoping an AI can build their dream inventory tracker before the snack run ends. In practice, the idea is much more consequential: it describes a style of software development in which a person asks a large language model, or LLM, to produce some or all of a project’s code.

The label is commonly traced to AI researcher Andrej Karpathy, formerly the leader of Tesla’s Autopilot Vision program. In February 2025, Karpathy described a new way of coding in which the developer leans into rapidly improving LLM capabilities and stops treating the underlying code as the central concern. He pointed to tools including Cursor Composer used with Sonnet as examples of the technology becoming capable enough to support that approach.

That framing explains both the appeal and the backlash. Vibe coding promises a lower barrier between an idea and a working piece of software. But critics see a dangerous gap between getting something to run and understanding whether it is secure, dependable, maintainable, or even doing what its creator thinks it does.

The debate is not really about whether AI can help programmers. It plainly already does. The harder question is where assistance ends and responsibility begins.

What people mean when they say “vibe coding”

At its broadest, vibe coding is asking an LLM to make software through natural-language instructions rather than writing every function, query, interface component, or test by hand. A person may describe a feature, receive code, paste it into a project, report an error back to the model, and repeat until the application appears to work.

That workflow can be genuinely useful for a small, personal problem. One example involved a former veterinary technician who created an app to track insulin doses for an older cat. That is a good illustration of the optimistic case: a person with domain knowledge knows exactly what tool would help, even if they do not have a traditional programming background. An LLM can reduce the distance between that need and a custom solution.

For hobby projects, prototypes, personal utilities, and early design experiments, that accessibility matters. Plenty of useful software ideas never move beyond a note app because hiring a developer, learning a programming language, or navigating conventional development tools is too intimidating. AI can make the starting line less forbidding.

But “the app works on my machine” has never been the full definition of software quality. This is where the vibe coding conversation becomes less breezy than its name suggests.

Why security concerns are at the center of the criticism

The most serious objection is that generated code can bring hidden security failures with it. A person who does not understand the output may not know how to identify an unsafe authentication flow, a flawed database query, poor handling of user input, or an accidentally exposed secret. Even an experienced programmer can miss those problems if AI output is accepted too quickly.

Preliminary research from Georgia Tech’s School of Cybersecurity and Privacy adds weight to the concern. In April, researchers reviewed 43,000 security advisories covering a three-month period earlier in the year. They identified 74 vulnerabilities that could be directly connected to AI-generated code, including 14 they classified as critical.

Those numbers need careful interpretation. The analysis did not establish that every AI-created flaw can be found in disclosure records, and the researchers estimated the real count may be five to 10 times higher because only code properly disclosed as LLM-generated could be traced. In other words, the study provides a warning signal, not a complete census of AI-related vulnerabilities.

Still, the warning is meaningful. A vulnerability is not less exploitable because the buggy code arrived in response to a pleasantly worded prompt. For anything that handles money, private data, health information, accounts, or a community of players, security review cannot be replaced by confidence in a fluent chatbot answer.

Generated code has to be owned by someone

The central issue is accountability. If an LLM produces an error, the model does not join an on-call rotation, explain the architecture to a teammate, patch the issue months later, or accept responsibility when users are harmed. The human or organization deploying the software does.

That matters long after a prototype’s first successful demo. Software changes. Dependencies update. Users find odd edge cases. New operating systems and devices expose assumptions. A codebase assembled from pieces its owner cannot explain may become increasingly difficult to repair. The result can be a project that is quick to begin and expensive to sustain.

This is not an argument that every line must be hand-written. It is an argument that somebody needs the ability to inspect, test, revise, and defend the final product. AI may accelerate the work, but it cannot make that obligation disappear.

AI assistance is not automatically vibe coding

A major source of confusion is the tendency to treat every use of AI in programming as the same thing. It is not. There is a practical distinction between code fully generated by an LLM and AI-assisted work, where a developer uses a tool for autocomplete, debugging suggestions, code cleanup, review support, or a conversational explanation of a roadblock.

That distinction matters because the second category can leave the programmer firmly in charge of the design and implementation. An autocomplete suggestion is not the same as delegating an entire application’s logic to a model. Asking for help understanding a failing test is not the same as accepting an unfamiliar system wholesale because it compiles.

Survey data from 2025 showed both the rapid adoption of AI tools and continued resistance to the vibe-coding label. Stack Overflow’s developer survey found that 47.1 percent of respondents used AI tools daily. Yet 72 percent said vibe coding was not part of their workflow, while another 5 percent said it was emphatically not how they worked.

That combination makes sense. Professional developers can see value in targeted automation while rejecting the idea that code itself has become irrelevant. The code remains the thing that ships, breaks, stores information, connects systems, and must be maintained when the original prompt is forgotten.

Another survey, involving 1,100 professional programmers who had tried AI tools, found that 72 percent used AI coding tools every day. Respondents estimated that about 42 percent of their codebases were AI-generated or AI-assisted, and they expected AI-generated code to make up more than half by the following year. Those figures combine generated and assisted code, so they should not be read as proof that half of production software is being created through pure vibe coding. They do, however, show how quickly AI has entered everyday development work.

The junior-developer problem is bigger than a prompt window

There is also a workplace concern that cannot be solved by telling newcomers to “learn AI.” Many tasks now automated for senior developers were once work assigned to junior teammates. Those smaller assignments were not merely busywork. They were opportunities to learn a codebase, make mistakes in a supervised environment, receive feedback, and gradually earn responsibility.

If entry-level tasks vanish faster than new training paths appear, the industry risks weakening the route through which future experienced developers are made. A company may gain speed today while making it harder to develop the people who will understand its systems tomorrow.

That concern has particular relevance to games and interactive software, where a project’s tools, pipelines, online services, and long-term patches can be as complex as the game itself. Automation can be helpful, especially for repetitive work, but a durable team still needs people who can reason through failures rather than only restate them to a model. The conversation around AI control in other contexts has likewise focused on the importance of human oversight, as explored in this discussion of AI control concerns.

A more useful way to judge the practice

The term vibe coding attracts heat partly because it can describe wildly different behavior. Building a private cat-care tracker with AI help is not the same proposition as deploying an AI-written service that manages user accounts or sensitive records. Treating them as identical makes the debate worse.

A sensible evaluation starts with the stakes. How much harm can a mistake cause? Who will maintain the project? Has a person who understands the code reviewed it? Are testing and security checks part of the process? Is AI being used to speed up a capable builder, or to bypass every stage at which someone would normally verify the system?

  • Low-stakes personal tools can be a promising use case, provided creators remain cautious about data and permissions.
  • Prototypes may benefit from fast AI-generated scaffolding, but prototypes should not quietly become production systems without review.
  • Professional products require ownership, testing, maintenance planning, and security accountability regardless of how much code an AI produced.
  • Learning environments should use AI in ways that help people build understanding rather than hide the underlying work completely.

Vibe coding earns enthusiasm because it makes software feel more reachable. It earns criticism because reachability is not the same as reliability. The useful middle ground is neither treating LLMs as magic programmers nor pretending they have no place in development. It is using them as powerful tools while keeping human judgment attached to the code that ultimately affects other people.