Vibe Coding in Enterprise Software
Development (2025): State of the Art, Risks, and Best Practices
Introduction
“Vibe coding” refers to an emerging approach to software development where programmers (or even non-programmers) build applications by giving AI tools high-level natural language prompts and trusting the AI to generate the code. Instead of carefully crafting every line, the developer guides the AI with rough instructions — e.g. “Fix this bug” or “Add a nickname field” — and lets the model figure out the implementation details. The term was popularized in early 2025 by AI pioneer Andrej Karpathy, who described vibe coding as “fully giv[ing] in to the vibes” of AI-generated development. In essence, the hottest new programming language becomes English, as developers converse with AI to create software.
This paradigm gained significant buzz in 2025, with Karpathy and others demonstrating that even complex apps can be built through conversational prompts rather than traditional coding. Tech media dubbed “vibe coding” Silicon Valley’s latest trend, and user-friendly AI coding assistants have proliferated. But can enterprise software — the kind of large-scale, mission-critical applications that must run reliably in production for years — truly be built on vibes? This report examines the state of the art in vibe coding tools, the promises and pitfalls of this approach, and its suitability for enterprise projects requiring long-term maintenance.
State of the Art in 2025: AI Coding Tools and “Vibe Coding”
AI-assisted coding has rapidly advanced from simple autocomplete to powerful “co-pilot” systems. A number of new tools epitomize the vibe coding trend by tightly integrating AI into the development workflow:
- Cursor (https://www.cursor.com/)— an AI-powered code editor (a modified VS Code) that brings chat-based assistance directly into your IDE. With Cursor, a developer can highlight code and issue natural language instructions (e.g. “Optimize this function” or “Explain what this does”), and the AI will refactor or describe the code in-place. Cursor emphasizes fine-grained control — it won’t change things unless directed, making it feel like a diligent assistant waiting for commands. It had attracted tens of thousands of users by late 2024, indicating strong interest in embedded AI helpers.
- WindSurf (https://windsurf.com/) — another AI-first IDE (built by Codeium) that takes a more agent-driven approach. WindSurf’s AI agent (“Cascade”) can autonomously perform multi-step coding tasks across a project, not just autocomplete lines. For example, you can tell it to implement a feature, and it will generate a step-by-step plan, open the relevant files, apply code changes in multiple places, and even suggest terminal commands or run tests. WindSurf’s goal is to keep the developer in a flow state, letting the AI handle many low-level details — essentially an “autopilot” for coding. This makes it appealing for users who want the AI to take more initiative, beyond just on-demand prompts.
- Bolt.new (https://bolt.new/?rid=gaowwz)— a web-based AI development platform (from StackBlitz) that asks “What do you want to build?” and then generates a full-stack application from the prompt. Bolt allows users to prompt, run, edit, and deploy apps entirely in the browser, abstracting away most manual coding. For instance, New York Times columnist Kevin Roose (a self-proclaimed non-programmer) used Bolt to create a “LunchBox Buddy” app that scans fridge contents to suggest recipes. Bolt’s ability to turn a single high-level idea into a working web app exemplifies vibe coding’s promise of “few prompts away from a product”. In Roose’s case, he simply described what he wanted and Bolt produced a functional app (with AI doing the heavy lifting of coding).
- Replit (https://replit.com/refer/santismm) — a cloud-native “all-in-one” IDE that blends coding, runtime, and deployment in a single browser tab. Its Ghostwriter AI suite (chat, inline completion, Explain, and Transform) lets you highlight code and ask for refactors, explanations, or tests — showing every diff so you stay in control. Because every repl runs instantly on Replit’s servers, Ghostwriter can compile, execute, and even rollback deployments, giving the AI a feedback loop that feels like pair-programming with CI/CD built-in. By mid-2024 the platform had passed 20 million registered developers and was rolling out one-click Deployments and versioned Rollbacks, turning an AI-generated prototype into a public web app in minutes. In vibe-coding terms, Replit sits between Cursor’s surgical edits and Bolt’s one-prompt scaffolding: it can scaffold a full Flask API from a single sentence, but it keeps the human “in the loop” by streaming code as it runs and letting teams watch (and interrupt) the AI’s edits in real time — ideal for classrooms, hackathons, and rapid prototyping.
- Lovable (https://lovable.dev/?via=ssm) — Lovable is an AI-driven tool designed with a primary focus on enabling users to quickly transform their ideas into functional applications. It emphasizes ease of use and provides a guided development experience, making it accessible to a wide range of users. Users have found Lovable to be straightforward to use and capable of producing good results, particularly for smaller, less complex tools. However, it has been noted that Lovable may not be suitable for more intricate projects, such as those built with the NextJS framework. Currently, Lovable is in a free beta phase, with a professional version anticipated to be released in the future. Lovable appears to be tailored for individuals who prioritize simplicity and speed in the creation of basic applications, potentially targeting non-technical users or those who are new to the world of coding. Its description as a tool that can take an “Idea to app in seconds” highlights its focus on an intuitive interface and a guided approach, aiming to make app development accessible even to those without extensive technical expertise.
- Devika (https://devikaai.org/) — Devika stands out as an open-source AI software engineer that is designed to interpret high-level instructions and break them down into a series of actionable development tasks. Its architecture is intended to mimic the behavior of a junior developer, incorporating advanced planning and reasoning algorithms, contextual keyword extraction for precision, and dynamic agent tracking and decision-making capabilities. As a community-driven alternative to commercially available AI coding platforms, Devika emphasizes user control and transparency in the AI-assisted development process. A key advantage of Devika is its open-source nature, which allows developers to delegate complex coding work while retaining full oversight and control over how the AI agent operates. However, effectively guiding Devika may require a more thorough understanding of the software development lifecycle to ensure that the high-level instructions provided are sufficiently detailed and unambiguous. As an open-source project, Devika is likely free to use, although there might be costs associated with setting up and running the necessary infrastructure. Devika’s open-source nature offers developers a greater degree of control and transparency over the AI agent’s processes, which may be particularly appealing to those who prefer community-driven solutions and the ability to inspect and modify the tool’s underlying code.
- Cody (https://sourcegraph.com/cody) — Cody, developed by Sourcegraph, is presented as an AI coding assistant with a deep understanding of an entire codebase. It excels at tasks such as answering questions related to vast code repositories, performing intelligent code refactoring, and providing precise search and navigation capabilities. Cody seamlessly integrates with popular integrated development environments (IDEs) like VS Code, Visual Studio, Eclipse, and JetBrains, making it a versatile tool for many developers. A significant benefit of using Cody is its ability to comprehend and work with large and complex codebases, offering contextually aware suggestions that are highly relevant. It is particularly useful for experienced developers who need assistance in navigating, understanding, and refactoring extensive projects. While the pricing for Cody was not explicitly detailed in all the provided snippets, information from another Sourcegraph product, Zencoder, suggests a tiered pricing structure that includes a Free Plan, a Business Plan starting at $19 per user per month, and an Enterprise Plan starting at $39 per user per month. It is advisable to consult Cody’s official pricing page for the most accurate information. Cody appears to be especially well-suited for seasoned developers working with substantial and intricate codebases due to its robust understanding of project context.4 Its capacity to analyze entire codebases and provide contextually relevant suggestions makes it a valuable asset for navigating and modifying large projects, which can often be challenging to comprehend and maintain. This indicates a focus on supporting professional developers in their existing workflows.
- Advanced AI Agents (e.g. Manus AI) https://manus.im/invitation/9PHHZCB8OIEGE — Beyond IDEs, 2025 also saw “AI agents” like Manus that operate at an even higher level of autonomy. Instead of a back-and-forth chat, Manus lets the user specify an overall goal, then handles the entire coding process: “Build a basic login page” for example. The agent will generate the necessary code, run it, check for errors, debug, and continue iterating without needing the user to prompt each step. In effect, Manus acts like a junior developer who can interpret a request, attempt an implementation, test it, and fix mistakes on its own. Demos showed it creating features (e.g. UI components matching a given style) with minimal human intervention. This “delegation” style of vibe coding is cutting-edge — it pushes the envelope from conversational coding toward fully automated development. However, it also raises the question of how much a human developer remains “in the loop” to guide or verify the work.
Adoption and momentum. Vibe coding techniques have quickly moved from novelty to mainstream discussion. By early 2025, major tech outlets were reporting on a surge of interest in AI-generated code. Y Combinator revealed that 25% of startups in its Winter 2025 batch had codebases at least 95% AI-generated — an astonishing figure that signals a shift in how new software companies are bootstrapping products. Replit’s CEO Amjad Masad noted that “75% of Replit customers never write a single line of code”, highlighting how many users rely on its AI tooling to handle the actual coding. Even large tech firms are experimenting: Google’s CEO Sundar Pichai said over one-fourth of new code deployed at Google in 2025 was AI-generated (albeit likely with human oversight). In short, the state of the art shows AI-assisted coding becoming commonplace — from hobbyists building apps by chatting with GPT-like models, to startups speeding up development, and enterprises integrating AI suggestions into their pipelines. The tools (Cursor, WindSurf, Bolt, Manus, Replit and others) are continually improving at understanding natural language intents and producing workable code. This momentum suggests vibe coding is not just a fad, but part of a broader evolution in how software is created.
Why the excitement? The appeal of vibe coding lies in its potential benefits:
- Rapid development and prototyping: It dramatically accelerates going from idea to working software. Users report being “only a few prompts away from a product”, enabling rapid prototyping. For example, a startup founder used vibe coding to build a PDF-to-video app (Brainy Docs) quickly; if the AI made mistakes, he’d simply feed the errors back for a fix, reaching a functional product with minimal manual coding.
- Lower barrier to entry: Non-engineers or junior devs can create useful tools without deep programming knowledge. Roose’s experience — building multiple personal apps despite “not [being] a programmer” — shows that “with a few keystrokes, amateurs can now build products that previously required teams of engineers”. Vibe coding shifts some of the burden of syntax and API minutiae to the AI, letting creators focus on high-level functionality.
- Increased productivity for engineers: When used by experienced developers, these AI copilots can handle boilerplate code and routine tasks. This frees humans to work on design, complex logic, or polish. Some engineers also use vibe coding as a way to learn new languages or frameworks quickly, by having the AI generate code in an unfamiliar tech stack and studying the results. In other words, the AI can act as a tutor or accelerate the “scaffolding” of a new project, which the developer can then refine.
Despite these advantages, serious concerns are emerging about how far one can trust vibe coding, especially for production-quality enterprise software. Early adopters have found that along with the good vibes come very real limitations. The next sections examine the key criticisms and long-term risks of vibe coding — crucial factors for any organization considering this approach for maintainable, long-lived systems.
Criticisms and Challenges of Vibe Coding (Especially for Enterprises)
Enthusiasts might call vibe coding “magical,” but seasoned engineers and researchers have raised significant criticisms of relying too heavily on this method. These challenges are particularly acute in enterprise scenarios where code quality, consistency, and reliability matter deeply.
“Black box” code and lack of understanding. A core issue is that vibe coding encourages developers to accept code without fully understanding it. Simon Willison, an experienced developer and AI researcher, draws an important line: if you use an LLM to generate code but you review and comprehend every line, then “that’s not vibe coding…that’s using an LLM as a typing assistant.” In true vibe coding, you don’t have full insight into what the AI produced. This opaque understanding can be dangerous. The developer might end up with a codebase that “works” initially but contains latent bugs or logic quirks that no one on the team fully grasps. As one commentator quipped, “vibe coding is all fun and games until you have to vibe debug.” Debugging AI-written code can be painfully difficult if the human didn’t reason through the code in the first place. In enterprise development, where teams need to collaboratively modify and troubleshoot code over years, this lack of transparency is a red flag.
High initial output, but struggles with iteration. Vibe coding tends to shine in getting something working quickly, but falters when requirements evolve or the project grows in complexity. Venture capitalist Andrew Chen tried building features with the latest AI codegen tools and found “you can get the first 75% [of an app] trivially… then try to make changes and iterate, and it’s… enormously frustrating.” Many have observed this pattern: the AI is great at producing an MVP (minimum viable product) or the “happy path” implementation, but if you need to refine the logic, handle edge cases, or adjust specifications, the model might go off the rails. It may introduce regressions or require re-prompting from scratch. An experienced Microsoft engineer, speaking anonymously, noted that large language models are “great for one-off tasks but not good at maintaining or extending projects. [As projects grow] they get lost in the requirements and generate a lot of nonsense content.” In an enterprise setting, software is never one-and-done — it must be maintained and enhanced continuously. Vibe coding currently copes poorly with iterative development and long-term evolution, often necessitating substantial human rework for subsequent changes.
Overhype and reliability issues. Some experts simply feel the hype has outpaced reality. That Microsoft engineer called vibe coding “a little overhyped”— it’s not a magic wand that can replace sound engineering practices. Indeed, AI coding tools can and do make mistakes. Roose recounts how some of his AI-built projects malfunctioned or behaved oddly: one model-generated website “made up fake reviews” from a business’s Yelp page and inserted them into the site. In another attempt, the AI-built web app left out half of the intended content. Such hallucinations and omissions undermine trust. For trivial apps this might be no big deal, but for enterprise software, accuracy is paramount — you can’t have an AI inventing data or skipping important steps. This ties back to the need for rigorous review: without careful human validation, vibe-coded software can incorporate subtle errors that only surface later.
Even when the AI’s output is correct, there are practical limits that can halt vibe coding in its tracks. Notably, context size and scope — an LLM might handle a small codebase, but enterprise systems are huge. The AI can’t “see” the entire codebase if it exceeds the model’s context window, leading to inconsistent or incomplete modifications. Integration with external systems is another challenge. Roose struggled for weeks trying to vibe-code an “inbox autopilot” email responder because integrating with real email services and workflows was beyond the AI’s straightforward capabilities. This reflects a general issue: enterprise apps often must interface with other systems, legacy databases, specialized protocols, etc., which may not be well-represented in the AI’s training or easily expressed in a prompt. In such cases, the AI can hit a wall, and a human developer must step in to write glue code or solve novel problems that the model can’t.
Maintainer’s dilemma and team workflow. When one developer uses vibe coding to generate a large chunk of a system, their team members face a dilemma: how to trust and work with that code. If the original author themselves might not fully grok the code (having simply accepted the AI’s output), other engineers will be even more wary. Code reviews become tricky — reviewing AI-written code is like reviewing a junior developer’s work who can produce lots of code very fast but might not understand the implications. Reviewers often end up essentially rewriting or heavily refactoring such code to meet standards, negating the supposed time savings. Moreover, if each team member is vibe coding independently, ensuring consistency in style and architecture is hard — one model might generate code in one style and another differently. Without strong guidelines, an AI-generated codebase can become a patchwork of disparate patterns. Many enterprises have strict coding standards and design rules precisely to avoid this kind of inconsistency and sprawl.
In summary, vibe coding flips the traditional development script — you get speed and convenience at the cost of clarity and predictability. For enterprises, this trade-off presents serious challenges. We next analyze the long-term risks if a company leans heavily on vibe coding for production software.
Long-Term Risks of Vibe Coding for Production Software
Building an enterprise application is not just about getting it to work today — it must remain reliable, secure, and adaptable for years. Here are the major long-term risk factors when using vibe coding for serious software projects:
- Maintainability and Knowledge Retention: Code that was generated by an AI and accepted without full understanding is inherently hard to maintain. Future developers may struggle to modify or extend it, because they don’t know the rationale behind certain implementations. As one AI expert put it, “most of the work we do as software engineers involves evolving existing systems, where the quality and understandability of the underlying code is crucial.” If nobody on the team truly understands the AI-written modules in an application, maintaining or evolving that system becomes risky and slow. In the long run, unclear code is far more costly — each bug fix or feature addition could introduce new errors if the maintainers are guessing at how the code works.
- Code Quality and Technical Debt: Vibe coding can introduce shortcuts and suboptimal solutions that accumulate as technical debt. The AI might choose an approach that works for now but is not the best long-term strategy (e.g. a quick hacky fix for a bug, or an inefficient algorithm). Without a human architecting the system, the result may lack a coherent structure. As the codebase grows, these hidden issues compound, making the software fragile. One expert warned that overreliance on AI-generated code can make the project “unmanageable during the scaling or debugging process”, i.e. as soon as you try to scale up, the cracks begin to show. In enterprise contexts, such technical debt can derail projects or require costly re-engineering down the line. It’s telling that Karpathy himself, after experimenting, conceded vibe coding was “not too bad for throwaway weekend projects” but only “quite amusing” — hardly an endorsement for production use.
- Scalability and Performance: AI models tend to provide a generic implementation that satisfies the prompt, but they don’t inherently optimize for performance or scalability unless explicitly asked (and the user might not know to ask, or how to phrase it). For a small user base or dataset, a vibe-coded solution might seem fine; but under enterprise workloads (thousands of users, large data volumes), naive implementations can choke. For example, an AI might pick an O(n²) algorithm because it works on the sample data — a human developer aware of scale would choose a more efficient approach. Similarly, system architecture (caching, concurrency, distributed design) is something experienced engineers plan for scalability — an AI focusing only on functional requirements might neglect those aspects. This means vibe-coded systems can hit performance bottlenecks or require significant rework to scale up to enterprise demands.
- Security Vulnerabilities: Security is a major concern with AI-generated code. If developers are unaware of secure coding practices, the AI may introduce vulnerabilities — e.g. using outdated encryption, not sanitizing inputs (leading to SQL injection or XSS), or exposing secrets. One industry expert noted that “security vulnerabilities may slip through without proper code review” when using vibe coding. This is because the AI will produce code that looks plausible, but it does not have a true understanding of security context; it might even regurgitate insecure code patterns found in training data. Enterprises face high stakes here: a vulnerability in production can lead to data breaches, legal liability, and damage to reputation. If vibe coding is used, rigorous security audits and testing become mandatory, potentially eating away any time savings. There’s also an accountability issue — if an AI wrote a flawed piece of code, who is responsible for the bug or breach? Developers must take ownership, but that loops back to the fact that they might not have full insight into AI-generated code.
- Compliance and Auditability: Many enterprises operate in regulated industries (finance, healthcare, etc.) or have internal compliance standards. They need to audit code changes, ensure proper documentation, and sometimes even prove correctness or adherence to standards. AI-generated code can be problematic in this regard. It may not produce proper documentation or comments explaining its logic. Additionally, if an audit asks “why does this function do X,” the answer “an AI wrote it” is not acceptable — someone needs to reverse-engineer the intent. Compliance standards (like MISRA for automotive code, or FDA guidelines for medical software) often require clear traceability from requirements to implementation. Vibe coding, which is more ad-hoc, struggles with such traceability. An auditor might also raise concerns about IP or licensing: did the AI inadvertently include code that has a restrictive open-source license? (It’s happened before with AI models regurgitating licensed code, though rare.) Long-term, the opacity and unpredictability of vibe coding make compliance harder.
- Tool/Model Dependency: Relying heavily on a specific AI tool (Cursor, Manus, etc.) could introduce a form of vendor or model lock-in. If your team gets used to “vibing” with a certain AI and that service changes (pricing, model updates, or it shuts down), you may be left stranded with code that was partially written in a proprietary format or style. While the code itself remains, future development might depend on again using an AI. For example, a codebase that was largely created by AI might be written in a way that assumes AI assistance for further edits. If that AI is no longer available, maintaining the code manually could be more arduous than if it had been written by human conventions from the start. This is more of a strategic risk, but enterprises do consider long-term tool stability and supplier risk in their decisions.
- Developer Skill Atrophy: Over-reliance on vibe coding might in the long run erode the engineering skills within a team. Newer developers who skip directly to AI assistance may not build the deep understanding of programming concepts that their predecessors did. As one expert observed, “ease of use is a double-edged sword — beginners can make fast progress, but it might prevent them from learning about system architecture or performance.” If an enterprise’s developers as a whole start depending on AI for every task, they might struggle to debug complex problems or innovate new solutions (areas where human intuition and experience are crucial). This risk is more abstract, but real: it could create a workforce that is great at prompting AI, but less adept at traditional coding and critical thinking about software design. In a crisis — say a severe production outage — those skills are needed to quickly diagnose and fix issues that an AI didn’t foresee.
In summary, while vibe coding can speed up development, the long-term costs and risks can easily outweigh those initial gains if not managed properly. As Ars Technica succinctly put it, “vibe coding your way to a production codebase is clearly risky”, especially because down the road you must live with that code. For enterprises, qualities like maintainability, reliability, security, and clarity of code are not optional — they are essential. Vibe coding as of 2025 has not proven it can consistently meet those standards across the full software lifecycle.
SMEs vs. Large Enterprises: Differing Impacts and Considerations
The implications of vibe coding can vary depending on the size and maturity of the organization. A small startup and a Fortune 500 enterprise have very different constraints and priorities, which affect how (or if) they should use vibe coding.
In Startups and SMBs (Small/Medium Businesses): Smaller companies often prioritize speed and agility. For a scrappy startup trying to get an MVP to market or impress investors in a short time, vibe coding is enticing. It allows a tiny dev team (or even a solo founder) to produce a working product demo in days, something that traditionally might take a team weeks. Indeed, many startups are jumping on this trend — recall that 25% of YC Winter 2025 startups had majority-AI codebases. For a startup, the immediate benefit of getting to production faster or with fewer developers can be the difference between success and failure. Vibe coding can also help a small team punch above its weight, implementing features in domains where they lack expertise by leveraging the AI’s knowledge.
However, the flip side is that startups risk building on a shaky foundation. If the product takes off, that quick-and-dirty AI-generated code may become a maintenance headache. Small companies often lack dedicated QA, security teams, or robust processes — so a vibe-coded application might accumulate a lot of undiscovered bugs or security flaws until it’s too late. A startup can perhaps get away with some messiness when user counts are low, but if they succeed, they might face a painful refactor or rewrite later (which is hardest to do right when the company is scaling up fast). In some cases, this “technical debt time-bomb” could hinder a startup’s growth — what saved time in development could cost them time (and money) in firefighting or rebuilding in year 2 or 3. Startups have to strike a balance: use vibe coding to move fast, but be ready to allocate resources to harden and clean up the code if the project shows traction. Many experienced startup CTOs will insist on a rewrite of a quick prototype before it becomes the official product, to incorporate proper architecture. With vibe coding, that discipline is still needed, perhaps even more so. As one AI engineer cautioned, “a good enough prototype often faces pressure to get pushed to production” — and giving in to that pressure without refactoring can leave a young company carrying a heavy load of tech debt.
On the positive side, SMEs typically have less red tape than large enterprises, so they can experiment with vibe coding more freely. They might accept the risks in exchange for rapid development, especially if the application’s domain is relatively low-risk. For example, a small B2B SaaS startup might vibe-code an internal tool or a non-critical feature to save time, whereas they would hand-code the core payment processing module more carefully. The smaller the scope and user impact, the safer it is to use vibe coding in a small company context.
In Large Enterprises: Big companies have established software development lifecycles, extensive testing/QA, security review processes, and often strict regulatory requirements. Any new development approach has to integrate into this machinery. Enterprises will appreciate the productivity boost of AI coding assistants, but they are generally far more cautious about adopting something like full-on vibe coding. The risks discussed (security, maintainability, etc.) weigh heavily when you have millions of users or critical business functions depending on the software.
Enterprise development tends to involve large, complex systems that have been built over years by many developers. It’s unrealistic to throw an AI at an entire legacy codebase and expect to “vibe” out new features without extensive human guidance — the context window limitations and integration complexity make that infeasible. Instead, enterprises might use AI in narrower ways: for instance, to generate unit tests, to refactor small modules, or to assist developers by suggesting code snippets. In other words, they are more likely to use the AI as an assistant within the existing workflow (like Cursor’s model of waiting for specific instructions) rather than an autonomous project builder. A banking or healthcare company is unlikely to allow a Manus-style agent to build an app end-to-end and deploy it without human code reviews, no matter how tempting. The stakes are simply too high. As Ars Technica noted, “enterprise environments typically require code maintainability and reliability standards that vibe-coded solutions may struggle to meet”. Large firms will generally insist on those standards being met, which means lots of testing and oversight of any AI-generated code.
Another factor is compliance and data privacy — large companies often have policies preventing developers from pasting proprietary code or data into external AI services. This could limit the use of cloud-based vibe coding tools (like an online AI IDE) on sensitive projects. We are starting to see on-premise or self-hosted AI code assistants as a response, but those might not be as powerful or up-to-date as something like OpenAI’s latest model. Thus, a big enterprise might hold back on vibe coding simply due to legal/compliance concerns about where the code goes and what the AI might learn or leak. For SMEs, this is usually less of a concern (they are more willing to use cloud tools and don’t have legacy sensitive data).
Cultural impact: In a large engineering organization, there is often resistance to approaches that bypass the collective knowledge and best practices of the team. If an individual engineer started committing large chunks of AI-generated code, they’d likely be met with heavy code review criticism from peers who prefer clarity and adherence to the team’s standards. In contrast, in a small startup, the culture might be more “wild west” and open to trying anything that works. Large enterprises also have more bureaucracy — introducing vibe coding might require approvals, pilot programs, proving it doesn’t decrease quality, etc.
In summary, small companies stand to gain the most immediate benefit from vibe coding’s speed, but also risk the most if they don’t mitigate the downsides. Large companies have the resources and knowledge to mitigate those downsides — but their tolerance for risk is low, so they will likely adopt a very constrained form of AI-assisted coding, not the freewheeling “just vibe it” ethos. As one senior engineer said, the vibe coding idea is overhyped for big projects — LLMs can’t maintain or extend large systems reliably. For large enterprises, the motto remains: move fast but without breaking things.
Best Practices and Recommendations: When to Use Vibe Coding (and When Not To)
Given the above analysis, here are clear recommendations for using vibe coding in an enterprise context:
When Vibe Coding Can Be Beneficial:
- Prototyping and Ideation: Use vibe coding for rapid prototypes, hackathon projects, or “proof of concept” work. In these cases, speed of development is more important than code robustness. It’s a great way to explore an idea or validate a feature. For example: a product team could whip up a demo with an AI-generated code to show stakeholders. Keep such code disposable — Andrej Karpathy found the technique “not too bad” for throwaway weekend projects, which is an apt description. If the prototype shows promise, plan to rewrite or thoroughly audit it before production. As Simon Willison warns, “stay aware of the very real risk that a good enough prototype [built by AI] often faces pressure to get pushed to production” — fight that pressure unless the code is brought up to standards.
- Internal Tools with Limited Scope: If you need to automate an internal process or create a small utility for use within the company (where an occasional glitch is tolerable), vibe coding can save time. For instance, an internal dashboard for monitoring logs or a script to convert data formats could be largely AI-generated. These are usually not customer-facing and can be fixed on the fly if issues occur. Still, ensure someone on the team reviews the output; the relaxed tolerance is not an excuse for security holes even in internal tools.
- Learning and Onboarding: Encourage junior developers or developers working with a new technology to experiment with vibe coding in a sandbox. Having the AI generate code can quickly teach them new patterns. Three engineers interviewed by IEEE Spectrum noted that vibe coding is a useful way to learn unfamiliar languages or tech stacks by example. This should be coupled with learning — after AI generates something, the dev should study it to understand how it works (otherwise, as noted, it isn’t truly vibe coding but rather just assisted learning). Using vibe coding as a learning tool can upskill your team, as long as they don’t become blindly reliant on it.
- Routine Boilerplate Generation: In enterprise projects, there’s often a lot of boilerplate (repetitive code) — e.g., model classes, CRUD interfaces, configuration files. Letting an AI handle these can be a huge time saver and relatively low risk, since it’s easy to verify correctness (does it compile? Does it follow the template?). Many teams already use AI suggestions for writing unit tests, documentation stubs, etc. This fits within a controlled use of vibe coding — the human specifies the pattern, the AI fills it in, and the human validates the result. Essentially, the AI works as a junior developer performing rote tasks, freeing humans for the complex parts.
When to Avoid or Heavily Supervise Vibe Coding:
- Core Business-Critical Code: Do not vibe code the heart of your application — the core algorithms, security-sensitive components, financial calculation logic, etc. These are the pieces that absolutely must be correct, well-understood, and maintainable. Hand these to experienced developers. If AI is used at all here, treat it as an assistant: double-check every line it produces. Remember the guideline: if you fully reviewed and understood the AI’s code, you haven’t done vibe coding, you’ve done traditional coding with assistance — which is fine! But if you don’t have time to rigorously review, then you shouldn’t let AI write these parts unattended. As Kevin Roose concluded, vibe coding is “probably best for hobby projects, not essential tasks.” In an enterprise, “essential tasks” covers anything that could harm the business if it fails.
- Large-Scale or Long-Lived Projects (without a plan): If you’re starting a new major software project that is intended to live for many years, be very cautious about jumping in with vibe coding from the start. It might get you an MVP quickly, but think about year 5: will the codebase be understandable? As one engineer put it, AI tools tend to “get lost” as a project grows. If you do use AI heavily at project inception, allocate time for refactoring and adding documentation while things are still manageable. It may even be wise to limit AI contributions to certain layers of the architecture — e.g., allow it for UI layout code (which can be easily re-generated or tweaked later), but not for the critical business logic. Also, insist on test coverage for AI-generated code to have safety nets for the future. Without such discipline, a large vibe-coded project could become a maintenance nightmare, as discussed.
- When security and compliance are non-negotiable: In domains like finance, healthcare, aerospace, etc., where software must meet regulatory standards, vibe coding should be avoided unless the output is meticulously verified. For example, an FDA-approved medical device’s software can’t have “mystery code” that the team doesn’t fully understand — that’s a compliance failure. Similarly, if an application handles sensitive data (PII, financial records), developers should be extremely careful about using AI tools that send code or data to external servers. In such cases, one might limit AI usage to offline or on-prem models that have been vetted, and still undergo thorough human review. Bottom line: If you wouldn’t copy-paste random code from the internet into this component, you shouldn’t blindly accept AI code for it either.
- Without Proper Oversight and Testing: If an organization doesn’t have strong testing practices or code review culture, then introducing vibe coding is risky. AI or not, untested code is a recipe for bugs. But AI code in particular might have non-obvious failure modes. It’s essential to have automated tests that can catch regressions or incorrect functionality in AI-written code. Additionally, code reviews should remain in force — perhaps even requiring two pairs of eyes on AI-generated segments. If your enterprise development process can’t accommodate that (for instance, if timelines are so rushed that code is rarely reviewed or tested), then it’s better to avoid vibe coding because it could significantly increase the defect rate. In contrast, in organizations with rigorous processes, AI-generated code can be held to the same standards as human code — which will slow things down a bit but yield a more reliable outcome.
General Best Practices: Even when using vibe coding in the recommended scenarios, a few practices can mitigate risks:
- Keep the human in the loop. Use the AI as a collaborator, not an autonomous coder. Ask it for code, but read and understand the code before integrating it. If something is confusing, ask the AI (or a teammate) for an explanation. Treat the AI kind of like a junior dev — helpful, but needing guidance and supervision.
- Iterate with small steps. Rather than asking the AI to build a huge feature in one go, break the task into smaller prompts. This makes it easier to pinpoint where an error comes in and to ensure each piece is correct. It also reduces the chance of the model “getting lost” in a long session.
- Enforce coding standards. Many AI code tools can be steered with style guidelines. For example, you can prompt, “Write this in our company’s coding style with proper docstrings.” Consistency in output makes maintenance easier. If the tool allows it, provide it with templates or examples of desired patterns. Some enterprise-focused AI dev tools let you train or customize them on your codebase so they adhere to your norms.
- Don’t stop learning. Encourage developers to analyze the AI’s contributions and learn from them. The goal should be that over time, your human team becomes even more skilled — leveraging AI to see different approaches, then internalizing the good patterns. If a piece of AI-generated code is too perplexing to explain to a colleague, that’s a sign it doesn’t belong in the codebase until understood or simplified. As Willison emphasizes, “if you’re going to put your name to [code], you need to be confident you understand how and why it works”.
Concrete Use Cases: Where Vibe Coding Works — and Where It Doesn’t
To illustrate these principles, let’s look at a few scenarios:
- Use Case 1 — Startup MVP: A small fintech startup wants to test an idea for a budgeting app. They have one developer (also the founder) and need a prototype for investor demos. Using an AI coding assistant, the founder manages to build an end-to-end mobile app in a couple of weeks by prompting the AI to create the frontend screens, login system, and a basic analytics backend. This is a classic vibe coding success story — it saved time and the prototype impresses investors. Why it’s appropriate: The code doesn’t need to be perfect; it just needs to demo the concept. The founder is prepared that if the startup gets funded, they will hire engineers to rewrite or productionize the code. In fact, they treated the AI-generated code as a throwaway prototype. During development, the founder also learned a lot by seeing how the AI structured the app, which helps in guiding the rewrite. Here vibe coding provided speed and a learning experience, with minimal downside because the team consciously limited its long-term reliance on that exact code.
- Use Case 2 — Internal Data Dashboard in a Mid-size Company: A mid-size e-commerce company’s ops team needs a custom dashboard to monitor real-time orders and inventory, something not available in their off-the-shelf ERP system. The engineering team is busy with customer-facing features, so an analyst with some tech skills decides to try an AI tool to create the dashboard quickly. Using a tool like WindSurf or Cursor, they generate a web dashboard that pulls data from the database and displays charts. It’s done in a day and works well enough for the ops team. Why it’s appropriate: This is an internal tool with read-only data access. If it breaks, it’s not visible to customers and can be fixed without major consequence. The quick turnaround was valuable. However, after initial deployment, a senior engineer does spend an afternoon reviewing the code, adding some error handling and authentication (the AI omitted those). With a few tweaks and security checks, the dashboard is safe to use internally. Here vibe coding was used as a force multiplier for a non-developer and then validated by a developer — a good balance.
- Use Case 3 — Major E-Commerce Platform Feature (Not suitable): Now imagine that same e-commerce company decides to add a new feature to its customer website — say, an AI-driven recommendation engine on product pages. This is complex, customer-facing, and ties into many parts of the system (product database, user history, etc.). If a developer attempted to vibe-code this entire feature, things could go awry. The AI might produce some recommendation algorithm and hook it up, but perhaps it doesn’t scale well or has security issues. It might use the wrong data, or not handle edge cases (like a user with no history). The code would be hard for others to maintain because it wasn’t designed with the team’s input. This is a case where vibe coding is inappropriate without heavy supervision. The company instead should use AI in a limited way: maybe use it to generate boilerplate for the recommendation service, but have data scientists design the algorithm and engineers integrate it properly. They should write tests to validate the recommendations. In short, for a core production feature with high impact, they should not rely on AI to make architectural decisions. If they had gone the vibe route, likely they’d face issues in production — perhaps the service crashes under load or gives nonsensical suggestions in some cases, requiring urgent intervention and refactoring. The cost of those fixes could outweigh any initial speed gain.
- Use Case 4 — Legacy System Migration (Not suitable): A large bank wants to migrate part of its COBOL mainframe system to a modern stack. If someone suggests feeding the entire COBOL code into an AI and letting it spit out Java or Python, that would be extremely risky. The chance of subtle errors in financial calculations, or mismatches in business logic, is high. And verifying the correctness would be an enormous task — essentially you’d need to double-run old and new systems for every scenario. This is not a good use of vibe coding. Instead, AI could assist in smaller ways (maybe translating individual functions to get a starting point for developers to then carefully validate). The migration of a mission-critical, long-lived system should be done with full understanding at each step. History has shown that even manually, these projects are difficult — an automated, vibe-driven approach would likely fail or produce an unmaintainable result.
- Use Case 5 — Personal/Hobby Project: On the other end of the spectrum, consider an individual who wants a simple app to organize their personal photo collection. They decide to try vibe coding using a conversational AI coding tool. Over a weekend, they prompt the AI to create a small web app that categorizes photos by content. It mostly works, though it has a few quirks. This is perfectly fine — exactly the scenario vibe coding was made for. Why it’s fine: The stakes are zero (it’s for personal use, no sensitive data beyond their own, no one else impacted). The person doesn’t mind if occasionally the app mis-tags a photo or crashes; they can just restart it. They also don’t intend to maintain it long-term — if it breaks after the next OS update, maybe they’ll just build a new one with a then-updated AI. This scenario demonstrates that vibe coding can empower end-users to create niche software for themselves, an exciting development in its own right. Enterprises, however, rarely have the luxury of such low stakes.
Finally, it’s worth noting an anecdote that made headlines: an AI coding assistant (Cursor) actually refused to continue writing code for a user after about 800 lines, telling them “I cannot generate code for you, as that would be completing your work… you should develop the logic yourself.” This “tough love” moment (likely a built-in safeguard against over-reliance) humorously underscores that at some point, the human must take charge. In enterprise projects, developers should proactively take charge long before an AI taps out. Use vibe coding as a boost — not a crutch — and be mindful of its limits.
Conclusion
Vibe coding represents a new human–AI collaboration paradigm in software development. As of 2025, the tools and techniques have proven their ability to speed up development and lower barriers, but they are not a silver bullet for enterprise software engineering. The current state of the art — from AI-infused IDEs like Cursor and WindSurf to autonomous agents like Manus — gives us a glimpse of a future where coding feels more like brainstorming with a supercharged assistant. However, real-world experience and expert opinions make it clear that the fundamentals of software engineering remain unchanged: maintainable, high-quality software requires understanding, planning, testing, and oversight. In the words of Simon Willison, no matter how clever the AI, developers ultimately must “take accountability for the code [they] produce”.
Enterprises should approach vibe coding with both optimism and caution. It can certainly be part of the toolkit — for example, to automate tedious tasks or prototype new ideas quickly. When used wisely, it can even improve productivity and help teams focus on higher-level problems. But for long-term, production-critical software, vibe coding should augment, not replace, traditional development rigor. The “vibes” cannot carry a project through scaling, maintenance, and years of change — humans still need to do that heavy lifting (or at least closely supervise the AI if one day it can).
In practical terms, organizations might start by creating clear policies for AI-generated code: where it’s allowed, how it must be reviewed, and quality criteria it must meet before merging. By drawing those boundaries, teams can enjoy the creative and fast-paced “vibe” of AI-assisted coding in appropriate areas, without compromising the integrity of their core systems. As with any new technology, finding the right balance is key.
The concept of vibe coding is likely to evolve. We may see improved AI agents that can explain their code, tools that enforce standards automatically, and better integration of AI in the software lifecycle. These advancements could mitigate some risks over time. For now, though, any enterprise diving into vibe coding should conduct a reality check (or an “industry vibe check”, as one article quipped). Leverage these powerful new tools, but remain grounded in software engineering best practices. In short: code with vibes, but verify. The long-term success of your software may depend on it.
Sources
- Karpathy, Andrej — Introduced the term “vibe coding” (Feb 2025)en.wikipedia.org, en.wikipedia.org
- Roose, Kevin — “Not a Coder? With A.I., Just Having an Idea Can Be Enough.” (NYTimes, Feb 27, 2025)web.archive.org, web.archive.org
- Edwards, Benj. — “Will the future of software development run on vibes?” (Ars Technica, Mar 5, 2025)web.archive.org, web.archive.org
- Chowdhury, Hasan & Mann, Jyoti — “Silicon Valley’s next act: bringing ‘vibe coding’ to the world.” (Business Insider, Feb 13, 2025)businessinsider.com, businessinsider.com
- Business Insider — (ibid., on downsides and expert quotes)businessinsider.com, businessinsider.com
- IEEE Spectrum — “Engineers Embrace Vibe Coding.” (Matthew S. Smith, Apr 8, 2025)en.wikipedia.org
- Cursor Documentation/Medium — Discussion of Cursor, vibe coding UXmedium.com, medium.com
- WindSurf vs Cursor (Keith McFarland, Mar 6, 2025) — Feature comparison and “vibe coding” survivallinkedin.com, linkedin.com
- Manus.ai — Agentic coding demo medium.com
- Ars Technica — “AI coding assistant refuses to write code…” (Mar 13, 2025)en.wikipedia.org, ndtv.com
