I'm All In on AI, But We Need to Talk About Vibe Coding

Table of Contents Introduction AI Is Awesome Failing Code and a Cold Bus And Here Comes the "However" The Name Itself The Actual Vibe Journey is More Important than Destination Let's Go Back in Time Abstraction Over Abstraction? Now, What Happens if You Trust the AI Too Much? Security Risks Unless You're Building a Very Simple App, You'll Eventually Need to Talk to a Real Engineer And Last but Not Least — Sustainability As we Move Towards the End, Let's Switch to a Positive Note Boilerplate Projects / Code Demo Projects Bridging the Gap Between Engineers and Managers Dipping Toes in Creating Products To Sum Everything Up Introduction AI Is Awesome For the record, as I mentioned in the title, I'm huge pro-AI. I think it's the logical next step in the evolution of computer science. We've always aimed to build smarter systems and automate what we can — it's part of our nature. Humans crave convenience, efficiency, and simplicity. The more easily we can create and manage complex systems, the better and there's absolutely nothing wrong with that. Large Language Models (LLMs) have become a cornerstone of this progress. Today, nearly every software engineer relies on them in some way (or at least the vast majority do). I started my professional software engineering journey way back in 2017, when I got hired as a junior software engineer. Back then, the landscape was very different. It wasn't unusual to spend an entire day digging the hell out of the internet for a solution that sometimes was almost impossible to find. If I had access to ChatGPT back then, I could've generated a solution in 10 minutes, analyzed it, and adapted it to my specific use case. Failing Code and a Cold Bus At the time, the best we had was StackOverflow — which, to be honest, often felt like one of the most toxic places on the internet. I remember working on a rarely used platform with terrible documentation and almost no community support. Out of desperation, I decided to post a question on StackOverflow. Do you know what happened? Nothing. No replies, no upvotes, no downvotes — just silence. I posted a few more questions (oh, I even got a badge for this — I kid you not.) and finally someone, for some reason, downvoted my question, causing my account to get locked. Yes, just like that. Locked out, not for spamming or trolling, but for asking legitimate questions that no one knew how to answer (what a great way to start your software engineering career right?). If I had AI tools like we have today, that phase of my career would've been so much less painful. I'd have found those answers without stressing out myself and thinking about my career choices on the way home at 10PM sitting in a cold, empty bus. I'm sharing all this to make one thing clear: I'm a huge supporter of AI, machine learning, deep learning — the entire field. Even my PhD research focused on data mining and AI. I've had professional debates with people who are skeptical about this technology, and honestly, I don't understand the hostility. Why would I reject a tool that helps me work smarter, learn faster, and be more productive? And Here Comes the "However" However, that doesn't mean we should exploit the potential of any tool in the worst ways possible. Just because something is powerful doesn't mean it should be used recklessly. Tools, including AI, are meant to assist us, not replace us. And that distinction matters. Which brings me to my core concern: vibe coding. I have fundamental issues with this trend. It just doesn't sit right with me. In fact, it feels wrong on so many levels that I might not even be able to unpack all of them in a single article. But let's start with the basics — the foundational problems — and work our way toward the more complex ones. The Name Itself Even if the concept behind vibe coding is great, it's still the single worst name for it. I don't think it was thought through enough. Let's break it down by first defining both parts of the whole term: Vibe: the mood of a place, situation, person, etc. and the way that they make you feel (dictionary.cambridge.org) Coding: the composition of sequences of instructions, called programs, that computers can follow to perform tasks. It involves designing and implementing algorithms, step-by-step specifications of procedures, by writing code in one or more programming languages. (wikipedia.org) Now that we've defined both terms, I'm left with two pretty dumb — but honest — questions: Where exactly is vibe in all this? Where exactly is coding in all this? I think it's a complete opposite. The Actual Vibe To me, good vibes in coding come from learning — really learning. They show up when you dive into a new language, experiment with a fresh library, explore a new design pattern or architectural style. You try to understand it, play with it, integrate it into a project — maybe even st

Jun 24, 2025 - 19:30

I'm All In on AI, But We Need to Talk About Vibe Coding

Introduction
- AI Is Awesome
- Failing Code and a Cold Bus
And Here Comes the "However"
- The Name Itself
- The Actual Vibe
- Journey is More Important than Destination
- Let's Go Back in Time
- Abstraction Over Abstraction?
- Now, What Happens if You Trust the AI Too Much?
- Security Risks
- Unless You're Building a Very Simple App, You'll Eventually Need to Talk to a Real Engineer
- And Last but Not Least — Sustainability
As we Move Towards the End, Let's Switch to a Positive Note
- Boilerplate Projects / Code
- Demo Projects
- Bridging the Gap Between Engineers and Managers
- Dipping Toes in Creating Products
- To Sum Everything Up

Introduction

AI Is Awesome

For the record, as I mentioned in the title, I'm huge pro-AI. I think it's the logical next step in the evolution of computer science. We've always aimed to build smarter systems and automate what we can — it's part of our nature. Humans crave convenience, efficiency, and simplicity. The more easily we can create and manage complex systems, the better and there's absolutely nothing wrong with that.

Large Language Models (LLMs) have become a cornerstone of this progress. Today, nearly every software engineer relies on them in some way (or at least the vast majority do). I started my professional software engineering journey way back in 2017, when I got hired as a junior software engineer. Back then, the landscape was very different. It wasn't unusual to spend an entire day digging the hell out of the internet for a solution that sometimes was almost impossible to find. If I had access to ChatGPT back then, I could've generated a solution in 10 minutes, analyzed it, and adapted it to my specific use case.

Failing Code and a Cold Bus

At the time, the best we had was StackOverflow — which, to be honest, often felt like one of the most toxic places on the internet. I remember working on a rarely used platform with terrible documentation and almost no community support. Out of desperation, I decided to post a question on StackOverflow. Do you know what happened? Nothing. No replies, no upvotes, no downvotes — just silence. I posted a few more questions (oh, I even got a badge for this — I kid you not.) and finally someone, for some reason, downvoted my question, causing my account to get locked. Yes, just like that. Locked out, not for spamming or trolling, but for asking legitimate questions that no one knew how to answer (what a great way to start your software engineering career right?). If I had AI tools like we have today, that phase of my career would've been so much less painful. I'd have found those answers without stressing out myself and thinking about my career choices on the way home at 10PM sitting in a cold, empty bus.

I'm sharing all this to make one thing clear: I'm a huge supporter of AI, machine learning, deep learning — the entire field. Even my PhD research focused on data mining and AI. I've had professional debates with people who are skeptical about this technology, and honestly, I don't understand the hostility. Why would I reject a tool that helps me work smarter, learn faster, and be more productive?

And Here Comes the "However"

However, that doesn't mean we should exploit the potential of any tool in the worst ways possible. Just because something is powerful doesn't mean it should be used recklessly. Tools, including AI, are meant to assist us, not replace us. And that distinction matters.

Which brings me to my core concern: vibe coding.

I have fundamental issues with this trend. It just doesn't sit right with me. In fact, it feels wrong on so many levels that I might not even be able to unpack all of them in a single article. But let's start with the basics — the foundational problems — and work our way toward the more complex ones.

The Name Itself

Even if the concept behind vibe coding is great, it's still the single worst name for it. I don't think it was thought through enough. Let's break it down by first defining both parts of the whole term:

Vibe: the mood of a place, situation, person, etc. and the way that they make you feel (dictionary.cambridge.org)

Coding: the composition of sequences of instructions, called programs, that computers can follow to perform tasks. It involves designing and implementing algorithms, step-by-step specifications of procedures, by writing code in one or more programming languages. (wikipedia.org)

Now that we've defined both terms, I'm left with two pretty dumb — but honest — questions:

Where exactly is vibe in all this?
Where exactly is coding in all this?

I think it's a complete opposite.

The Actual Vibe

To me, good vibes in coding come from learning — really learning. They show up when you dive into a new language, experiment with a fresh library, explore a new design pattern or architectural style. You try to understand it, play with it, integrate it into a project — maybe even start something completely new just to see how it works.

Then, inevitably, you fail. You hit walls. Because if you don't you're not really trying hard enough. You spend hours figuring out what went wrong. And in doing so, you learn even more. Eventually, things click. You get it right. You might even share what you've learned with others — and just like that, you've grown. You're a better engineer than you were when you started.

That is the vibe. The entire journey — the curiosity, the failure, the persistence, the breakthrough, the emotion. That's what gives coding its energy and meaning.

I've spent countless hours fixing stubborn bugs — and no, it's not always fun in the moment. Sometimes it's frustrating, exhausting, even borderline demoralizing. But the second I find the solution, everything lights up again. Suddenly, the world feels colorful. I can even recall exactly what music I was listening to, what time it was, what the weather was like, what kind of coffee I was drinking — every tiny detail.

And later, when I hear that same music, it all comes back. I'm right there again, reliving those vibes again. That emotional journey, that sense of reward is what makes real coding meaningful to me. That's the actual vibe. It's not just about the outcome. It's about the journey that makes you grow.

Journey is More Important than Destination

When I was just starting out in my career, I was completely focused on the destination — the end result, the output, the "final product." But boy, was I wrong. Over time, I realized that the journey is what really matters.

There is no final destination — only milestones along an ongoing path. And that path is full of challenges, lessons, and most importantly, vibes.

This is exactly why I became a software engineer in the first place. Back in high school, I used to imagine my future self as someone who could understand complex systems on a deep level — someone who could solve problems with a precise, hard-earned set of skills. That image inspired me. That's what makes this job so cool.

And to me, that's the real vibe — the emotional rollercoaster you go through while coding. The ups and downs. The frustration and the breakthroughs. The way your mood shifts as you immerse yourself in the problem and slowly figure things out on your own. I don't think there's a better vibe than that.

I can't comprehend how anyone can call it vibe the process when you just tell an LLM what to do and it just generates code for you. I'm not saying it's all bad and I'll talk about this later, but I don't see myself doing that anytime soon.

Let's Go Back in Time

Let's imagine what vibe coding would've looked like back in the 1980s — back when AI, at the level we have today, was still science fiction.

You're a computer science student trying to cover your college fees. You open up the local newspaper and find an unusual job listing:

HELP WANTED: VIBE CODER
80sCoolVibes, Inc.
Venice Beach, California – Est. 1981

Are you looking for a coding job that doesn't require any actual coding knowledge?
Can you explain something in plain English?

Then congratulations — this job is for you.

... and the rest of the text ...

The salary isn't great, but it's just enough to cover your tuition fees. So, you apply — and to your surprise, you get the job.

It's your first day at work, and you're excited. You're finally stepping into the tech world during one of the most iconic decades in history — the 1980s. Computers are taking off. The future is being written in real time, and you want to be part of it.

At the office, there's one guy named Marcus — the only actual software engineer in the company. He's sharp. He writes great code. But here's the catch: he doesn't make decisions. He doesn't design systems. He just sits there and waits for someone — you — to tell him what to build.

Your job? Tell Marcus what you want. Wait for him to build it. Review the result. Tell him what to tweak. Repeat.

And you start to realize something doesn't feel right.

You're in the vibiest era of tech history. You wanted to be a builder, an innovator, someone who understands systems from the inside out. But instead, you're playing telephone with a keyboard. You're not writing the code — you're just approving it. Guiding it. Prompting it.

You're not a coder. You're just the guy who tells a code generator what to do — whether that generator is a human or a machine. The core concept is the same.

I don't know about you, but in that moment, I'd start seriously question my decisions and job-searching skills — or I'd just assume that I'd have become a character in a new Black Mirror episode, which sounds even scarier.

Abstraction Over Abstraction?

Programming languages are becoming more and more approachable every day. Modern languages tend to borrow the best ideas from one another, striving to make their syntax cleaner, more intuitive, and easier to learn. There are always exceptions, of course, but in general, if you're building a language you want to be future-proof and widely adopted, embracing these advancements is no longer optional — it's essential.

Now, you might argue that languages like PHP are still widely used, or that almost the entire American banking system runs on COBOL. And you're right — but those are a different category entirely. I'm not talking about languages that were used to build massive, legacy systems that are practically impossible (or extremely risky) to rewrite.

Take aviation, for example. If an aircraft's onboard software is written in C, nobody wants to migrate it to something "nicer" — and for good reason. You don't want unexpected bugs showing up at 35,000 feet. Similarly, if a banking core system has been running on COBOL for decades, it's often better to leave it alone. The system is so large and so critical that even a minor change could cause major disruption. In those cases, stability outweighs elegance every time.

But for new projects — ones that are just being designed or trying to gain traction — it's a different story. If your language isn't easy to read, write, and reason about, and it doesn't offer some other groundbreaking advantage, it's going to struggle to gain widespread adoption. Developer experience matters now more than ever.

The point I want to make here is that modern high-level programming languages have become incredibly intuitive. Take Python, for example — you can practically read it like plain English, and that's a good thing. Anyone can build a simple calculator app in Python after just a few minutes of learning the basics. That's the power of accessible syntax — it empowers people to build, not just prompt.

You don't need to ask an AI model to write the entire thing for you. You can write it yourself, in your own words, and still be in full control. You're the pilot — sitting on the left, hands on the yoke. When you hit a dead end or need help remembering a piece of syntax, you turn to your copilot (AI). You get the information, refine it, adapt it to your specific needs, and then integrate it into your codebase. You're not blindly copying — you're still steering your aircraft.

What vibe coding does is introduce yet another layer of abstraction — on top of an already abstracted concept — but this time, the abstraction is much less predictable. Programming languages like C# are already high-level and abstracted from machine code, but they're still precise and reliable. If you write something that breaks C#'s syntax rules, it won't compile. Simple as that. And if you do know how to code in C#, you're in control. You can log errors, debug critical sections, analyze performance, write clean, maintainable code — in other words, you're the pilot. You understand what the system is doing under the hood. Even though it's abstracted, it's consistent and deterministic.

But vibe coding changes that. The abstraction it introduces isn't like the one you get from managed code — it's much more vague. For example, the C# compiler will always generate the same Intermediate Language and bytecode for the same piece of source code. AI tools, on the other hand, might generate completely different outputs for the same request depending on context, randomness, or prompt phrasing. That makes this new layer of abstraction far less reliable — at least for now.

Now, What Happens if You Trust the AI Too Much?

I'm not sure what the future holds for AI, and I won't pretend to predict it — but right now, if you trust AI too much while coding, things can go very wrong, very fast.

Just to be clear, I'm not talking about workflows where you ask an AI for help, review the output, tweak it, and then you thoughtfully integrate it into your project. That's fine. That's productive. That's what a good copilot is for. I'm talking about full-blown vibe coding — where you prompt something vague, don't even look at the code, and ship it straight to production. There are already plenty of examples of how badly that can go.

Take the now-infamous SaaS project built with Cursor. The author proudly tweeted that it had “zero hand-written code.” Two days later? He was tweeting again — this time about API keys getting maxed out, users bypassing subscriptions, and random junk being dumped into the database. In their own words, “random things were happening.”

That's not software engineering. That's rolling the dice and calling it development.

I still genuinely felt for that person — it's incredibly frustrating to believe you've built something amazing, only to watch people abuse it, exploit every loophole, and drain it of all value. But this is something we all need to come to terms with: there's no shortcut to sustainable success.

Even if you get lucky and achieve something quickly without much hard work, those shortcuts usually come with cracks. And cracks are easy to exploit.

People will notice the shortcuts you took to succeed — and some will deliberately lay traps along those same paths, just waiting for someone to slip.

Yes, it's wrong to take advantage of someone's failure. But the world isn't fair — and the internet certainly isn't. There are always people out there actively looking for weaknesses to exploit. That's why whether you're building a product, starting a business, or learning a new skill, the best mindset is simple: "hope for the best, expect the worst". It's not pessimism — it's preparation.

Security Risks

Now that we've looked at the vibe-coded SaaS example, let's briefly talk about the security risks that come with this approach.

When you're building software for a company, security isn't optional — it's a top priority. You don't want your secret API keys showing up in a GitHub repository, or worse, exposed publicly. You want credentials, tokens, and sensitive configs to be stored securely, encrypted, and properly scoped.

But AI tools don't inherently understand what's sensitive in your application. They don't know which variables are secrets, what data should never be logged, or what security best practices apply to your use case. Sure, you might know and tell the AI that — because you're an experienced developer who's run into those problems before. But what about someone who hasn't? Someone using AI as a helper tool, without ever having built a secure system from scratch? They might unknowingly commit secrets to version control, log user passwords in plaintext, expose internal endpoints, or open up massive attack surfaces — all because the code "looked fine."

That's the real danger of vibe coding: it can skip over the parts you didn't even know you were supposed to care about.

Unless You're Building a Very Simple App, You'll Eventually Need to Talk to a Real Engineer

Software can become very complex very quickly — especially in enterprise environments. If your app is being built entirely by an AI model and you eventually hit a wall trying to change something highly specific, there's a good chance AI won't be able to help. One time, I was customizing my personal .NET project template application. I needed to tweak a template.json file for a .NET project template in a very specific way, and even after multiple attempts, the AI couldn't generate a working solution. I ended up finding the fix kept deep in a GitHub discussion thread.

At that point, you need a real software engineer — someone who can read, understand, and surgically update the code. Or even who knows how to find a solution that can't be found by AI. But here's the catch: that person likely isn't going to have a good time working with AI-generated code. In fact, it may take a huge amount of effort just to add a feature, fix a bug, or even understand the existing structure. Refactoring that codebase from scratch? That could be a nightmare.

Vibe coding builds fast, but it can also accumulate massive technical debt — quietly, invisibly, and quickly.

And Last but Not Least — Sustainability

When asked how much OpenAI loses from people saying things like “please” and “thank you” to ChatGPT, Sam Altman famously replied on X:
“Tens of millions of dollars well spent — you never know.”

And that's just for polite responses — things like “no problem” or “you're welcome”. If those tiny interactions cost tens of millions, it gives us a rough idea into just how much energy is being consumed behind the scenes.

Now zoom out and look at the full scale of ChatGPT alone:

~122 million daily active users
~400 million weekly active users
~1 billion messages processed every single day
~1 GWh of electricity consumed daily — roughly equivalent to powering 33,000 U.S. households per day

That's a staggering amount of energy for just one product.

One of the core principles of software engineering has always been efficiency — not just in performance or architecture, but also in how we consume resources. Yet with vibe coding, we're doing the opposite: we're pushing energy usage to unprecedented levels. It's one thing to occasionally look something up on a static webpage. It's another to have AI models generate, regenerate, and rephrase entire codebases throughout the day.

There are tens of millions of software engineers on the planet today. And vibe coding — by its nature — is easier than actual engineering. So it's not hard to imagine a future where vibe coders far outnumber traditional developers.

If that happens, the energy footprint of software development could skyrocket — bringing with it a significant increase in carbon emissions, and a sustainability crisis we're not prepared to handle.

This isn't just a technical issue anymore. It's an environmental one, too — and we'll have to deal with it sooner or later.

As we Move Towards the End, Let's Switch to a Positive Note

So where does vibe coding actually make sense?

Boilerplate Projects / Code

For starters, generating quick boilerplate projects can be a great use case. AI tools can simplify the process dramatically — especially if you don't already have a templating system in place. Granted, if you've invested time in building your own custom templates, generating a boilerplate can be as simple as running a single CLI command. But if you haven't? AI can fill that gap nicely.

Demo Projects

Another area where vibe coding really shines is in creating demo projects for clients. Sometimes, you don't need a fully functional product — you just need something to show. A working concept. A rough proof of idea. Instead of burning hours stitching together a throwaway demo, you can let AI handle it. Build fast, present your vision, and either toss it afterward or keep it as a prototype to refine later.

Bridging the Gap Between Engineers and Managers

This approach can also be incredibly useful for non-technical stakeholders, like project managers or product owners. Using AI tools, they can build quick prototypes to visually and functionally communicate their vision to the development team. Instead of writing long requirement documents they can generate a rough version of the product they have in mind — making it much clearer what they're aiming for. This kind of rapid prototyping can reduce misunderstandings and help developers deliver exactly what's expected faster and more accurately.

Dipping Toes in Creating Products

It can also play an important role in onboarding new developers or helping people explore the field. By experimenting with AI-generated code, beginners can get a glimpse into what coding looks like across different domains. They can generate web apps, desktop tools, mobile apps, games and discover what excites them. While it's no substitute for deep learning and real experience, vibe coding can serve as a gateway to real software engineering.

To Sum Everything Up

Vibe coding isn't inherently bad — but it can be a slippery slope when used in the wrong context. Like almost everything in life, it's a tool. And like any tool, it can work in your favor, or turn into a liability. It all depends on how and when you use it.

Will I be vibe coding anytime soon? Probably not. I still want to be the main pilot in my cockpit — fully in control, fully aware of what's happening under the hood. It's not the right time for me to trade seats with AI and hand the yoke over to an AI to become the copilot.

But once it becomes the standard, I'll definitely make the switch. — I still believe this is the future in a long run.

If someone else finds energy and creativity in that workflow? If they're passionate about building that way? Then by all means — let them. No one has the right to discourage someone from exploring new workflows or tools. All I ask is that they go in with eyes wide open, fully aware of the risks and limitations, especially if they don't yet have the technical experience to spot red flags.

At the end of the day, we're all part of the same developer community. Whether you're old-school or new school, hands-on or voice-prompted — what matters most is that we respect each other's paths and help one another grow.

And that's the real vibe!