Imagine firing up your laptop, describing an app idea to an AI, and watching it spit out code while you sit back sipping coffee. No detailed plan, no rigorous architecture upfront – just you and the AI vibing your way to a working program. That, in a nutshell, is “vibe coding.” It’s a buzzword born from the rise of AI coding tools, describing a wing-it approach to programming where you rely heavily on AI helpers like ChatGPT, Cursor, or GitHub Copilot instead of a structured game plan. It’s as if coding has turned into an improvisational jam session with an AI as your bandmate. Sounds fun and fast, right? It can be – but it can also go off the rails if you’re not careful.

In this article, we’ll break down what vibe coding really means, how it came about in the age of advanced AI assistants, and why going full-on vibe mode has some serious pitfalls (think: spaghetti code, duplicate functions everywhere, and zero architecture). More importantly, we’ll explore how to find a happy middle ground – “semi-vibe coding” – where you still harness AI for speed and inspiration, but with enough planning and oversight to keep your project from collapsing under its own weight. We’ll also debunk the myth that AI has made human coders obsolete (psst… it hasn’t), even if some excited CEOs (cough you-know-who cough) are pushing devs to use AI 24/7 without grasping its limits.

Whether you’re a junior developer eager to use the latest AI tools, or a C-suite exec wondering if your dev team should “just use ChatGPT for that,” stick around. We’re going to talk about the good, the bad, and the responsible way forward with vibe coding – all in a friendly, no-nonsense tone from someone who’s been around the code editor a few times. Let’s dive in!

What Is “Vibe Coding,” Anyway?

An example of vibe coding: asking an AI (ChatGPT in this case) for a code solution in plain English. The AI generates a JavaScript function on the fly based on the prompt, shifting the human role from writing code to just describing what’s needed and reviewing the output.

“Vibe coding” (sometimes written as vibecoding) is basically coding by free association with an AI. Instead of carefully designing a system and writing the code yourself, you describe what you want in a few sentences, hit enter, and let a large language model (LLM) do the heavy lifting. The AI generates the code for you, and your job shifts from typing out every semicolon to guiding, testing, and tweaking what the AI produces. In other words, you provide the vibe (the idea or intent), and the AI writes the actual code. Advocates claim this lets even amateurs produce working software without deep programming expertise.

Sounds almost like magic, right? Well, it kind of is – the magic of massive AI models trained on tons of code. If you’ve ever used GitHub Copilot or ChatGPT’s coding capabilities, you’ve had a taste of it. You might say something like, “Hey AI, create a simple web form that collects emails and stores them in a database,” and the AI will try to generate the HTML, CSS, Python/JS code, or whatever is needed. No strict plan, no careful crafting – just “I have a need, let’s see what the AI gives me.” One Reddit user described the true vibe coder’s ethos as not even looking at the code or understanding it – just trusting the AI to do its thing, and only interacting with the end result (asking for changes or fixes if something breaks). It’s the ultimate “black box” approach: treat the AI like an all-knowing code genie.

The term vibe coding itself is new – it was popularised around early 2025 (AI luminary Andrej Karpathy jokingly introduced it) – but the practice started emerging as AI coding tools took off. 

Karpathy summed up his experience with vibe coding as: “It’s not really coding – I just see things, say things, run things, and copy-paste things, and it mostly works.”

In other words, he would describe what he wanted, let the AI write it, run the code, and if it failed, he’d try random tweaks or ask the AI to fix it until it worked. This was “quite amusing” for toy projects, he noted, though he acknowledged the approach has real limitations (the AI often can’t fully understand or fix complex bugs, so he’d resort to odd workarounds) 

So vibe coding = coding without a strong plan, driven by AI outputs and a bit of hope. Instead of meticulously designing and coding, you’re jamming with the AI. It’s a bit like telling a junior developer to build something and hoping for the best – except this junior dev has read all of StackOverflow and might churn out a decent app by cobbling together what “feels” right from its training data.

How AI Tools Made “Coding by Vibe” Possible

Why are people vibe coding now? Thank the AI boom. A few years ago, if you didn’t know how to code and just tried to “vibe” your way through a project, you’d be lost. But with modern AI assistants, everyone from seasoned engineers to complete non-coders suddenly got a turbocharged helper that can translate plain English into code.

It kicked off with tools like OpenAI’s ChatGPT and GitHub Copilot in late 2021–2022. Copilot, for example, was like an autocomplete on steroids integrated into VS Code – you write a comment or a function signature, and it suggests whole chunks of code. ChatGPT took it further: you could literally chat, saying “I need a Python script that does X,” and it would output a script. By mid-2023, these tools were mainstream, and more kept coming.

Cursor, one of the so-called “AI code editors,” is a great example. It’s an IDE built around AI assistance – valued at a whopping $10 billion – designed so you can “vibe code your app without programming knowledge.”  In Cursor, you don’t have to remember syntax or sift through documentation; you describe what you want, and it helps generate or modify your code accordingly, all within the editor. Even Google jumped on the trend with things like Firebase Studio (an AI builder that lets you create full-stack apps via prompts, clearly targeting the vibe coding use-case). In short, the tech industry saw how many people were using AI to code and started building tools explicitly to make “describe it, get code” the new normal.

So by 2023-2024, we had this perfect mix: AI models (like GPT-4 and others) that are extremely good at coding tasks, plus editor integrations and UIs that made it seamless to use them. Coding became more conversational. Instead of writing 100 lines of boilerplate yourself, you could say “Create a user login form with Flask”, and poof – the code appears. Instead of digging through StackOverflow for how to shuffle a deck of cards in JavaScript, you just ask the AI and it writes the function for you (see the image above for exactly that scenario!).

This opened the door for non-developers or beginner devs to attempt projects by leaning heavily on AI. Essentially, AI became the co-pilot (or maybe the pilot), and the human became the idea person and tester. That’s vibe coding in practice. It was only natural that many folks, excited by this capability, started skipping the boring parts of planning and coding and went straight to “let’s see if the AI can build this for me.”

Even experienced devs felt the pull – after all, if you can prototype a concept in an afternoon by just chatting with your AI assistant, why not? Hackathon projects, throwaway scripts, personal tools – perfect use cases for vibing out some quick code. One developer wrote about how he “vibe-coded” a micro app in 10 minutes using ChatGPT to automate a tedious PDF-to-Markdown conversion task, noting that this collaborative AI approach saved him hours of manual work. He still had to guide the AI with specifics and do a bit of tweaking, but the bulk of the code came from the AI in minutes. Stories like that spread fast!

It’s worth noting that even as vibe coding caught on, many realised it’s best for certain scenarios. Quick prototypes, one-off scripts, learning exercises, or solving well-defined tasks are the sweet spot. Our PDF-to-Markdown friend pointed out that small one-function apps or simple prototypes are the best fit for vibe coding at the moment, even though some ambitious folks are trying to build full-blown platforms this way. Likewise, tech commentators have observed that vibe coding lets a single person do what might’ve required a whole team before, but with limitations – the results often still have issues and don’t replace careful engineering for serious projects. (More on those issues in a moment.)

Bottom line: AI tools made vibe coding possible by lowering the barrier to getting functioning code. If you have an idea and some patience, you can literally talk your way into a codebase. The appeal is obvious – it’s fast, it’s accessible, and it feels like the future. But if you jump in without knowing the downsides, you might end up with an AI-generated house of cards. Let’s talk about the dangers of pure vibe coding (so you don’t learn the hard way).

The Dangers of Pure “Vibe Coding”

Like a lot of shiny new tech approaches, vibe coding comes with fine print. If you go all-in on coding by vibes – meaning you have little to no plan, you’re blindly accepting whatever the AI throws at you, and you’re not really digging into the code – you can run into some serious problems. Think of it as the hangover after the AI party. Here are the big ones to watch out for:

⚠️ Redundant and Repetitive Code Everywhere

AI coding assistants are great at producing code, sometimes too great. If you prompt them in isolation, they might unknowingly create duplicate functions or logic in multiple places. For example, you might ask the AI to generate code for validating user input in two different parts of your app at different times – if you’re not careful, you could end up with two slightly different validateInput()functions in two files. The AI isn’t inherently tracking a single design across your whole project; it responds to each prompt, often by generating new code from scratch. This means it can violate the programmer’s beloved DRY (Don’t Repeat Yourself) principle. In fact, industry research has noticed that code written with AI assistance tends to have more copy-pasted and repeated code, and less refactoring, than code written the old-fashioned way. One report found that since the rise of AI coding, there’s been a significant uptick in duplicated code and a drop in code reuse, indicating that AI users often solve a problem by just adding new code rather than integrating with existing code. All that redundancy can make a codebase bloated and hard to maintain. Imagine having to fix a bug and realising it’s been copy-pasted in five different files – yikes! That’s a real risk when you vibe code without oversight (the AI isn’t going to politely tell you “um, I already wrote a function for these two prompts ago”).

⚠️ Lack of Architecture or Coherent Design

Vibe coding usually means no strong plan upfront. You’re building feature by feature, prompt by prompt, following the “vibe” of what you need in the moment. The result? You might end up with a Frankenstein architecture – pieces bolted together in odd ways, no consistent structure, and lots of technical debt hiding in the shadows. AI isn’t a software architect. If you don’t guide the high-level structure, it will just give you whatever meets the immediate request. That could mean all your business logic ends up crammed into one giant file because you never asked to split it out. Or maybe the AI created a few classes and functions that kind of overlap in purpose because you prompted for similar things at different times. The code might work, but it could be one hot mess under the hood. Developers have observed that when you let AI output code without a guiding architecture, it’s like having a bunch of disjointed contractors work on a project – you get inconsistent patterns and a lot of duct tape solutions. In one experiment, a team tried a “zero human code” approach (letting AI build and even self-fix an app), and they discovered that early design decisions became “nearly immutable” because the AI struggled to refactor or change course once the code got complex  The AI would actually introduce new bugs or bizarre workarounds when asked to restructure things, to the point that large-scale changes became dangerous. The lesson: if you don’t plan a sensible architecture from the start, the AI isn’t going to magically impose one, and trying to fix the structure after the fact is extremely painful. You can end up stuck with whatever sloppy structure “felt right” to the AI in the moment, which might be very far from best practices. This lack of a solid foundation can haunt you as the project grows.

⚠️ Inefficient or Low-Quality Code

AI-generated code is a mixed bag. Sometimes it’s brilliant; other times, it’s… suboptimal. If you’re vibe coding and not paying attention, you might be shipping code that works but is far from optimal. Perhaps the AI uses a less efficient algorithm because it’s the first thing that came to mind (it might not automatically think to optimise unless you prompt it to). Or it might do something in 10 steps that could be done in 3, simply because it’s imitating an average example from its training data. I’ve seen AI code that, for example, queries a database in a loop (slow!) instead of doing one set-based query, simply because the prompt didn’t specify the efficient approach. If you, as the developer, aren’t watching out for performance or complexity, the AI likely isn’t either. Another issue is bloat – AI might generate a lot of boilerplate or overly generic code that you don’t actually need. Sure, it runs, but you’ve got more lines of code to maintain and potential new points of failure. Studies have noted that AI assistance can increase the amount of code written (one GitHub study said developers produce up to 55% more code with Copilot), which is cool for productivity, but more code without a purpose is just more room for bugs. And speaking of bugs…

⚠️ Hidden Bugs and Lack of Understanding

Perhaps the biggest danger of pure vibe coding is the human not understanding the code. If you just trust the AI and never delve into the logic, you’re essentially flying blind. AI can and does make mistakes in code – sometimes subtle ones. It might off-by-one error in your loops, use an outdated API, or mis-handle an edge case. If neither you nor any colleague catches it, those bugs go live. And when something breaks, you might be at a total loss because you didn’t actually write (or even read) the code that’s failing. This is compounded by the fact that AI can hallucinate – produce outputs that look legit but are actually nonsense. For example, a New York Times tech columnist tried vibe coding some small apps and noted that while it was powerful, the AI would occasionally fabricate things that weren’t true. In one case, it even invented fake data (fake reviews on an e-commerce site) as part of the output  If you’re blindly copy-pasting, you might miss such inaccuracies or shady behaviour. Security is a big concern here too: AI might not include proper security checks (say, sanitising user input or using secure defaults) unless you explicitly ask. You could end up with serious vulnerabilities in your application and have no clue. There’s evidence that teams using AI assistants have seen more security incidents because of this – one survey found 68% of developers spent more time resolving AI-introduced security vulnerabilities once they started using AI coding tools. The AI isn’t malicious, it’s just not omniscient; it might leave the barn door open without telling you. And if you don’t understand the code, you won’t catch it until something goes very wrong.

⚠️ Technical Debt and Maintenance Headaches

All of the above issues contribute to what we call technical debt – the cost of all the quick-and-dirty choices you (or the AI) made that you’ll have to pay for later. Pure vibe coding can generate a codebase that works today but is a nightmare to maintain tomorrow. Redundant code means more places to fix a bug. Poor structure means it’s hard to extend or modify features. Inefficiencies can mean costly refactors down the line. And not understanding the code means each future change requires a bunch of reverse-engineering. Developers are already reporting that uninhibited use of AI is compounding technical debt in projects  It’s telling that while managers are excited about AI, many engineers have grown wary – they’ve been burned by code that was supposedly finished in record time, only to spend the next week cleaning up edge cases and errors that the AI introduced .If you’ve ever joined a project with a messy codebase (who hasn’t?), imagine that, but with the added twist that the code was written by an AI that isn’t around to explain why it did what it did. As one Reddit commenter bluntly put it, “This vibe coding concept is a scissor in a child's hand. But a scissor is a good tool in the right hands.”  Without proper care, vibe coding can cut you.

Given these dangers, it’s no surprise that seasoned devs raise eyebrows at pure vibe coding, especially for production software. It might be fine for a quick prototype or a throwaway hackathon app (even Karpathy said vibe coding was “not too bad for throwaway weekend projects” ), but if you’re building something that needs to be maintained, scaled, and trusted, going full vibe is asking for trouble. In a professional setting – say a team of engineers collaborating on a codebase – pure vibe coding is “not sustainable” at all. One experienced user noted that true vibe coding (where you don’t read or understand the AI code) just doesn’t fly if you plan to be part of a real engineering team or work on a large codebase; it might be okay for quick solo prototypes, but not for serious development.

So, should we abandon AI-assisted coding? 

No way! 

The key is to use these AI tools wisely, without falling into the trap of blind vibe coding. That’s where the concept of “semi-vibe coding” comes in – a middle path that gives you the best of both worlds.

Semi-Vibe Coding: Using AI as Your Co-Pilot (Not Auto-Pilot)

After the cautionary tales above, you might be thinking, “Alright, I won’t just vibe out and let the AI do everything. But what should I do instead?” The answer: combine your human skills (planning, reasoning, understanding) with the AI’s superpowers (speed, knowledge, consistency). This is what we’ll call semi-vibe coding – you’re still coding with the AI and maybe even “vibing” in the sense of a smooth, interactive flow, but you remain firmly in control of the steering wheel.

Think of it like this: if pure vibe coding is letting the AI drive your car while you nap, semi-vibe coding is using cruise control – you’re letting the AI handle some tasks, but you’re alert, watching the road, and steering as needed. Here are some strategies and best practices for semi-vibing responsibly:

📝 Start with a Plan (Even a Loose One)

Before you type a single prompt, sketch out what you want to build. This doesn’t have to be a 50-page spec; it can be a simple outline or a few sentences on what the key components are. Identify the major pieces of the project: for example, “We’ll need a database model, an API endpoint, and a frontend page. We should have a separate module for utilities, and we’ll use framework X for the backend.” Jot down or mentally note these. This guiding vision will help you prompt the AI in a structured way (“Next, I need a function in the utils module to do Y…”) rather than random scattershot requests. As one experienced non-coder put it, “Vibe coding or not, it’s all about setting the foundations. You wouldn’t task your dev team with ‘Nothing works, please fix this, ’ and you should not approach AI with that either.”  In other words, give the AI specific tasks in a sensible order – don’t just say “build my app” with no further direction. Planning what you want to build (even at a high level) will save you from AI tangents and rework later.

🔎 Do AI-Assisted Research and Design

Coding isn’t the only thing AI is good at. You can use tools like ChatGPT or Perplexity to research best practices, architectures, and unknowns before you generate large chunks of code. For instance, ask the AI: “What’s a good library for handling user auth in Node.js?” or “What are common architectures for a real-time chat app?” or “Can you outline a basic design for an inventory management system in Django?” These questions leverage the AI’s vast training knowledge to give you pointers and options. Essentially, use the AI like a consultant or a rubber duck at the design phase. This can alert you to things you hadn’t considered (security implications, scaling suggestions, etc.) and inform how you structure your code. Some vibe coders take this further – they have the AI draft product requirement docs or implementation plans, which they then feed back into their coding session. You don’t necessarily have to go that far, but definitely ask the AI about what you don’t know. Treat it like an encyclopedia and mentor, not just a code generator. This step helps ensure that when you do start coding, you’re following recognised good practices instead of accidentally making a well-known mistake (which the AI might happily do if you never asked).

💻 Use AI Coding Tools Interactively (Keep Yourself in the Loop)

When you move to implementation and start generating code with an AI (be it in Cursor, VS Code with Copilot, or plain ChatGPT), stay engaged. Don’t just accept the first thing it gives you if you don’t understand it. Read the code it produces. Step through it logically. If something is unclear, ask questions. A great habit is to tell the AI to explain the code back to you or to add comments. For example, you can prompt, “Can you add comments to this function explaining what each part does?” This way, the AI itself will document the logic for you, and you can quickly catch if something doesn’t make sense. (Yes, you can literally have it write docstrings and inline comments – it’s an excellent way to improve clarity.) By constantly reviewing what the AI outputs, you transform the process from blind vibe coding into a kind of AI pair-programming session. Remember the wise words of AI researcher Simon Willison: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding... that’s using an LLM as a typing assistant.” That’s exactly the goal – use the AI as your assistant, not a mysterious code oracle. So after each code generation, be the reviewer. Run the code if possible to test it quickly. This active involvement will nip a lot of issues in the bud. You’ll catch that the AI made a function static when it shouldn’t have, or that it didn’t handle an error case, and you can immediately prompt it to fix or refine that.

📂 Be Explicit About Structure and File Placement

One pro tip while coding with AI is to tell it exactly where to put things. Don’t let it decide your file structure (it might make weird choices or keep everything in one file). For example, if you want a helper function to live in a utils.py module, include that in your prompt: “Create a function format_currency in utils.py that takes a number and returns a formatted string.” This not only gives you control of the organisation but also signals to the AI the context (if it knows about your project files, it will put the code there appropriately). Modern AI IDEs like Cursor often allow drag-and-drop of files or have a sidebar with your project tree – use that to your advantage. If the AI creates a new file when you didn’t want one, you can move the code, or better yet, instruct it: “Integrate the above code into main.js instead of a new file.” Being deliberate about architecture (e.g., separating frontend and backend logic, or keeping database models in one place) as you go prevents the “jumble” effect. Essentially, you impose the architecture, and the AI fills in the code. This avoids a lot of the duplicate code problems, too – if you know you want one central function for something, you won’t accidentally prompt the AI to make multiple versions in different places. Another benefit: when you’re clear about where code should live, the AI’s answers tend to be more focused and relevant to that context. You’re giving it constraints that lead to a cleaner outcome.

🔄 Iterate with Small, Focused Prompts

It’s tempting in vibe coding to ask for a whole subsystem at once (“Generate the entire user authentication module”). But you’ll have better results – and more control – if you break tasks down. For instance, first ask for a User model class. Then ask for a registration function. Then a login function. Step by step. After each step, check the work (does the User model have the fields you want? Does the login function properly validate passwords?). By iterating like this, you reduce the chance of the AI going off on a tangent, and you can course-correct as you build. If something isn’t right, you can pinpoint it: “The login function you gave me doesn’t lock out after 3 failures; please add that.” This is much easier than generating a monolith and trying to unravel it. It’s the same principle as good software development: iterative, incremental improvements. Plus, smaller prompts mean the AI has the relevant context fresh in the conversation, which can improve accuracy. Many AI coding veterans treat the process like an interactive dialogue: build -> review -> refine -> repeat. This keeps the vibe (collaborative and fast) without losing the quality (because you’re validating at each step).

🗂 Document and Comment as You Go (with AI’s help)

We touched on this with asking for comments, but it deserves its own emphasis: make documentation a first-class citizen in semi-vibe coding. When you prompt the AI, you can often ask it to include docstrings, usage examples, or even markdown docs. For example: “Generate a Java method to parse XML and include a JavaDoc comment with an example.” This way, you’re not only getting code, but also an explanation alongside it. It forces both you and the AI to clarify the intent of the code. Additionally, maintain a README or design notes where you jot down decisions. Some advanced users even feed this back into the AI (one Reddit user mentioned keeping a markdown knowledge base of project info that they symlink into the project so the AI can refer to it ). That might be overkill for many, but the point is: keep track of what’s happening. If you have to stop the AI session and come back a week later, those comments and docs will save you from having to re-read all the code to figure out what it does. Think of it as leaving breadcrumbs for your future self (and for teammates). And yes, you can absolutely tell the AI something like, “Add logging to this function” or “Write a one-paragraph summary of how this module works and put it at the top of the file.” These things greatly improve clarity, and the AI is usually quite capable of generating them if asked.

✔️ Test and Verify at Each Milestone

Semi-vibe coding doesn’t mean you trust blindly – you verify often. After writing a chunk of code with the AI, run it (if possible) with some tests or sample input. If you’re building a web app, fire it up locally and click through the feature you just built. If it’s a library, write a quick snippet to call the functions. This will catch obvious errors immediately. Crucially, if you find a bug or the output isn’t what you expect, use that as feedback to the AI. For instance: “I ran the function and got an error about a null pointer – can you help fix that?” or “It works, but it’s running really slow with 1000 entries; any idea how to optimise?” Now you’re using the AI not just as a coder, but as a debugging assistant. Many AI coding tools shine in this role – they can take an error message and suggest a fix. By testing as you go, you prevent a pile-up of bugs later (the “oh no, nothing works and I have no clue why” scenario). It also reinforces your understanding. If the AI’s explanation of a piece didn’t match reality, you’ll catch it and correct it, building trust in the codebase you’re creating.

By following the above practices, you’re essentially still “vibing” – there’s a natural, fast flow with the AI – but you’re not flying blind. As one Reddit commenter noted when praising a successful AI coding approach: “You’re having success because you’re not vibe coding (i.e. blindly accepting the code); you’re actually taking it a level above and using some practical steps to document and check what the LLM is outputting.”  Exactly! Semi-vibe coding means you use the AI, but you also use your brain at each step. The end result is code that you (and your team) can understand, maintain, and trust more than if you had let the AI just roam free.

And here’s the kicker: semi-vibe coding can be almost as fast as pure vibe coding, because a lot of these best practices can be rolled right into your prompts and workflow. You’re basically pair-programming with the AI. Yes, you take a bit of time to plan and review, but you save time not having to do massive clean-ups later. It’s a net win for productivity and code quality.

Now, with this balanced approach in mind, let’s address a big elephant in the room – a concern both newbies and execs often have: is AI going to replace the need for human programmers? And corollary: should we force all programmers to use AI for everything because it’s obviously the Future™? Spoiler: It’s not that simple.

No, AI Hasn’t Made Human Coders Obsolete (Myth vs. Reality)

Given how powerful these AI tools are, it’s fair to ask: “If AI can code, do we really need developers anymore? Can’t we just have people vibe code and eliminate all that expensive engineering work?” This line of thinking has definitely crossed the minds of some executives (and plenty of clickbait articles). You might even have heard of companies mandating their devs to use AI for coding or touting that they built something with 90% AI-generated code. Let’s clear the air on this, with a friendly cough in the direction of overly optimistic CEOs: AI is a tool, not a replacement for programming expertise.

First off, coding is more than just writing syntax – it’s deeply tied to understanding problems, making design decisions, and continually adapting to new requirements. AI, for all its capabilities, doesn’t truly understand the project’s goals or the users’ needs. It doesn’t take responsibility for the choices made. As we saw, if you naively trust AI to do it all, you often end up with more work in debugging and maintenance. In fact, many developers report that using AI can be a double-edged sword. It might speed up initial coding, but then they spend additional time verifying and fixing things. A recent survey of 500 engineers found that 67% of them spent more time debugging AI-generated code than code they wrote themselves. Think about that – if the AI writes 1000 lines for you in a day, but you then have to comb through those 1000 lines to troubleshoot, you haven’t actually saved time overall. Another finding was that a majority of teams had issues when deploying AI-written code, and 68% said they’re now spending more time resolving security vulnerabilities introduced by AI. So, far from replacing developers, AI has in some cases created new work for developers (like cleaning up the AI’s mistakes).

Now, this isn’t to say AI provides no productivity boost. Used well, it definitely can (and does). But the key is “used well” – which usually means human developers overseeing and integrating the AI output. GitHub’s CEO made a bold prediction that in the near future, AI might write 80% of our code. Even if that comes true, who’s handling the crucial 20% of code that is uniquely complex, or the integration of all that code, or verifying that 80% for correctness and performance? Yup, humans. In practice, what we see is AI taking over a lot of the boilerplate and rote coding tasks – the tedious stuff that doesn’t require deep creativity, which frees developers to focus on the interesting and hard parts. It’s augmenting, not replacing. One AI researcher quipped that AI won’t replace programmers, but programmers who use AI might replace those who don’t. There’s truth there: it’s a skill that can make a dev more effective, but it’s not sending developers to the unemployment line en masse.

That said, some business leaders have gotten a bit too hyped. We’ve heard of execs practically demanding AI be used everywhere to justify cutting headcount. (Some even measure how many lines of AI-generated code are in a project as if that’s a KPI… pro tip: it’s not 😅.) It’s reached a point where surveys show a rift – many C-suite folks think their AI adoption is going great, but a lot of engineers internally are frustrated with how it’s being forced without guidance. The phrase “misguided mandates” has popped up. In one report, nearly half of execs said AI adoption was “tearing the company apart” due to the disconnect between leadership’s expectations and the reality on the ground. Developers worry that errors and tech debt are being introduced by over-reliance on these tools.

To any CEOs or managers reading: mandating AI use without understanding its limitations is a recipe for disaster. Yes, AI can make your team more efficient – 58% of devs in a Stack Overflow survey said it improved their efficiency. But only if used right. If you just tell everyone “use AI for everything and we can ship faster,” you might ship fast… straight into a buggy mess that costs more to fix. Remember, AI has no accountability – your devs do. They’re the ones who will stay late diffing through an AI-generated commit to find why the payment service is crashing. Leaders like to talk about how AI can allow smaller teams, perhaps hiring fewer developers (some high-profile tech CEOs have indeed mused about reducing engineering staff thanks to AI advancements ). That might sound good on an earnings call, but in practice, it could mean the remaining developers are overburdened with interpreting and fixing AI outputs. Morale can dip if devs feel like they’re just babysitting an AI or being asked to rubber-stamp code they know might be problematic.

The myth that “AI coding means we don’t need coders” also ignores all the creative and critical thinking that goes into successful software. AI is pattern-based; it regurgitates and blends what it’s seen. It’s not going to invent a novel algorithm for your very specific problem (unless that algorithm already exists in its training data). It’s not going to strategise how a feature should be broken into microservices based on company-specific constraints. And it certainly won’t talk to stakeholders to figure out what the software should do in the first place. Human developers aren’t going anywhere because someone needs to do the parts that AI can’t – understanding the real-world context, making judgment calls, and ensuring the tech actually aligns with business/user needs.

Let’s bust another mini-myth while we’re here: some worry that if they lean on AI (even in the semi-vibe way we discussed), they aren’t “real programmers” or they’re not learning. Not true! You still have to know what’s going on. In fact, using AI can accelerate learning if you engage with it – it’s like having an infinite patience tutor who can answer “why did you do that?” for every line of code. If you’re a beginner, don’t be ashamed of using AI help, just make sure you study the AI’s output. Think of it as reading a lot of example code very quickly. Over time, you’ll start spotting when the AI’s suggestion is good or bad, which means you’re building intuition. And please, still learn the fundamentals! AI might handle syntax, but you need to know concepts (like what a web server does, or why we index databases) to effectively tell the AI what to do and to catch its mistakes.

To sum up the myth-busting: AI hasn’t made coding obsolete – it’s changed how we code. The role of a developer is shifting more towards architecting, reviewing, and integrating, with less mindless typing. We’re kind of levelling up into a conductor role, orchestrating AI-generated pieces. Some forward-thinking companies embrace this: they encourage devs to use AI where it helps, but also invest in training them to do code reviews and maintain quality on AI contributions. The result can indeed be faster development cycles without (too much) loss of quality. Those companies that just yell “AI everything now!” and cut corners? They’ll likely face a reckoning when the bugs, security breaches, and unhappy developers start to pile up.

As for that future where AI can build entire large systems flawlessly at the click of a button – it’s not here yet. We might get there (never say never in tech), but as of 2025, even the best models have context limits and can hallucinate or make wrong assumptions on big codebases. One expert predicted that truly hands-off vibe coding for big legacy codebases is still a few years away – current models struggle with very large contexts and complex coordination, so we’re “far away from coding assistants that can vibe code huge legacy codebases as part of real enterprise companies”. In the meantime, those of us in the trenches will be doing semi-vibe at best. And if AI does get that good down the road, I suspect the nature of our jobs will shift again (perhaps to more product and system-level thinking). But we’ll cross that bridge when we come to it.

Closing Thoughts: Keep the Vibe, Mind the Code

Vibe coding is an exciting development in our industry. It’s made coding more accessible and, in many cases, more fun – after all, who doesn’t enjoy feeling like Tony Stark talking to JARVIS, building something with just your voice (or keyboard) and some AI magic? We’re living through a time where a single person can accomplish things in software that would have been almost unthinkable a few years ago, thanks to AI helpers. If you’re a beginner, this is an awesome opportunity: you can build real projects while learning, with an AI pair-programmer by your side. If you’re a business leader, it’s an opportunity to boost productivity and tackle backlogs by empowering your team with AI tools.

But – and this is a big but – the core principles of good software engineering still apply. Planning isn’t dead. Code readability and maintainability matter. DRY and good architecture matter. Testing and security matter even more when an AI is churning out code on your behalf. In other words, you can’t just throw out all the rulebooks because “the AI has got it.” As we discussed, going full vibe with no oversight can lead to costly messes. The trick is to find that balance: leverage the AI to do the heavy lifting and repetitive work, while you apply judgment, oversight, and direction.

The concept of vibe coding might have started as a trend or even a joke, but it’s highlighting a real shift in how software gets built. We’re moving towards higher-level abstractions – “code in English” is becoming a thing. It’s an exciting evolution, and those who learn to ride the wave (without wiping out) will do great. Just remember that at the end of the day, building software is a team sport – and now your team includes some AI players. Treat them well, but don’t let them replace the playbook that makes your team successful.

So go forth and vibe… responsibly. Plan a little, vibe a little, review a lot. Use AI to amplify your productivity, not replace your thinking. When you strike that balance – the AI writing lots of code, you guiding and refining it – you often get the best results: fast development and solid code. And honestly, it’s pretty darn cool to see an AI implement your idea in seconds, and know that you had the wisdom to make it all come together correctly.

Happy coding, and may your vibes be good and your bugs be few!

👋 Connect with Me

I’m Javian Ng, an aspiring Full-Stack Infrastructure Architect & LLM Solutions Engineer based in Singapore. I love building scalable infrastructure and AI systems.

• 🌐 Website: www.javianng.com
• 💼 LinkedIn: linkedin.com/in/javianngzh
• 🛠️ GitHub: github.com/javianng

Feel free to reach out or explore more about my projects and experiences.

Sources