What is vibe coding, and why is it changing the way we work?

Vibe coding has, in a short time, become an established concept in the AI space and among product and software developers.
‍
The name is no coincidence. “Vibe” points to a more creative and less intimidating way of thinking about code, where you don’t necessarily sit and fine-tune every single line, but instead work in a flow of rapid iterations. Suddenly, you can “talk” a piece of software into existence. Not as magic, but as a new form of collaboration between human and machine, where the AI produces the code, and you produce and define the intention.
‍
This means that more team members can take part in building, that prototypes can be created in record time, and that feedback loops can become extremely short. On the flip side, new demands arise around quality, security, and workflows. Because while vibe coding can propel you forward quickly, it can also send you off the road at race-car speed.
‍
To understand vibe coding in practice, we spoke with Anne Lindberg, a software developer in Digitalization and IT at the Central Denmark Region, and founder and consultant at LindbergAI, where she helps companies get started quickly with AI-driven solutions. She works daily with generative AI, is trained as a software engineer, and has a strong background in backend development, AI tools, and digital product development.

What is vibe coding, in your own words?

“If we strip it down to the essentials, vibe coding is using generative AI to code for you. You describe what you want in a prompt, and then the model writes the code. It’s a bit like using AI to generate text or images — just with software as the output.”

Where does the concept come from, and what distinguishes vibe coding from regular prompting?

“The term gained particular attention through a post by Andrej Karpathy, an AI researcher and former Head of AI at Tesla, who in February 2025 wrote that he had started coding in a new way he called vibe coding. The movement of creating code via prompts was already well underway — but now it had a name for this way of developing. The point was precisely to surrender to the flow. You don’t sit there fine-tuning every single line yourself.

You look at the result, copy and paste, and when something breaks, you feed the error message back into the model and essentially say: fix it — and then you iterate from there. In Karpathy’s own description, it goes so far that he barely touches the keyboard but can speak to the tool and have things built.
‍
Prompting is a broad concept that can cover everything from text and images to analysis and ideation. Vibe coding is more specific: it is prompting with the very concrete goal of making a piece of software work through rapid iterations.

You build by describing, testing, debugging, and improving—and in the pure spirit of vibe coding, you don’t necessarily need to understand every line of code along the way, as long as you can steer the direction and verify the outcome.”

Do you remember your first encounter with vibe coding?

“Definitely. I don’t actually think I knew it was called vibe coding at the time. I saw a post on LinkedIn about someone who had tried a tool, and I thought: that looks really smart. I’ve never been particularly good at building UI and frontend. I work as a backend developer, so I had the tool create a website for me — and I was completely blown away by how much cool stuff it produced. I told everyone I knew, both at work and in my family.
‍
I even got my dad, who’s really into wine, to create a wine website and something for his golf club. I thought it was incredible that I could suddenly do something I’ve always found really difficult. So it really was a revelation. I remember thinking: this is seriously powerful. And it’s only accelerated ever since.”

What specific challenges in product development does vibe coding help solve?

“The biggest difference is speed. Previously, it could take a really long time to build something — even a single feature could take weeks or months. With vibe coding, you can often get a first version in just a few days, which means you can test earlier and learn faster.
‍
But it’s not just about speed. It also changes who can take part in building. Suddenly, it becomes more accessible — you could say software development is being democratized. More people on the team can contribute directly to getting something up and running, not just the traditional developer role. It could be product people, designers, or others who can clearly describe the need and iterate together with the tool.
‍
And then there’s something I think is quite important: personal software. Instead of buying yet another tool and another subscription, in many cases you can build exactly what you need yourself. Small solutions tailored to your specific day-to-day work, without having to wait for a large development process.
‍
I remember once, for example, a colleague and I couldn’t decide whether to use Trello or Jira for a project — and both were probably a bit overkill for what we needed. So we sat down, and within an hour and a half we had built what we used to manage our projects and tasks. That’s where vibe coding is really powerful.”

Are there other strong use cases for vibe coding?

“Prototypes — that’s another area where vibe coding is really powerful. When you can get your ideas out quickly, both visually and functionally, so you can test them and get feedback right away. Vibe coding is also great for customer dialogue and stakeholder conversations. If you can build a sketch live or within a very short time, it becomes much easier to clarify: is this what you meant? Or is it completely off? It saves an enormous number of rounds based on assumptions.
‍
Vibe coding is also well-suited for the small solutions that would otherwise never be prioritized. This could be internal tools or personal software, where you’d normally end up buying another tool or living with a workaround. Here, vibe coding makes it realistic to build a small solution that fits the need exactly, without turning it into a massive project that drains organizational resources.”

What is vibe coding not good for?

“I usually say that vibe coding tools are really good for simple to moderately complex projects. But if you’re building something very, very complex, it might not be the right approach to vibe code everything — you may instead need skilled developers to help build it properly.
‍
It also very much depends on what you’re working with. If you don’t have the technical understanding yourself, and you’re dealing with something complex that may also involve sensitive personal data, you need to be able to ensure that the vibe coding tool you’ve used hasn’t taken some clever shortcut to make things easier, which could end up becoming a security risk in the software you’ve built.
‍
For complex systems, I wouldn’t just vibe code them directly. It requires thorough groundwork and a solid setup of architecture, security, and governance before it works in practice.”

What does a good vibe coding process look like in practice?

“If you want to set yourself up for a good vibe coding session, it starts with maturing the idea. You can do it on your own, but you can also use tools like ChatGPT to spar on scope, needs, and what exactly should be built.
‍
Once I have a rough idea of what the solution should do, I usually sketch some wireframes or get something visual down. That makes the prompts much sharper. After that, I feed it into a tool like Lovable, which is also designed to ask clarifying questions if it’s unsure about what you’re asking.
‍
Sometimes I use it more spontaneously. If I just have an idea I want to test quickly, I skip the first steps, open Lovable, and use the annotation feature to say: ‘Build this.’ The output isn’t necessarily what you end up using, but it can be enough to quickly see the direction and test it before investing more time.
‍
And if it’s going into production, it’s often quite simple. There’s a publish button, and in practice you can launch with a single click. If you have your own domain, you can connect it—otherwise, they generate one for you.”

What pitfalls do you most often see when people get started with vibe coding?

“There are definitely pitfalls, but the better tools you use, the fewer you run into, because they have built-in guardrails (security mechanisms, ed.) that help prevent vulnerabilities.
‍
A typical mistake in the beginning is that the output becomes very generic and doesn’t look particularly good. So you need to learn how to prompt in a way that improves both quality and expression. And it’s crucial to think design first when prompting — because in the end, it’s garbage in, garbage out. So it really comes down to getting good at prompting.”

How do you ensure quality along the way?

“There are definitely some preconceived notions about code quality, and that may have been more true a year ago — or even just six months ago. But the tools are evolving so quickly now that if you have a reasonable understanding of how to prompt them technically, you can often catch errors along the way — and they also don’t occur by default in the same way anymore.

Previously, for example, you might see API keys end up in a file and become exposed (keys that should be hidden were accessible to everyone, ed.), but that’s not how these tools are designed today. Most tools include a security check you run before publishing, which catches the vast majority of issues. But of course, you can’t avoid the basics: you still need to test your code and make sure everything works as it should.”

Which tools are the most widely used?

“If we look at the most widely used tool right now, it’s Lovable, which I’ve already mentioned. It’s a vibe coding tool from Sweden, and it’s definitely one of the biggest. It also functions as a no-code tool, where you don’t really have to look at the code if you don’t want to.
‍
And it’s also worth adding that if you’re a developer — or feel like trying some more advanced vibe coding tools — you can try Claude Code or Cursor, which are two of the most popular tools on the market right now.
‍
What really characterizes this space at the moment is the speed. I’ve experienced people asking during a workshop, ‘Why can’t the tool do X, Y, Z — for example export to a webshop?’— and then the next morning they announce that you can now build an entire webshop with the click of a button. That’s how fast things are moving — it’s wild.”

‍