Everything you need to know about vibe coding

What is vibe coding?

Vibe coding—using LLMs to generate code from natural language descriptions—is having a moment. Even people who love to code don’t always want (or have the time) to code everything themselves. And people who don’t know how to code at all can seemingly build something usable with little engineering oversight.

On the one hand, vibe coding makes coding faster and more accessible, but it can also lure developers into a false sense of security, creating unnecessary tech debt and introducing security vulnerabilities if left unchecked. Here’s everything you need to know about this trend’s potential (and its risks) before you get the good vibes going.

Vibe coding delivers on one of the huge promises of LLMs: Instead of writing the code yourself, you describe what you want (a feature, design, or even an entire product) in natural language to a chatbot such as Cursor Composer, using trial and error to get to the desired result. The term was coined by Andrej Karpathy in early February 2025 in this now-infamous tweet:

Vibe coding applies to developers and non-technical folks alike. For devs, what distinguishes vibe coding from your everyday LLM-generated code is the language back-and-forth you can have with the models as they build. You, a human developer, can pitch an idea. The AI will pitch the execution, and you can approve, deny, or adjust it for the output you want.

Entrepreneur and indie hacker Pieter Levels popularized the idea by vibe coding a flight simulator game and launching the Vibe Coding Game Jam (with more than 500 projects submitted).

Using generative AI in coding isn’t new—developers have been using AI to accelerate routine tasks, automate repetitive workflows and suggest bug fixes or improvements since at least the mid-2010s.

In Karpathy’s example, vibe coding goes a step further by having the AI generate all the code (you “forget that the code even exists”)—offloading the heavy lifting to an LLM and simply starting over (or having a dialogue with the AI) if something doesn’t work rather than sweating over root cause analysis and debugging.

Vibe coding is fun, fast, and liberating. Non-developers can generate the code they want without having to understand what’s going on under the hood, and developers can jam on pet projects without having to write every line of code themselves. Advancements in LLMs and AI coding assistants are making it easier for anyone to be able to build software. But if anyone can do it, what’s the point of vibe coding if you know how to code?

Using generative AI to speed up development has always been about relieving developers of undifferentiated heavy lifting: tedious, menial tasks. With vibe coding, the scope is wider: instead of tasking AI with individual jobs, you might prompt it to be responsible for the scaffolding work surrounding the project.

Where vibe coding enables non-engineers to create without learning to code, experienced engineers are freed up to focus on advanced problem solving and relieved of undifferentiated heavy lifting, such as:

Think of the flow state you could achieve, or the creativity you could harness if you could just remove these kinds of tasks from your project!

But the reality isn’t so simple. Vibe coding can result in better apps with less tech debt because you can move quickly without (necessarily) cutting corners, but critically this requires an expert behind the wheel.

You need to know enough to differentiate good code from code that will paint you into a corner, to guide the AI towards best practices, or foresee potential pitfalls.

Vibe coding can be a force multiplier for devs with the right approach. But without guardrails, vibe coding can be a force multiplier of all your mistakes. Nothing kills good vibes like security breaches or sprawling, inconsistent code across the team.

Graduating from a proof-of-concept to a fully functioning, secure, scalable app is a challenge for even seasoned developers. The same risks apply to AI-generated code, as we see in this example:

An AI coding assistant doesn’t know your business’s security requirements and protocols. Proactively accounting for security (and not sharing your coding assistant-generated app online) will be critical for keeping your data and infrastructure secure.

“AI doesn’t write secure code by default and you should probably ask it to check for injections or check it over yourself,” wrote Pieter Levels. The trouble with fully giving in to the vibes is that it’s easy to overlook (or be blissfully unaware of) the implications of vibe code in the real world.

Software educator Santiago Valdarrama shared a security checklist for AI-generated code (all of which can be conducted with AI), with the cautionary words that, “Vibe coding is meant to be fun, but you should never be trusting or careless. Modern AI can help you fix security vulnerabilities, but you must know what questions to ask.”

Good vibes for you might not be good vibes for the team. Karpathy himself acknowledged that vibe coding is “not too bad for throwaway weekend projects”. In production, at scale, is where the cracks will start to show. When development teams are actually a group of individuals just vibing on their own, standardization becomes impossible (or at least difficult). AI context windows are still a long way from being able to ingest entire codebases to make sense of code sprawl and system dependencies.

Vibe coding may also encourage a culture of throwaway code—simply starting over when something doesn’t work or making random changes until it does. Teammates might remove code without understanding the effect on other parts of the codebase, and without proper version control there is a risk of irreversible changes.

Vibe coding in non-developer hands could mean more tech debt and additional maintenance overhead. Without insight into what the LLM is doing behind the scenes to produce a usable product or feature, you might find later that it’s written checks you can’t cash (like brute-forcing fixes instead of addressing the root cause).

Writing code is a fraction of the overall role of a developer; maintaining, debugging, and securing that software often represents a much bigger chunk of work. AI is prone to verbosity—the default output isn’t simple, succinct, or secure code—its default is more code. Asking for simplified code is sometimes only possible if you understand how the code is written and know what to ask for.

Vibe coding isn’t just low- or no-code by another name. The abstraction at play here is completely different. LLMs aren’t specifically trained on best practices and will not reuse code or standardize on principles without oversight. While we wouldn’t go so far as to call vibe coding a trap, there are clearly pitfalls to watch out for that make it all the more important for skilled developers to embrace multimodal development and get involved.

Don’t get us wrong: getting 80% of the way to a functioning concept with a few prompts is a huge efficiency gain. Vibe coding is perfect for exploration and ideation with lower friction. So, how do you make sure you’re taking the right shortcuts, and vibe coding in a way that your QA and infrastructure engineers won’t hate you for?

The hardest thing about designing and developing software has always been defining what you want; that hasn’t changed. Understanding user and business requirements, potential solutions, and how those interact with your existing code, stack, and infrastructure (and being able to communicate those needs) is arguably even more critical now.

By delineating what’s owned completely by developers and what gets delegated to the AI, you can contain unpredictable behavior and potentially buggy code and safeguard mission-critical business logic or sensitive data.

You can vibe code your unit, integration, and regression tests, but will want to maintain manual validation, especially for edge cases. Making sure your vibe code is covered by quality monitoring tools can also help flag code smells.

Eventually, we may be able to leave code review to the LLMs by having the models critique one another's output, but for now we need a careful human review for adherence to coding standards, maintainability, and alignment with specs.

Some security-critical components should only be driven by humans, such as input validation to prevent injection attacks (like the one above), authentication and authorization enforcement, and handling of sensitive data.

Using Git or another version control system allows you to track all changes, including those suggested by AI, so you can trace and revert problematic code if needed (and won’t lose months of work like the Cursor user above).

For applications to work in a real-world context, we can see that the role of a developer in vibe coding goes way beyond “tab tab tab”. To avoid security issues and long-term impacts on maintainability, we still need active human developer oversight and steering. Vibe coding may also be superseded by fully autonomous AI coding agents in the near future. In the meantime, developers can give in to the vibes for faster iteration and exploration, balanced by a healthy dose of skepticism and the checks and balances outlined above.