The original “vibe coding” note

Karpathy posted his note on February 2, 2025. He described a style of building where you lean fully on the AI model, accept the suggestions it gives you, and stop worrying about the underlying code. You talk to the tool, often by voice, describe what you want, and let it generate and run the program. If something breaks, you paste the error back in and ask for a fix rather than reading through the logic yourself.

He framed it as something that only became possible because the models had gotten good enough to handle small projects on their own. It was a casual, almost playful observation, not a manifesto. He later called it a quick throwaway thought. But the name was sticky, and within months people everywhere were using it.

Normally a programmer reads every line, understands it, and takes responsibility for it. Vibe coding flips that. You describe the outcome you want in everyday language, the model writes the code, and you judge it by whether the result feels right when you run it, not by inspecting how it works. You are steering by vibes: does the app do the thing, does it look okay, does the error go away.

Think of it like cooking with a very capable assistant who handles the knife work while you taste and say "more salt." You stay in charge of the direction, but you let go of the mechanics. That trade is the whole point, and also the whole risk.

This little note named something a lot of people were already starting to feel. Once you can describe software in plain words and watch it appear, the barrier to making a small tool, a quick game, or a weekend prototype drops a lot. People who never thought of themselves as programmers can build working things.

It matters for our community because it sets a starting line. Vibe coding is a great way to learn, to play, and to get a rough idea in front of real users quickly. The caution, which Karpathy himself implied and others spelled out later, is that going purely on vibes works best for low-stakes projects. The moment something needs to be reliable, safe, or maintained over time, you usually want to slow down and understand the code, not just feel it.