Vibe Coding: AI is changing who gets to build things
Why AI might be the best coding partner you'll ever have
I didn’t know how to code in Power BI, but I still ended up with a working dashboard. Copilot helped me figure it out, one prompt at a time. This article is about vibe coding. Building by describing what you want, not by knowing or writing perfect syntax. It works for me because it lowers the barrier to building something useful, it works for organizations if they create the right environment and it might just be a glimpse of how we’ll build in the future.
I recently watched a YouTube series where someone tried to make a SaaS application without doing any of the coding themselves. They were purely going to interact with AI, give their problem statements, iterate the product by engaging with the AI and having the AI do all the coding for them. And I have to say: I was pretty impressed by the end result.
Sure, this was a hobby project, which of course is different than doing this in a serious enterprise environment. Still the question that keeps being stuck in my head for the last couple of weeks: Is it a good thing that you can build a working script without knowing how to code?
What is ‘vibe Coding’?
The term ‘vibe coding’ was first used in February 2025 by Andrej Karpathy, one of the co-founders of OpenAI. He tweeted:
So basically vibe coding is what happens when you build something technical like a script or data pipeline without really knowing the language you’re working in. You’re not writing code from scratch. You’re vibing with AI, feeding it problem statements and letting it generate the code for you.
For me the point of vibe coding is not that you get to be lazy (although that’s a nice benefit 😁). It’s about being curious, exploring new technologies and above all it’s about getting to the end result.
The Power BI struggle
In the last couple of months I’ve been working on gaining some skills and knowledge on Power BI. How to import data, how to transform data and how to create compelling visuals based on that data (people seem to really like it when data is presented through vibrant colors).
I found that when you want to create custom fields and visuals, you want to use something called DAX (Data Analysis Expressions). With little to no prior experience in Power BI, you can imagine my reaction when I found I also needed to learn how to write code using a ‘language’, or at the very least a logic, I never even heard of prior to starting this journey.
I started off by asking my Power-BI-guru-colleague how to write some simple stuff like 'count the number of rows’ to get to a number which you can display. That one proved to be simple enough: COUNTROWS(YourTable). Then I wanted a more detailed visual, in which I wanted to display counts based on more criteria. Took a bit more time, but we got there in the end.
Normally for me this is right around the time when you don’t want to bother your colleague with yet another question and you try to find the answer on your own. Usually, that goes something like this: Google it. End up on Stack Overflow. Lose faith. Close the laptop. Repeat.
Not this time though! Instead of spending hours deciphering Stack Overflow threads, I turned to Copilot. And boy, was that a good decision!
Copilot as a coding partner
By explaining what I was doing in Power BI to M365 Copilot in Business Chat, I could ask really specific questions which applied to my exact situation. At the same time I didn’t feel like a complete idiot reading from people that know way more than me. If something was too difficult or too vague, I just asked Copilot to dumb it down a little for me. Got an error message? Just paste it into Copilot and ask how to fix it.
The result: a working dashboard, showing the visuals that I want in the way that I want them to show.
By no means am I an expert in Power BI or DAX coding, but does that matter if I get to the result that’s needed?
What stood out to me is how Copilot changes the way we think. It’s not just a tool that writes code, it’s a partner in writing code for and with me.
You start with a vague idea “I want to present information on a Power BI dashboard” and Copilot helps you shape it. It asks questions, suggests approaches and even points out errors in your logic. It’s like programming with someone who never gets tired of you (and your corny jokes) and doesn’t judge your dumb questions*.
*For the people that think “There are no stupid questions”: Some of my Copilot prompts beg to differ. Although the responses always seem to indicate that it was a “really good question”…
That’s powerful. Especially for people who don’t see themselves as developers. Even for those hardcore developers, vibe-coding may also be useful in different aspects. Specifically the integration of Agentic-mode Copilot in your favorite IDE, such as Visual Studio code with GitHub Copilot, is really powerful. Performing a root-cause analysis based on a bug or error message in a repository containing hundreds of files of code has become quite easy. In environments where the amount of work is measured in effort, this will have quite an impact.
Why this matters for organizations
From my experience most will agree there is a line between hobby-projects and production environments in organizations. But where do we draw that line?
A strong argument for caution is the worry that by allowing vibe coding in your organization, you’re building, or at least increasing, the risk of technical debt. Without structure, documentation or testing, you might end up with something that works today but breaks tomorrow without anyone knowing why. That’s not a risk you want in an enterprise environment.
At the same time, isn’t this already happening at the moment? Most scripts in organizations aren’t peer-reviewed or unit-tested. They’re built by people who know “just enough” to get the job done. If anything, Copilot makes that process more consistent. You can define guardrails, enforce patterns, and even build agents that check the code for you.
Most organizations are full of people who have ideas but lack the technical skills to implement them. Copilot changes that. It lowers the barrier to entry. It lets people build things they couldn’t before.
But it only works if you create the right environment.
You need:
Guardrails: Define what’s allowed and what’s not based on your enterprise architecture standards, secure coding principles, AI guidelines, regulatory compliance policies etc. (You could even think about creating agents that would automatically check new and existing code for compliance and security)
Community: Encourage people to share what they’ve built with others and learn from each other
Support: Have senior developers who can review and improve the output
Training: Not just on how to use Copilot, but on how to think in problem statements
I would argue Copilot doesn’t remove the need for structure, but it makes structure even more important. The question here is: are organizations ready to embrace and facilitate this shift?
Shifting the way we think
The interesting part to me is how we (as professionals, as human beings) think about this. Does it matter if I understand what’s written down if it gets me to the desired result. And if so, to what extent does it matter? If I write 90% of the code and let Copilot write the other 10%, is that an issue? If I write 100% of the code, but I let AI review it, should we be concerned? Why do we trust a human to write or review something more than we trust a computer? All questions I also don’t have the answer to at the moment. Maybe there’s simply a business need to make someone accountable.
I don’t think vibe coding will replace traditional development. But I do think we’re in the midst of a shift in the way we work. At the moment I feel we’re thinking too much in how to improve our current processes and ways of working, while we should think in how AI enables us to work differently.
There used to be a time where I needed to know how a computer worked to use one, I also couldn’t ‘make a computer’ by just clicking together a virtual machine in Azure or play a computer game without knowing the command to start it from MS-DOS (giving away my age with this one). The point being: These things are really normal today, but were not as obvious some years ago.
I feel we’re currently shifting from “I know how to code” to “I know how to describe what I want”. We’re not replacing developers, we’re redefining what it means to build. And maybe not everything needs to be perfect. Sometimes, it just needs to work.
Final thoughts
At the end of the day: What do I know? I’m also still figuring this stuff out. But if a little bit of vibe coding means I get to build cool stuff without a screen full of syntax errors, I’m in!