Andrej Karpathy, the former OpenAI researcher and Tesla AI director, introduced the term "vibe coding" in early 2025 to describe a specific coding practice: prompting a language model for code, running whatever it produces, and iterating on the description rather than reading the actual code. What started as a self-aware joke about weekend projects has evolved into a widespread practice that raises serious questions about code quality, reproducibility, and scientific integrity.

What Exactly Is Vibe Coding?

Vibe coding means writing software by describing what you want to a language model, then accepting the output because it appears to work rather than because you understand how it works. The defining characteristic is not using AI tools for coding assistance, which most developers do now, but the deliberate decision not to read the output closely. If the code breaks, you paste the error back and ask for another attempt.

Karpathy was explicit about his original intent: he described giving in to the vibes and effectively forgetting that the code exists, and he was clear that he meant throwaway weekend projects rather than anything that mattered. However, the phrase spread far faster than the caveat did. Within months, it had a Wikipedia entry, explainers from major technology vendors, and considerable argument attached, mostly from people applying the practice well outside the frame it was coined in.

Where Is Vibe Coding Actually Acceptable?

The critical question separating legitimate use from risky application is straightforward: does anyone other than you depend on this being correct? Vibe coding is genuinely fine in specific contexts where the stakes are low and the output is temporary.

• Throwaway Exploration: Reshaping a file to see what is in it, creating a scratch plot you will look at once and delete, running a format conversion, or doing a quick sanity check on a distribution before deciding whether a question is worth pursuing. The output is a decision in your own head, and if the code were wrong you would probably notice because you know roughly what you expected to see.
• Prototypes and Internal Tools: If you are trying to find out whether a data-collection instrument, a participant-facing form, or an internal dashboard is worth building properly, a working artifact tells you more in an afternoon than a specification tells you in a week. It is entirely legitimate to throw it away afterwards.
• Scaffolding and Learning: Using AI-generated code as temporary scaffolding you intend to rewrite, or learning by taking something apart to understand how it works. These applications align with the original intent of the term.

Where Does Vibe Coding Become Indefensible?

The practice crosses a critical line when the code produces results that other people will rely on. Analysis code that generates a number, figure, or statistic in a published paper is not defensible as vibe coding. Anything touching participant data, and anything another researcher will have to reproduce, requires full understanding and documentation.

If prompt-generated code contributed to a published result, the methods section must disclose this fact. As researchers note, nobody will ask for a prompt log until someone cannot reproduce your figure, and then everyone will. A wrong finding in the literature can lead to corrections or retractions that damage both individual researchers and the broader scientific record.

How to Use AI-Assisted Code Responsibly in Research

• Line-by-Line Review Required: For anything touching real data, conduct a thorough line-by-line review of the code. Someone who understands the method must review it without exception before it touches anything real or produces publishable results.
• Disclosure in Methods: If generative assistance was used for analysis code, state this explicitly in your methods section. Indicate that the code was reviewed and that you understand what it does and why it produces the results it produces.
• Version Control and Ownership: Use tools that allow you to own the generated code and maintain it in version control. This ensures the code is inspectable, reviewable, and archivable later, even if you did not read it at the time of generation.
• Distinguish from AI-Assisted Development: Recognize that AI-assisted development, where you prompt for a function, read it, test it, correct it, and keep the parts that survive, is a different activity with a different risk profile than vibe coding. Most working developers are actually doing AI-assisted development, not pure vibe coding.

The distinction between these practices is not pedantry; it is the entire foundation of what follows, because the risk lives specifically in the not-reading. Karpathy's term was coined in a deliberately unserious register that signaled it was not a methodology, yet the practice is entirely real and widespread. A substantial amount of software genuinely gets made this way now.

Why Karpathy Remains a Key Voice on AI Development

Karpathy continues to be recognized as a valuable resource for anyone interested in the technical foundations of modern artificial intelligence. Beyond coining the vibe coding term, he shares insights about neural networks, large language models, AI development, and programming. His background as a founding member of OpenAI and former director of AI at Tesla gives him credibility on how these systems actually work, making his content especially relevant to developers and technically minded readers who want to understand not only what AI can do, but how these systems function.

As AI tools become increasingly integrated into software development workflows, the conversation Karpathy sparked about vibe coding highlights a broader tension in the field: the need to balance speed and convenience against rigor and reproducibility. For researchers, developers, and organizations building systems that others depend on, the answer is clear. For weekend projects and internal exploration, the vibes may be fine.