Vibe Coding is Shoot-and-Forget Coding

TL;DR Vibe coding is great for quick hacks; lasting software still needs real engineers.

Vibe coding, the trend of using AI to generate code by describing what you want in natural language, has been hailed as the future of programming. Coined by AI pioneer Andrej Karpathy in early 2025, the term refers to “fully giv[ing] in to the vibes, embrac[ing] exponentials, and forget[ting] that the code even exists”. In practice, vibe coding means accepting whatever code an AI assistant produces without carefully reading or understanding it, trusting that the code “mostly works” for your needs. Enthusiasts see it as a revolutionary shortcut: why spend hours grinding out syntax and debugging when an AI can do it in minutes? However, the reality is more nuanced. Vibe coding often creates “shoot-and-forget” code, one-shot solutions that work today but become a nightmare to fix, understand, or maintain tomorrow. This article takes a factual look at why the “vibes” might not carry you through the long haul of software development, and why traditional coding skills are still crucial in the age of AI.

The Allure of Vibe Coding

It’s easy to see why vibe coding has captured the tech imagination. Instead of writing every line by hand, developers (or even non-developers) can describe their intent in plain English and let advanced large language models (LLMs) like GPT-5 or Claude generate the code. Karpathy’s viral tweet in February 2025 illustrated the appeal: he built a web app by simply telling an AI what to do, copy-pasting error messages back into it, and accepting the AI’s fixes, all while barely touching the keyboard. The speed and ease are unparalleled. Proponents claim this flips programming on its head, making the human a high-level “director” and the AI the laborious “implementer”. Why sweat the small stuff when your tireless AI pair-programmer can crank out a prototype in an afternoon?

This promise of near-instant development has led to explosive adoption. Within weeks of Karpathy’s tweet, vibe coding was featured in major media and embraced by startups. Merriam-Webster even added “vibe coding” to its dictionary as a trending term in 2025. Y Combinator reported that a quarter of the startups in its Winter 2025 batch had codebases 95% generated by AI. Tech CEOs boast that vibe coding lets “10 engineers do the work of 100” in terms of feature output. The approach also democratizes development, enabling people with no formal coding background to create working apps by simply “describing the vibe” of what they want. In theory, anyone can build software without learning syntax, lowering the barrier to entry and unleashing new creativity.

Advantages frequently cited for vibe coding include:

• Lightning-fast prototyping
  Get a basic app or feature running in hours, not weeks. LLMs can produce boilerplate and repetitive code in seconds, allowing rapid experimentation. Small teams or solo tinkerers can punch above their weight, shipping ideas that would have been prohibitively slow in a traditional workflow.

• Less grunt work
  Tedious tasks like writing boilerplate, configuring frameworks, or searching Stack Overflow are handled by the AI. This frees developers to focus on high-level design and product vision instead of wrestling with minor syntax errors.

• Accessibility for non-coders
  With natural language prompts and a bit of guidance, people who aren’t professional developers can create functional software. This opens the floor to domain experts, designers, or hobbyists to implement ideas without first spending years learning to code.

• Enhanced productivity for coders
  Even experienced developers use vibe coding for a productivity boost. They can delegate routine code generation to AI and spend more time on architecture, complex logic, or creative problem-solving. As one CTO put it, “I’m spending 80% less time actually typing code… instead I’m thinking more deeply about system architecture and user experience, the stuff that actually matters”.

The hype around vibe coding paints it as an engineering utopia, a world where anyone can build software by just “vibing” with an AI collaborator, no painstaking coding required. It’s a compelling vision, and indeed, vibe coding can be transformative for quick wins and throwaway projects. Karpathy himself noted how amusing it was to let an AI handle a “weekend project” and just watch things materialize. For those low-stakes scenarios, why not let it rip?

However, seasoned developers and real-world experiences are revealing significant caveats. What happens after you’ve generated that nifty app? That’s where the vibes often run out, and serious software engineering kicks in. Vibe coding enthusiasts who proclaim traditional coding skills are no longer needed may be in for a rude awakening when they face the maintenance, debugging, and scaling of their AI-written code. Let’s explore why.

Shoot-and-Forget Code: Here Today, Gone Tomorrow

One of the biggest criticisms of vibe coding is that it encourages a “fire-and-forget” mentality toward code. You prompt the AI, get a working snippet or application, and move on without looking back, effectively “shoot-and-forget.” The code is treated as a one-shot solution: use it while it works, but don’t plan on modifying or extending it later, because doing so can be a nightmare.

Karpathy’s own description of vibe coding captures this ephemeral relationship with the code. He admitted that the AI-generated “code grows beyond my usual comprehension” and that he stopped reading diffs or trying to fully understand the changes. If a bug arose that the AI couldn’t automatically fix, he would just “work around it or ask for random changes until it goes away”. In other words, the approach forsakes careful debugging in favor of trial-and-error (or as I like to call it, “programming by stepwise debugging” [Steve]) until it “mostly works.” The end result might function initially, but nobody (not even the original developer) truly knows how or why. As Karpathy put it, “I’m building a project, but it’s not really coding, I just see stuff, say stuff, run stuff, and copy paste stuff.”. It’s a candid admission that vibe coding produces throwaway code: great for a quick demo, much less great if you ever need to revisit or maintain that project.

This shoot-and-forget philosophy is fine for prototypes or one-off tasks, the kind of code you use once and discard. In fact, many advocates explicitly recommend limiting vibe coding to sandbox experiments, personal scripts, or proofs-of-concept. “Projects should be low stakes,” advises AI blogger Simon Willison. If there’s any chance the code will cause real harm (financial loss, data breach, etc.), you shouldn’t be vibe coding in that scenario. Developer Charly Pinsen (in a bluntly titled article, “Vibe Coding: A Weekend Hack That’s Not Ready for the Real World”) echoes this: “It’s a slick gimmick for a quick prototype, but don’t be fooled: it’s nowhere near ready for the real stuff, solid systems and businesses need more than AI vibes.” He notes that while “the LinkedIn crowd loves saying ‘vibe coding’ makes everyone a 10x engineer… a prototype isn’t a product, and a product isn’t a business.” Relying on an unvetted weekend hack to serve real customers is asking for trouble.

In our own experience running an AI-focused blog and building internal tools, we use vibe coding extensively for short-term needs, e.g., quickly whipping up a custom script or mini-app to automate a task. The productivity gains are undeniable; we might eliminate the need to subscribe to a SaaS service by vibe-coding our own little solution overnight. But we go in with the mindset that this code has a limited lifespan. We treat it as one-shot code: it does the job today, and if we need changes next week, we’ll likely generate a fresh solution from scratch rather than wade into the murky internals of the old one. In other words, we “shoot” (generate the code) and “forget” (dispose of it once used), instead of investing in long-term upkeep. This approach is pragmatic when the goal is just to solve an immediate problem cheaply and quickly.

However, the moment your project transitions from a throwaway script to something long-lived or mission-critical, shoot-and-forget coding becomes dangerous. Valuable software is rarely static … requirements evolve, bugs emerge, usage grows … and that’s where vibe coding’s lack of continuity hurts most. Next, we’ll dig into why understanding and maintaining AI-written code is so challenging.

Vibe Debugging: The Nightmare of Not Understanding Your Own Code

If you’ve ever inherited someone else’s convoluted codebase, you know how painful debugging and extending it can be. With vibe coding, you’re essentially inheriting code from an AI, a “foreign” developer that may have a very different (or non-existent) coding style. You got what you asked for (hopefully), but the AI’s solution might be far from how you would have written it, and often it’s beyond your comfort level. As Karpathy joked, even on his small project, the AI’s code grew so complex he “would have to really read through it for a while” to understand it. Many vibe coders don’t take that time; they proceed without truly grokking the code. That is fine until something goes wrong.

Now, imagine months later, an error surfaces or a new feature is needed. The original “vibe” is long gone, and you’re left staring at hundreds or thousands of lines of AI-generated logic you never carefully reviewed. “Good luck finding the bug when you didn’t write it,” quips Pinsen, reflecting on the difficulty of debugging AI-written code. Vibe coding, by definition, skips the step of code comprehension and review, so when an issue arises, the developer often has no mental model of how the system works. This is the essence of “vibe debugging”: trying to troubleshoot code that feels like someone else’s tangled mystery. It’s a nightmare scenario for maintainers.

Experts have likened blindly accepting AI code to “driving a car with your eyes closed … it works until it catastrophically doesn’t.” A prominent theme in software engineering is that you cannot effectively maintain or extend what you don’t understand. Professional developers are trained to value code clarity and explicit knowledge of system behavior. When vibe coding tosses that aside, the consequences show up later in the development lifecycle. As the Cloudflare AI team points out, teams that ship AI-written features with minimal review can quickly “become unfamiliar with their codebases,” making it harder to fix bugs or vulnerabilities. It’s not just a theoretical concern – it manifests as increased debugging time, higher incidence of defects, and even complete inability to resolve certain problems without rewriting major components.

Several common issues make vibe-coded projects especially tough to debug and maintain:

• Messy or non-idiomatic code: AI generators might produce correct-but-odd solutions, using unusual libraries, outdated patterns, or just logically convoluted approaches that a human wouldn’t naturally devise. The code often lacks the coherent architecture or style that comes from a human designer. Developers have reported AI-generated codebases turning into spaghetti. As one critic put it, large LLM-written programs can devolve into “LLM mush”, lacking the organized structure needed for scaling and maintenance. This mush is difficult to reason about when things break.

• Lack of documentation and clarity: A vibe-coded project typically has minimal comments or documentation (unless you explicitly prompt the AI to include them). It may also have inconsistent naming conventions or abstract logic that wasn’t apparent in the prompt description. Combined with skipping code review, this means future developers (or your future self) have little guidance. As a result, team collaboration and onboarding new developers are hampered. Others may find the code illegible or puzzling without someone who truly understands it.

• Brittle “glue” fixes: The vibe coding workflow encourages a quick-fix mentality: copy error message -> paste to AI -> accept the fix, repeat. This iterative patching can lead to a pile of band-aid solutions that make the overall code fragile. The AI might fix a symptom without addressing the root cause, or work around a bug in a hacky way that introduces technical debt. Over time, these layers of AI-generated patches create a house-of-cards codebase: one that “works… until it doesn’t.”

• Omitting edge-case logic: Unless explicitly instructed, an AI might produce the simplest code that passes the example in the prompt, without considering edge cases or unusual inputs. Human developers instinctively think about edge cases and error handling as they code; an AI has no stake in the future, it just fulfills the prompt as directly as possible. This means many vibe-coded apps work in the common scenario but fall apart in less typical conditions. Debugging those corner cases later is hard, especially if the error surfaces far from the immediate cause (which you may not understand due to the above points).

In short, vibe coding can trade short-term convenience for long-term pain. It front-loads all the fun of “writing” the code, and back-loads the difficulty to the maintenance phase. Traditional development spreads the effort more evenly: you invest time upfront in design, understanding, and careful coding, which makes later debugging manageable. Vibe coding saves time upfront, but that debt often comes due with interest during debugging.

One particularly illustrative anecdote comes again from Charly Pinsen: “I once inherited a codebase so tangled it took weeks to unravel, AI-generated code feels like that on steroids.” In other words, if you think deciphering another human’s sloppy code is hard, deciphering an AI’s code (which might be perfectly logical to the machine but not to any human) is even harder. Pinsen also notes that simply “tweaking until it works” isn’t engineering, it’s a gamble. When that gamble fails, you might be left without the skills or knowledge to resolve the issue, unless you essentially re-engineer the component from scratch.

Hidden Costs: Security and Reliability Risks

Another major reality check for vibe coding comes in the form of security and reliability. AI-generated code may run, but is it safe and robust? Often the answer is no, at least not without a thorough review by a knowledgeable developer. By default, vibe-coded applications carry significant hidden risks that might not be obvious to the person who prompted the code.

Security vulnerabilities are a top concern. Research has shown that a huge proportion of AI-generated code has serious security flaws. The Cloud Security Alliance warns that even top-tier LLMs tend to miss critical security practices; in fact, “the top foundational models generate at least 36% insecure code” when evaluated on security-critical tasks. In plain language, more than one in three pieces of code that an AI writes could be a ticking time bomb, vulnerable to exploits. These include classics like SQL injection, cross-site scripting (XSS), hardcoded secrets, weak authentication, and so on. A human developer with security training might catch and avoid such mistakes, but an AI will merrily produce them if not specifically guided otherwise. If you deploy AI-written code to production without a careful security audit, you’re rolling the dice on potential breaches.

Real incidents bear this out. In one example, an AI-generated snippet for a web app carelessly exposed API keys to the public, creating an immediate security hole. Another vibe-coded SaaS app touted on social media was “immediately compromised” by researchers, according to MIT Technology Review. The ease and speed of vibe coding can lull developers into skipping the rigorous testing that ordinarily would reveal such vulnerabilities. And when an issue is discovered later, the earlier point about lack of understanding kicks in; those security issues are “harder to fix if development teams are unfamiliar with the problem code.” In critical systems, that’s a nightmare scenario.

Beyond security, reliability, and scalability are also problematic for vibe-coded projects. Code that works for a simple demo may crumble under real-world conditions: high load, complex user behavior, integration with other systems, etc. AI code generators do not inherently optimize for performance or robustness unless asked. They often produce the straightforward solution that meets the prompt example, not the hardened solution that accounts for scale or failure modes. As a result, vibe-coded applications might run fine with one user and a toy dataset, but bog down or crash when extended to thousands of users or large data volumes. Performance tuning and resource management are skills that come with engineering experience; an AI doesn’t intuitively include those concerns.

Maintaining state and consistency across a large codebase is another challenge. Vibe coding sessions are typically focused on solving one prompt at a time; they don’t always result in a well-architected system-wide structure. This can lead to brittle integration points. For example, two features generated on different days might use slightly different data schemas or assumptions, because the developer (and the AI) wasn’t keeping track of the overall consistency. In a human-driven project, the developer’s mental model of the system prevents such inconsistencies; in vibe coding, that model might not exist. Scaling such an ad-hoc system or adding new features can be like playing Jenga, one wrong move and things break.

To be fair, many of these issues can be mitigated. Responsible use of AI coding assistants involves exactly what vibe coding in the pure sense avoids: reviewing, testing, and understanding the AI’s output. If you treat the AI as a helpful junior developer, double-checking its work and teaching it to fix mistakes, you can catch vulnerabilities and architectural issues. But that veers away from vibe coding per se. As Simon Willison emphasizes, if you thoroughly review and test AI-written code to the point you understand it, “that’s not vibe coding, it’s software development.” True vibe coding, by Karpathy’s definition, implies not doing those due diligence steps. It “deliberately sacrifices comprehensive understanding for speed and accessibility”, which is why it’s inherently risky for anything beyond disposable projects.

In summary, vibe coding can accelerate development dramatically, but it also accelerates you right past the safety nets and best practices that traditional development uses to ensure quality. This is why many experienced engineers are cautious about the approach. They aren’t just being stick-in-the-mud traditionalists; their reservations reflect “legitimate concerns about quality, security, and sustainability”. There’s no free lunch: any time saved by not testing or thinking through the code is often paid back (with interest) when things go wrong.

Traditional Coding vs. Vibe Coding: Why Skills Still Matter

Amid the vibe coding hype, there’s a narrative in some circles that “coding skills are now redundant.” If an AI can generate code for you, why bother learning algorithms, data structures, or debugging techniques? This view is short-sighted. In reality, strong coding and software engineering skills are more important than ever if you want to harness AI effectively and build reliable software.

First, it’s crucial to clarify that vibe coding is not a wholesale replacement for programming, it’s an evolution of tools. Think of it this way: high-level languages and frameworks didn’t eliminate the need to understand programming; they abstracted some details, but developers still needed to know what the code was doing conceptually. Similarly, using an AI to write code moves the human to a higher level of abstraction, you’re writing prompts instead of syntax, but you still need to know what to ask for, how to evaluate the output, and how to integrate the pieces. A vibe coder who lacks fundamental coding knowledge is flying blind. They may get something working by trial-and-error, but they won’t truly know if the solution is correct, efficient, or secure.

As one front-end developer noted, vibe coding “doesn’t erase expertise, it elevates it”. The AI can handle the rote coding, but the developer still must guide it properly and catch its mistakes. You need to understand code structure and architecture to prompt the AI effectively (garbage in, garbage out). You need debugging skills to recognize when the AI has hallucinated a nonexistent function or used a poor approach, and then steer it to a better solution. Performance tuning, security auditing, and adapting code to edge cases all require classic engineering thinking. Vibe coding shifts some of the implementation labor to machines, but it doesn’t eliminate the engineer’s role, if anything, it emphasizes the higher-level aspects of it.

Simon Willison draws a line between “AI-assisted programming” and true vibe coding. Many developers already use tools like GitHub Copilot or ChatGPT as intelligent autocompletes or rubber ducks, they still carefully review and integrate suggestions. This can indeed boost productivity while preserving code quality. In those cases, knowing how to code is still fundamental; the AI is just a powerful aid, analogous to a smarter IDE. Vibe coding in the extreme sense (no review, no understanding) is an outlier, useful in limited cases but not a good default practice for professionals.

 

Let’s compare some aspects of traditional coding vs. vibe coding to underscore why skills remain essential:

• Code comprehension
  Traditional coding demands that you understand every line you write (or copy). You debug by reasoning through the code. Vibe coding encourages skipping comprehension, but as we discussed, that only works until a non-trivial bug or change is needed. Developers who maintain the habit of understanding code (their own or AI’s) will have a huge advantage in diagnosing problems. If you know what the code is supposed to do, you can fix it; if you don’t, you’re stuck. Thus, the ability to read and reason about code is still critical, arguably even more when working with AI outputs, because you must be the safety check.

• Design and architecture
  In traditional development, you think about how to structure the program (modules, interfaces, data models) for clarity and future growth. Vibe coding tends to be ad-hoc; the AI might make design choices on the fly or follow your prompt literally without global context. Without human direction, the architecture might be suboptimal or brittle. Developers with solid architectural skills can guide the AI (e.g., generating one module at a time with clear interfaces) to ensure the result isn’t a big ball of mud. AI is a tool, not an architect; that responsibility remains with human developers.

• Testing and verification
  Seasoned programmers write tests, consider edge cases, and use debugging tools to verify correctness. An AI won’t automatically do this for you (unless explicitly asked, and even then, it might do a superficial job). It happily generates code that looks plausible. It’s up to the developer to validate it. Knowing how to test (and what to test for) is an irreplaceable skill to catch AI mistakes. The phrase “vibe, then verify” has emerged in the industry, meaning use AI to accelerate coding, but use human-led processes (like code review and testing) to verify the output. Without coding skills, you wouldn’t know how to verify or what a correct solution even looks like beyond “it runs.”

• Debugging and problem-solving
  Debugging is often called an art; it requires logical deduction, knowledge of how systems fail, and sometimes creative experiments. When an AI-generated code doesn’t work as expected, a developer must debug the situation. This means they need to interpret error messages, trace through code execution, and identify the root cause. These are classic software engineering skills. If anything, debugging AI code may require more skill, because the code can be more confusing. A developer who treats the AI as infallible will be lost when things break. In contrast, a skilled coder will approach AI output with healthy skepticism and an analytical eye, ready to dive in when needed.

• Maintaining skills and adapting
  Finally, relying solely on AI can lead to skill atrophy. If a developer stops writing or reading code entirely, their ability to troubleshoot or implement novel solutions will degrade over time. This is analogous to relying on GPS navigation, convenient day to day, but if the GPS fails, you might realize you’ve forgotten how to read a map. Similarly, future AI coding tools might change or face scenarios they can’t handle, and a developer who hasn’t kept their programming muscles active will struggle. By continuing to engage with coding fundamentals and understanding the AI’s outputs, developers ensure they remain adaptable and in control, rather than at the mercy of whatever the AI provides.

The bottom line: coding is not “redundant”, it’s evolving. The skill set is shifting, but the core competencies (logical thinking, understanding how software works) are as vital as ever. Vibe coding can automate the grunt work and accelerate the process, but it does not replace the need for human judgment, design insight, and problem-solving ability. In fact, those who have strong traditional skills are often better at vibe coding because they know how to coax useful results from the AI and how to fix or improve those results when needed.

To anyone who believes Karpathy’s vibe coding means they never have to learn to code: that’s a misunderstanding. What it actually means is that if you do learn to code (at least to an intermediate understanding), you can leverage these AI tools to be far more productive. If you don’t have any coding skills, you might get a toy app running with AI help, but you’ll hit a wall when something goes off-script. As one security expert put it, using vibe coding without careful review is “irresponsible” for anything public-facing or critical, the implication being that responsible use requires knowledge and oversight, i.e., human skill.

No Panacea: Vibe Coding in Perspective

“Vibe coding” is an exciting development in software engineering, no doubt. It represents a powerful new tool in the programmer’s toolkit, one that can boost productivity and invite more people into coding. For quick prototypes, personal scripts, or learning exercises, it’s fantastic; you can materialize ideas with unprecedented speed. However, it’s not a panacea. Writing code is only one part of software development; ensuring that code is readable, maintainable, secure, and reliable is another part, one that vibe coding alone doesn’t solve and often makes harder.

Enthusiasts who proclaim the end of traditional coding may be overlooking the practical realities we’ve discussed:

• AI-generated code is only as good as the guidance and scrutiny it receives. Without human expertise applied, it can and will produce faulty or suboptimal results.

• The “forget that the code even exists” ethos is risky outside of trivial projects. In the real world, code invariably outlives the moment of its creation. Someone will have to read it, debug it, and adapt it later, and if that someone is scratching their head at an opaque AI-written blob, the initial time saved evaporates quickly.

• Every new technology in programming (from high-level languages to code libraries to Stack Overflow itself) has raised fears of making certain skills obsolete. Yet time and again, the best outcomes come from developers who combine new tools with solid fundamentals. AI coding tools are no exception. They can make a good developer far more effective, but they won’t make a non-developer into a seasoned software engineer overnight.

In truth, vibe coding is best viewed as a trade-off. It “deliberately sacrifices comprehensive understanding for speed and accessibility”. That’s a trade-off you might accept for a throwaway project or a personal automation. But in exchange, you must be willing to also sacrifice some maintainability and peace of mind. If and when that code needs to be maintained, you either commit to re-engaging with it in depth (essentially doing the understanding later) or you generate a new replacement. For professional, long-term projects, giving up understanding is usually not worth the short-term speed. As software veteran Simon Willison nicely summarized, using LLMs in development is great, but if you skip making sure the code is human-understandable, you’ve left the realm of responsible development.

Reality check: There is no magic “create awesome app” button, not without consequences. Vibe coding can feel like magic when it works, but when the magic fades, you’re left with all the same problems developers have always faced, sometimes amplified by the lack of clarity. Bugs still need fixing. Requirements still change. Systems still need to talk to each other. Performance still matters. Users still find ways to do unexpected things. These are the truths of software engineering that no amount of “vibes” can wish away.

Looking ahead, it’s likely we’ll see more integration of AI in coding, and hopefully better tooling to address some pitfalls (like AI systems that can explain their code, or automated security scanners for AI-written code). The practice of vibe coding might become safer and more structured over time, especially as the community develops best practices (for example, a “vibe coding framework” or checklists for secure vibe coding are already being discussed). But today, in 2025, the prudent approach is to enjoy vibe coding’s benefits with eyes open to its limitations. Use it to accelerate and inspire, not to abdicate responsibility for your code.

In conclusion, vibe coding is “shoot-and-forget” coding in the sense that you fire off prompts and don’t look back at the code, a strategy viable only in limited contexts. There’s nothing wrong with leveraging AI to write code quickly; just recognize that “forgetting the code exists” is not a sustainable strategy beyond the short term. The fundamentals of good software, clear logic, maintainability, security, and yes, human understanding – still apply. Far from making human programmers obsolete, vibe coding highlights why their skills are indispensable: to direct the AI, to verify and improve its outputs, and to handle the hard problems that can’t be solved by shortcuts. Panaceas don’t exist in software. AI coding is a powerful tool, but real-world coding requires more than vibes; it requires solid engineering beneath the hype.