There is a new phenomenon in the tech industry. It's called vibe coding, and it has convinced an entire generation of project managers, entrepreneurs and career changers that they are now software developers. Spoiler: They are not.
For those of us who have been in the industry long enough to remember the Dreamweaver era, it feels familiar. Back then it was also suddenly possible for everyone to "make websites" without understanding HTML. The result was millions of unmaintainable monsters with nested tables, inline styles and blinking GIFs. We cleaned up for years. Now the story repeats itself, but with more advanced technology and significantly higher stakes.
Let me state it right away, before the angry comments start ticking in: I love AI-assisted development. I use it daily. Intensively. Almost intimately. My VS Code is so integrated with Claude and Copilot that I sometimes forget who of us is actually writing the code. But there is a crucial difference between using AI as a professional tool and using it as a magical wand that turns ignorance into working software.
Welcome to the era of prompt-driven self-deception
Vibe coding, for the uninitiated, is the art of describing what you want to an AI, accepting the first output, and then declaring yourself finished. It’s programming reduced to wishful thinking. It’s like ordering a burger at a restaurant and then calling yourself a chef.
And it works. At first. That is the terrible thing about it.
You prompt: "Make me a login page with React and Firebase." And voilà, you have a login page. It compiles. It runs. You can log in. You post a screenshot on LinkedIn with the caption "Day 1 of my coding journey 🚀" and reap likes from other people who have also just discovered that they can get an AI to write code for them.
But what you don’t know, because you don’t have the technical background to assess it, is that your newborn login page:
- Stores passwords in plain text in localStorage
- Has three different race conditions
- Uses a deprecated Firebase SDK from 2019
- Has an SQL injection vulnerability, even though you aren’t even using SQL (yes, it’s possible, and no, I won’t explain how)
- Is structured in a way that makes seasoned developers cry softly into their coffee
But hey, it works. And that’s what counts. Right?
"It works" is not the same as "it’s finished"
Here is the uncomfortable truth that no one on Twitter will tell you: Getting code to compile and run is the absolute minimum. It is not a quality stamp. It is the starting line. Not the finish line.
Imagine a bridge. You can build a bridge that holds one car, once, under perfect weather conditions, if the driver isn’t overweight, and if no one looks at it too long. Technically, it’s a bridge. It “works.” But would you drive over it every day? Would you let your family drive over it?
The same goes for software. Production-ready code must handle edge cases, failure states, concurrent users, unexpected inputs, network issues, timeout scenarios, and a million other things that your friendly AI assistant didn’t think of because you didn’t ask, and because you didn’t know you should ask.
Vibe coding is like building a house by asking someone to describe what a house looks like. You get walls and a roof. But you don’t get a foundation, insulation, plumbing or electrical installations that comply with building codes. And when it rains, you’ll notice the difference.
The invisible bill: Technical debt with interest
Here comes the part where I address those of you who hire people, and those who think you’ve just saved 500,000 kroner by letting the intern vibe-code your MVP.
Technical debt is a concept we use to describe the price you pay later for shortcuts you take now. And vibe coding without technical understanding is not just a shortcut. It’s taking out a loan from a loan shark, charging 40% interest, paid in developer hours, frustration and delayed releases.
I've seen it again and again. A startup launcher with a "working" prototype, built by a founder who learned to prompt their way to an app over a weekend. Six months later they hire proper developers to "just add a few features." The right developers look at the codebase. There is a long, heavy silence. Someone leaves the room. Someone starts drinking.
What would have taken two weeks takes four months. Not because the new developers are incompetent, but because they first have to archaeologically dig out what the original code was trying to do, and then rebuild it from the ground up while keeping the existing functionality running.
This is not a hypothetical scenario. This is Tuesday in the industry. Every week, capable developers inherit code problems they didn’t create themselves, and spend their work time cleaning up after people who thought they could prompt their way out of understanding what they were making.
The invisible victims: The developers behind the cleanup
Let’s talk about those who pay the price for vibe coding without accountability. It’s not the people who produce the questionable code. They’re long gone to the next project, next startup, next LinkedIn post about how AI is revolutionizing their productivity.
No, the price is paid by the developers who inherit the mess. They get a codebase that looks like the result of someone asking an AI to solve problems the person didn’t understand. And you can see it. No coherence. No architecture. No conventions. Just layer upon layer of generated solutions stacked on top of each other like a digital Jenga tower waiting to topple.
These developers must now:
- Understand code that follows no recognizable logic
- Debug problems in systems without documentation
- Add features to an architecture not designed to scale
- Explain to management why "just a small change" takes three weeks
- Do all this without being allowed to throw it all away and start over
It’s like being asked to renovate a house while the family still lives in it, while the house is actively collapsing, and while someone constantly asks why you don’t just "fix the roof quickly."
Burnout in the tech industry is a real problem. And part of the problem is that capable people spend their energy compensating for others’ irresponsible use of tools they don’t understand.
My own practice: Dancing with AI without stepping on my own toes
Now I’ll be honest about my own use of AI in development, so I don’t come off as a hypocrite preaching tools I use daily.
I vibe code. All the time. But I do it with open eyes and with decades of experience in my pocket.
Here’s the difference: When AI generates code for me, I’m its code reviewer. I read every line. I ask questions. I refactor. I discard. I ask for alternatives. I integrate it into an architecture I understand and can defend.
At the same time I use AI as my code reviewer. I ask it to review my own code for bugs, security holes, performance issues and stylistic inconsistencies. It’s a collaboration, not outsourcing.
My responsibility doesn’t disappear because AI wrote the code. The architecture is still my responsibility. Security is still my responsibility. Performance is still my responsibility. Long-term maintenance is still my responsibility. AI is an extremely powerful tool that makes me faster and more efficient. But the tool doesn’t take responsibility. I do.
It’s like the difference between using an electric saw as a trained carpenter versus using it as a total amateur. Both can cut wood. Only one knows what happens when something goes wrong.
The dangerous confusion: Tool versus competence
There’s a broader trend here that goes beyond vibe coding. We see it in no-code platforms. We see it in low-code solutions. We see it in every single "build an app without writing a line of code" ad.
These tools aren’t the problem. The problem is the implicit claim that the tool replaces competence.
A good calculator won’t make you a mathematician. A spell checker won’t make you a writer. And an AI that can generate code won’t make you a developer. These tools amplify existing competence. They don’t create it.
That doesn’t mean the tools are useless for beginners. On the contrary. AI can be a fantastic teacher, a patient explainer, an inexhaustible source of examples and guidance. But learning requires actually trying to understand, not just copy-pasting and moving on.
If you use AI to learn, you’re on the right track. If you use AI to avoid learning, you’re building on sand.
Who bears the responsibility?
This is a legitimate question, and the answer is uncomfortable for everyone involved.
AI companies bear some of the responsibility. Marketing often promises more than the tools can deliver, and downplays the necessary competencies to use them responsibly.
Decision-makers bear some of the responsibility. When you hire people to "vibe code" critical infrastructure because it’s cheaper than hiring real developers, you’ve made a choice with consequences.
But mainly, individuals bear responsibility for their own choices. If you know you don’t understand the code you produce, and you still deploy it to production, you’ve made an unethical decision. Not because AI is dangerous, but because you’ve chosen to ignore your own ignorance.
A constructive path forward
I won’t end with pure criticism, because that serves no one. Here’s what I actually recommend:
If you’re new to development and drawn to vibe coding: Fantastic. Use it. But use it to learn, not to avoid learning. Ask AI to explain the code it generates. Ask dumb questions. Try changing things and see what breaks. Build understanding, not just artifacts.
If you’re an experienced developer: Embrace the tools. They make us faster and better. But remember that your responsibility is not outsourced. You’re still the grown-up in the room.
If you’re a decision-maker: Stop thinking that AI eliminates the need for competence. It merely shifts it. Instead of trimming the developer budget, invest in people who know how to use these tools responsibly.
The conclusion you came for
Vibe coding is a powerful tool. In the hands of developers with technical understanding, it accelerates work, improves quality and opens new possibilities.
In the hands of everyone else, it’s just an extremely efficient way to produce future problems.
And those problems? Real developers end up solving them. With overtime, frustration and a quiet wonder about why anyone ever thought this was a good idea.
So next time you prompt yourself to a "working" solution, ask yourself one question: Do I understand what this code does? Can I defend it? Can I maintain it? Can I debug it when it goes wrong?
If the answer is no, you haven’t built software. You’ve just kicked the problem down the road.
And the bill always comes.
I personally use AI-assisted development daily and warmly recommend it to anyone who knows what they’re doing. To everyone else I recommend learning what they’re doing first.
