Vibe Coding's Dark Side: How AI-Generated Code Creates Security Risks and Technical Debt

'Vibe coding' is fun and easy, but there's a major catch

Imagine you've always wanted your own app. Perhaps one that tracks your household budget, organises the family shopping list or reminds you when to water your plants. Until recently, turning that idea into reality would have meant learning to code or paying a software developer. Now you can simply tell an artificial intelligence (AI) chatbot about your idea. Within minutes, it can write the code, fix errors and help you build a working app. This approach is known as vibe coding. It's fast, exciting and is making it possible for millions of people to create software for the first time. It's easy to see why vibe coding has become so popular. Yet researchers have already found thousands of security flaws and exposed secrets in publicly available AI-generated applications. Software that appears to work isn't always software you can trust. What is vibe coding? The term "vibe coding" was coined by AI researcher Andrej Karpathy. Rather than writing the software yourself, you describe the outcome you want - or the "vibe" - in plain, everyday language and let AI generate most or all of the software. If something doesn't work, you ask the AI tool to fix it. You don't necessarily need to understand how the code works - you just keep prompting until you get the result you're after. Tools such as ChatGPT, Claude, Gemini and specialised generative AI based coding assistants have made this possible. In fact, the most recent survey by major coding platform Stack Overflow revealed that 84% of developers globally used or planned to use AI coding tools in 2025. And it's not just developers using them: recent stats indicate about 63% of users of vibe coding platforms are people without a programming background, building products and tools of their own. People with little or no programming experience can now build websites, apps and automated workflows (such as compiling documents or doing other complex tasks) in a fraction of the time it once took. Building reliable software Most people imagine software developers spend their days writing code. In reality, coding is only one part of a much bigger process. Before software is released, developers ask important questions. Does it work reliably? Is it secure? Can someone else maintain it? What happens if something goes wrong? They test different situations, review each other's work and fix problems before anyone else uses the software. These steps aren't there to slow developers down. They're there because even software that seems to work for its purpose can still expose sensitive data or disrupt critical systems. Vibe coding can make it tempting to skip much of this process. If the app appears to work, it's easy to assume the job is finished. The risks of vibe coding Now, suppose you ask AI to build an app to manage your household expenses. The app opens, records your purchases and calculates your spending. Everything seems fine. But is it calculating correctly in every situation? Is your financial information stored securely? What happens if the app crashes halfway through entering your monthly expenses? Or perhaps it stores your financial data in a way that's easy for others to access. The app does exactly what you asked - but your personal information may not be properly protected. These aren't questions most beginners think to ask, yet they're exactly the kinds of questions professional developers routinely consider. Fixing problems can also become frustrating. You ask the AI to solve one issue, only to discover it has introduced another somewhere else. Without understanding what the AI has changed, you're left relying on it to solve problems it may have created. When is vibe coding enough? None of this means vibe coding should be avoided entirely. It's an excellent way to experiment with ideas, learn programming concepts or quickly build personal tools. Entrepreneurs can create prototypes, hobbyists can automate repetitive tasks, and small organisations can explore ideas that might otherwise never get built. The risks increase when AI-generated software is treated as ready for real-world use simply because it works. Apps that handle personal information, financial transactions or business operations still need careful testing and human oversight, regardless of who - or what - wrote the code. In one security study, about 45% of AI-generated code samples failed standard security tests. The broader issue goes beyond coding. Researchers have long warned about "automation bias" - the tendency to accept recommendations from automated systems without adequately checking them. As AI becomes better at solving complex tasks, it's becoming easier to accept its answers without questioning them. Software is just one area where this can have serious consequences, because mistakes may remain hidden until something goes wrong. AI can write code, but it can't take responsibility Vibe coding is opening software development to people with great ideas but little programming experience. But making software easier to create doesn't make it easier to judge whether it's secure, reliable and ready for others to use. No matter how good AI becomes at generating code, people - not AI - must remain responsible for what that code does.

As a developer, I always thought vibe coding was overhyped - until I actually tried it

When I first started hearing people talk about vibe coding, I couldn't understand why so many developers were excited about it. The idea of describing what you wanted and letting AI generate most of the code felt completely opposite to how I'd learned software development. I always believed good developers should understand the code they write, not simply accept whatever an AI suggests. To me, programming was about solving problems, thinking through the architecture, debugging issues, and knowing exactly why a solution worked. AI-generated code seemed more like a shortcut than a better way to build software. I was also skeptical because the early AI coding tools weren't particularly convincing. They often produced code that looked correct at first glance but contained outdated practices, unnecessary complexity, or subtle bugs. Spending time reviewing and fixing AI-generated code didn't seem any faster than writing it myself. For those reasons, I ignored vibe coding for quite a while and assumed it was just another over-hyped AI trend. I tried it for small projects The biggest surprise wasn't the code quality Close I wasn't ready to trust AI with anything important, so I started with a few small personal projects instead. These were the kind of tasks that normally don't require much planning but still take time to build, like simple utilities, automation scripts, and small web apps. My goal wasn't to let AI do everything. I wanted to see whether it could actually speed up my workflow without creating more work later. The biggest surprise wasn't that the code was perfect; it wasn't. I still had to review the output, fix a few issues, and make changes to match what I wanted. What surprised me was how quickly I could move from an idea to a working prototype. Instead of spending time writing repetitive code or looking up syntax, I could focus on refining the feature and testing whether it solved the problem. That was the moment I started seeing why developers were embracing vibe coding. Vibe coding genuinely shines in some aspects This is where it started saving me time Close The more I used vibe coding, the more I realized it wasn't equally useful for every type of project. Where it really stood out was the repetitive work that most developers don't enjoy, anyway. Setting up project structures, writing boilerplate code, generating API endpoints, or creating simple UI components suddenly became much faster. Instead of spending time on routine tasks, I could jump straight to the part that actually required my attention. I also found it surprisingly helpful when learning something new. Rather than switching between documentation, Stack Overflow, and tutorials, I could ask AI to build a working example and explain why it was written that way. That made it much easier to understand unfamiliar libraries and frameworks. I still wouldn't blindly accept everything AI generated, but I found myself using it more often for tasks that were repetitive, time-consuming, or outside my usual expertise. That's where vibe coding delivered the biggest productivity gains. I realized vibe coding isn't really "coding less" AI changed my workflow, not my job The biggest shift for me was realizing that vibe coding didn't reduce the amount of thinking I had to do. It simply changed where I spent my time. Instead of writing every function from scratch, I spent more time planning features, reviewing AI-generated code, testing edge cases, and refining prompts until I got the result I wanted. In many ways, I felt more like a reviewer than a typist. AI could generate hundreds of lines of code in seconds, but it couldn't decide whether the solution actually fit my project or followed good development practices. That responsibility was still mine. I also learned that the quality of the output depended heavily on the instructions I gave. Clear prompts usually produced better results, while vague requests often led to unnecessary revisions. Vibe coding didn't replace my development skills; it relied on them. The better I understood the problem, the more useful AI became as a coding partner. What I still wouldn't use vibe coding for AI is my assistant, not my replacement Even after changing my opinion, I don't think vibe coding is the right approach for everything. I still wouldn't rely on it for projects where security, performance, or reliability are critical. If I'm building something that handles sensitive data or has complex business logic, I want to understand every important part of the code before it goes into production. I also avoid accepting large chunks of AI-generated code without reviewing them carefully. It's easy to miss inefficient logic, unnecessary dependencies, or edge cases that only show up later. AI can move fast, but speed doesn't replace careful engineering. For me, vibe coding works best as an assistant, not as a developer. It helps me write code faster, explore ideas more quickly, and reduce repetitive work, but the final decisions are still mine. That's probably the biggest lesson I learned. AI didn't replace my role as a developer; it simply changed how I approached it. I came for the hype, but stayed for the workflow Trying vibe coding didn't make me a different developer, but it did make me a more efficient one. It helped me spend less energy on repetitive work and more on building, experimenting, and improving ideas. At the same time, it reminded me that good software still depends on careful decisions, not just fast code generation. That's why I don't see AI as something to fear or blindly trust. I see it as another tool in my development workflow, much like an IDE or a debugger. My skepticism hasn't disappeared completely, but now it's backed by experience instead of assumptions.

Domesticating AI: Why vibe coding feels like cheating

"I'm going to call it Yaffle." That was the final line of my June New Atlas article, Domesticating AI: It's not coming, it's already here. It was a throwaway remark after spending some time with Home Assistant's increasingly capable AI voice assistant, Nabu. I'm ecstatic to report that Yaffle is now real and answers to "Hey Yaffle." The problem was that Yaffle first needed to learn its own name. I'd tried this before, and failed, and the result was simple: I stopped using it. "OK Nabu" never felt right. Teaching an AI assistant a custom wake word sounds like the sort of project you'd expect to find in the hands of a machine learning engineer. TensorFlow, speech datasets, model training - not exactly the sort of thing you'd tackle over a quiet weekend. Which presented a problem. I'm not a software engineer. Nor, I suspect, will one be turning up at my door to offer me a job. I started with Microsoft qualifications in the 1990s and have spent most of my career coaxing technology into doing useful things. I was happy enough with Notepad and HTML back in the day, but writing modern software? Training AI models? I'm just not a coder. My brain simply doesn't work that way. It put me well outside my comfort zone. Or at least it did! I'd been hearing the term "vibe coding," the latest catch-all phrase for building software by describing what you want an AI to do rather than writing every line yourself. The phrase has become almost as divisive as the technology behind it. Spend half an hour in Reddit's programming communities and you'll understand why. It's easy to see why many programmers feel aggrieved. As a musician, I watched exactly the same thing happen to my own industry through the 1990s and 2000s, when increasingly capable software turned bedroom musicians into chart acts. To many experienced developers, "vibe coding" has become shorthand for "people producing code they don't understand." There are frequent calls for AI-generated code to be disclosed, warnings about security and maintainability, and no shortage of frustration that someone with little formal programming knowledge can suddenly produce something useful. It would be easy to dismiss that as gatekeeping, but I don't think it is. If you've spent years mastering software engineering, algorithms, architecture, debugging and security, watching AI lower the barrier to entry must feel much as it did for professional musicians in the 1990s. Their concern is understandable, and experience still matters enormously. I just couldn't help feeling I'd seen this story before. When university spat me out in the 1990s with an electro-acoustic music degree, producing professional recordings demanded training, specialist studios and dare I say, talent. Then Digital Audio Workstations like Cubase happened and suddenly, the bedroom became the recording studio. Professionals were rightly aggrieved. Most of the music being produced was awful. But some of it wasn't. The same pattern repeated itself in photography. Skilled Photoshop artists spent years mastering masking, selections and retouching techniques, only to watch AI remove a complex background with a single click. Writers have seen grammar checkers become writing assistants. Graphic designers watched templates become design platforms. Video? That's being transformed too. Every generation of technology moves us one step further away from machinery and one step closer to intent. Machine code became programming languages. Programming languages became frameworks. Frameworks became drag-and-drop builders. Now we're beginning to describe the destination instead of every step of the journey. We are rapidly approaching a world of near-instant, disposable applications built for the purpose of the moment, with the distance between inspiration and result rapidly decreasing. And it has all happened rather faster than anyone expected. That's exactly what happened with Yaffle. I didn't sit down and ask AI to build me a wake word. Instead, I found myself acting as project manager and lead architect for a team that didn't really exist. I'd explain the problem, we'd discuss approaches, I'd test the result, discover what I'd broken, feed that back, and we'd try again. Somewhere along the way there were Python scripts, TensorFlow models, ESPHome firmware and more terminal windows than I'd care to admit. But that wasn't the conversation I was having. The conversation was always about the problem. How do I teach Yaffle to recognize its own name? It let me have a conversation at the level of the problem I was trying to solve, translating that intent into code behind the scenes. For the price of a monthly AI subscription, I suddenly had what felt like an impossibly talented senior programmer sitting beside me. Not someone who always got things right, but someone who could explain unfamiliar concepts, suggest approaches, write code, review mistakes and patiently iterate until we reached something that worked. Yeah, patiently. It never rolled its eyes once. Looking back, this journey didn't really begin with Yaffle. One small Home Assistant tweak led to another until I somehow found myself in VSCodium, the open-source version of Microsoft's code editor, where I discovered what AI-assisted development was really capable of. Very quickly, I was building things that once would have seemed absurdly beyond me. If you're wondering where all this starts, it isn't as intimidating as you might think. Modern editors such as VSCodium can host AI assistants. The workflow is simple: describe the problem, let the AI suggest a solution, test it, refine it, rinse and repeat until ... Ta-da! None of those projects started with the ambition of becoming a programmer. They started because I had a problem worth solving. Perhaps that's why "vibe coding" feels so unsettling. As a Brit, I am predictably hopeless at languages. Writing software always meant learning the computer's language. Increasingly, AI allows me to just use my own. That doesn't make experienced programmers obsolete any more than Cubase eliminated musicians or Photoshop replaced photographers. If anything, it moves expertise up the value chain. The professionals still know what good looks like, still understand the trade-offs, and still recognize when the AI has produced garbage. Even Linus Torvalds, creator and lead maintainer of Linux, weighed into the argument this week. AI, he said, is "clearly a useful" tool; the challenge is making sure it helps maintainers rather than simply creating more work for them. Coming from someone responsible for one of the most consequential software projects on Earth, that feels like a fairly pragmatic assessment, not just hype. Personally, I'm still confident I can tell the difference between a skilled musician, someone who simply knows Cubase inside out, and an AI-generated track, but the barrier to entry has undeniably shifted. I never woke up one morning thinking, "I'd like to become a software developer." I just wanted a better wake word than "OK Nabu." Before that I wanted a better Home Assistant dashboard. Before that I wanted a smarter lighting automation. Before that I wanted ... Every project simply led to the next one because the next problem suddenly looked solvable. That's the remarkable thing about vibe coding. It isn't that AI writes software. It's that, for the first time, millions of people can create software without first spending years learning the language of the machine. Perhaps that's why it feels like cheating. AI didn't make me think like a programmer. It just lets me think like myself. Or perhaps, like every great leap in abstraction before it, it's simply another moment where technology changes who gets to create.

Why vibe coding is creating a hidden web deployment crisis

Experienced coders and people who have never done so much as a "Hello World" exercise are all having a blast with vibe coding. That's the practice of telling an AI model in plain English what software you want to make and then watching it rattle off lines of code faster than you can read them. The results can have very mixed quality, and if you don't have the expertise to review that code for problems, you run the real risk of putting together something that's just plain bad at best and actively dangerous at worst. Regardless, people are creating software with AI, and many of them want to put those apps out on the internet, which is where they run into problems. AI made building apps easy, but deployment became the new bottleneck A shift in the skills gap Vibe coding for more than just your personal enjoyment has shifted the friction up the chain. Now you might have a working AI-coded app, but no idea how to deploy it to a server so that you or other people can access it remotely. Developers and non-developers alike are building websites, utilities, dashboards, and even SaaS products without writing every line themselves. Thanks to tools like Claude Code, ChatGPT, Cursor, and a ton more, that is now the easy part. To make that vibe-coded app accessible, you need knowledge and skills. You need to know how to configure a web server, set up its security, register and connect a domain, and handle a long list of other small and annoying tasks. So now you have a situation where more people are writing software, but don't have the necessary knowledge or skills to deploy it to a hosting platform. That creates a market opportunity, and boy are some companies stepping up while rubbing their hands together. Hosting providers are reinventing themselves for the AI era They'll put your vibe code where everyone can experience it The most in-your-face example comes from a company called VibeHost. Close As you can tell from the gallery above, the pitch here is that whatever your coding agent makes, VibeHost will deploy it for you, usually in seconds. There's a "Free Forever" tier here with 5GB of storage and room for 100 static applications, which I'm sure will get a lot of tinkerers excited about the possibilities, but, of course, the hard sell is for that $20 a month subscription with the promise that you can just let the service deploy as many apps as your coding AI can grind out. As you might expect, established deployment platforms seem to be getting on this train too. Vercel, for example, invites us to "Deploy AI at the speed of frontend," and wants you to use its "end-to-end platform" to build your apps with AI and deploy them right there. These services even acknowledge the dangers of vibe code, with Vercel offering a sandbox that lets you run "untrusted code" to see what it does before you unleash it on the world at large. Traditional self-hosting could become the enthusiast option The stick shift gearheads of hosting None of this means that the current way of self-hosting is going away. Believe me, I can see how enthusiastic our readership is about homelabbing and half the fun is in the building and configuration, not just using the things you've deployed. It's going to stay the way it is for people who want to know how Docker works, or want to maintain that Linux server, or deal with domains, and ports, and certificates. But obviously, some homelabbers and other self-hosting hobbyists are embracing AI to differing degrees. The moderators of Reddit's r/selfhosted introduced a recurring "Vibe Code Friday" thread after AI-generated self-hosted projects became common enough to overwhelm regular discussions. So clearly there's room at the table for this way of doing things. Vibe-hosting removes deployment headaches -- but not security risks It's good that people are finding more ways to get their software out there, and it's probably good that more people are creating software using these new tools. But, just because it's easy to vibe-code an app, and now just as easy to vibe-host it, doesn't mean it's actually production ready. As always, the key issue here is quality control, and there will never be a scenario where one AI model QA's the work of another, and then yet another QA's that, and so on. At some point, a knowledgeable human who is qualified to perform quality control on software has to actually look at the code, and that has to happen long before it's deployed. Turning software development and deployment into a process with such a low bar is almost certainly going to expose us to websites filled with vulnerable products that don't actually work the way they're supposed to, but no one who really knows what they're doing ever checked to make sure it was all above-board. That's not a prospect I look forward to.

Are we vibe coding our way to a new legacy crisis?

When Anthropic's CFO revealed that over 90 per cent of the company's code is now written by its own AI, it landed as a milestone. Tasks that once consumed hours now take 30 minutes. The productivity gains are significant. But Anthropic is an AI-native company with some of the world's best engineering talent. For most enterprises, the question isn't whether AI can generate code at that speed. It's whether they can govern what it generates. Shadow AI: The new shadow IT "Vibe coding", the term for generating code via AI, has moved into the mainstream. By some estimates, almost half of all new global code is now AI-generated. Developer productivity is up. So is debt that nobody fully understands. Part of what's driving this is necessity. AI is helping close the engineering talent gap. Teams that lack experienced developers are using it to build at the pace the business demands. The problem is that the same shortage that makes AI indispensable also means there aren't enough senior engineers to review AI-generated code. Research across Fortune 50 enterprises found that AI-assisted developers introduce security vulnerabilities at ten times the rate of their peers. Forty-five per cent of AI-generated code contains OWASP Top 10 vulnerabilities. Independent analyses indicate that technical debt increases by 30-41 per cent following the adoption of AI tools. Traditional technical debt is at least visible. Engineers who cut corners know they did it. Vibe coding debt is different: developers often don't realize they have incurred it, because the code looks correct - right up until it doesn't. We used to worry about Shadow IT. The new threat is Shadow AI: code generated at pace without architectural review, security auditing or institutional understanding of what's been built. Unlike Shadow IT, which was typically contained within a department, Shadow AI compounds across organizational boundaries. In enterprises where systems are still deeply siloed, complex problems span multiple departments and platforms; no single team has a complete picture of what's been generated or what it depends on. Enterprises have spent decades paying for yesterday's shortcuts. AI risks creating the next generation of legacy systems, only much faster. Repeating the COBOL mistake The market is flooded with tools promising to read millions of lines of COBOL or Java and convert the functionality into a modern language. This is technically impressive, but strategically flawed. Legacy systems are full of inefficiencies, redundancies and "swivel chair" workarounds baked in years ago to compensate for other systems' limitations. Translating code line-by-line replicates that bad logic in a newer language, now running on cloud infrastructure with a modern interface on top of old code and dated processes. To get modernization right, organizations should avoid treating it as a technical exercise. Instead, they should step back and ask whether a process is still valid, not just how to replicate it. True modernization is about reinventing how work gets done, designed around the employee and customer experience rather than the constraints of systems built decades ago. It is a state of consistent change, and it must be driven by the North Star of clear business objectives. The agility layer Probabilistic AI needs to operate within deterministic boundaries to be safe and useful at enterprise scale. AI that can generate anything is not the same as AI that generates the right thing reliably with full traceability, in a context where every decision might be scrutinized by a regulator. This is why high-stakes organizations are looking for an agility layer: a governed process platform that imposes structure, ensures auditability and keeps AI outputs within maintainable boundaries. The US Army followed this approach for security with agility to operate with certainty at speed. Ordering ammunition in disconnected field conditions is mission-critical, with zero tolerance for ungoverned outputs. Similarly, pharmaceutical giant Merck's clinical supply chain, where regulatory scrutiny is intense and errors have patient safety consequences, required a platform that could accelerate delivery without sacrificing auditability. These are examples of organizations trying to address the hardest part of modernization: discovery. They are using AI to extract specifications from even the most poorly documented legacy applications, converting them into visual plans covering UI, data models and process flows. They're generating software components rather than custom code to reuse in other applications, accelerating development time and reducing technical debt. AI agents then build against those specs under human supervision, with developers assigning tasks and iterating throughout - at roughly 25 per cent of the time traditional approaches require. The future is bespoke, not general-purpose There is a temptation to conclude that general-purpose AI will soon render enterprise platforms obsolete. This is premature and in regulated environments, dangerous. General-purpose models are extraordinary at generating plausible outputs. They are not equipped to ensure those outputs are auditable, compliant or maintainable by teams that did not generate them. The vibe coding wave is real, and so is the debt it is creating. The organizations that navigate the next decade successfully and avoid falling into the same old legacy traps will not be the ones that generated code the fastest in 2025 and 2026. They'll be the ones to build governance and process boundaries into how AI was used from the start - so what was built quickly can still be understood, maintained and trusted years later. We've reviewed, rated, and ranked the best laptops for programming. This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit