When “Just Prompting It” Isn’t Really Programming
Imagine building a working application by describing what you want to an AI—then never once peeking at the code it writes. That’s the essence of “vibe coding,” a term popularized in February 2025 by programmer Andrej Karpathy. In a post on X, he described a workflow where he “fully gives in to the vibes, embrace exponentials, and forget that the code even exists.” He talks to his coding assistant, accepts every suggested diff without reading it, pastes error messages back verbatim, and works around bugs he can’t fix by asking for random unrelated changes.
There's a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I'm too lazy to find it. I “Accept All” always, I don't read the diffs anymore.
The defining characteristic isn't the use of an AI—many developers now let LLMs write all their code. The distinction lies in the surrender of oversight. A programmer who reviews AI-generated code, cares about its architecture, and maintains awareness of its internals is doing something different (what some call “agentic programming”). Vibe coding, in contrast, is the willful abdication of that responsibility.
Security Blind Spots in Forgotten Code
Because the vibe coder doesn't inspect what's been generated, no programming knowledge is required. That makes it ideal for non-programmers who want a custom tool for their own use, and even for veterans building throwaway prototypes. But those same blind spots introduce outsized risk the moment the software is shared or granted meaningful access.
LLMs open a dangerously large attack surface. A vibe-coded app can inadvertently expose sensitive data, or include credentials that let a remote attacker penetrate deeper into an organization’s systems. Any user of such tools—even one with no technical background—needs to understand that this “lethal trifecta” of AI, privileges, and data exists, because it’s exactly what the output of a vibe-coding session is likely to contain.
The Cost of Unreviewed Growth
There are further structural hazards. Low-quality AI-generated output tends to accumulate rapidly into sprawling, disorganized codebases. That makes future modifications genuinely harder—even for a capable LLM, since working with well-structured software produces far better results than attempting to maintain an entangled mess.
Then there’s the inherent unreliability of LLMs themselves. They are prone to hallucinate with great confidence, which can yield software that simply behaves incorrectly in ways the user can’t see. And because LLM output is non-deterministic, a request to add a feature may introduce regressions in completely unrelated parts even if the app was working acceptably before the change. Treat any AI-generated code with a healthy degree of skepticism.
A Useful Tool, Within Limits
Given these constraints, vibe-coded software is best suited to disposable projects that are only used by their author—or a small, trusted group fully aware of the trade-offs. As the underlying model capabilities and tooling continue to evolve, those limits will shift as well.
But for code that is more complex, more widely deployed, or that carries real consequences if it goes wrong, the soundest practice remains the one vibe coding intentionally rejects: don’t forget that the code exists.
