Vibe coding, explained for people who don't code

I'll be honest with you, I am not a software engineer. My background has always been strictly on the commercial side of things. When I returned to Stockholm from university in the States, I took a job selling PR services on pure commission. Almost everyone around me advised against taking a job with no base salary, but a guy I met there named Fredrik Bage told me I would be good at sales. He was right, and we eventually left to co-found a company called Mediapilot. We spent roughly seven years growing that business and created more than a hundred jobs in the process. I spent those years talking to clients, negotiating, and trying to understand what the market actually wanted. I did not spend my time writing Python or configuring servers. Later, when I worked on the commercial side at Happeo, my job was still entirely focused on people and revenue, not code. So when I sit at my desk in Marbella today building infrastructure for AI developers, I am doing something that would have been completely impossible for me three years ago. I am vibe coding.

The phrase itself sounds like a joke you might hear at a terrible networking event, but it describes a very real mechanical shift in how we build things. If you do not know how to code, making software used to mean hiring someone who did, attempting to explain your idea to them, and hoping they understood your vision. Vibe coding removes that gap entirely. You open an AI tool and you write your instructions in plain English. You type, "build me a login screen." The AI writes the code and renders the screen for you. You type, "make the primary button save the file when clicked." The AI updates the underlying code. When the application breaks, you simply copy the error message, paste it back to the AI, and say, "fix this broken logic." You are steering the software entirely by feel. You do not need to understand the syntax or the maths. You just keep adjusting the prompt until the output matches the shape you had in your head.

The trap of the working prototype

The immediate rush of this is hard to overstate. Right now, I am spending a lot of time building Anchor, a project I am working on to provide AI for alienated fathers. In the past, if I wanted to test a specific user flow for those fathers, I would have had to draw boxes on a piece of paper, wait for a designer to make it look acceptable, and then pay an agency to build a click-through prototype. Now, I can spin up a working web interface in a Tuesday afternoon between bad tennis matches. I can test the logic myself. I can click the buttons and see the exact shape of the product before anyone else is even involved. For building internal tools, or for proving that a concept actually makes sense in practice, this method is fantastic. You completely bypass the translation layer of human communication.

You can build a house out of cardboard very quickly, but you probably shouldn't wire it for electricity.

But the bill always arrives eventually. This is the part that non-technical founders wilfully ignore. When you vibe code, the AI is focused entirely on making the thing work right now, on your screen, in this exact moment. It will happily write redundant logic, ignore basic security protocols, and structure your database like a teenager's messy bedroom. Because you cannot read the code, you cannot see the rot accumulating underneath. You only see a button that successfully clicks. As soon as you try to put real user data into that system, or attempt to scale it, or simply try to maintain it three months later, the entire structure starts to collapse under its own weight. Technical debt is no longer something that builds up over years. With AI, you can accrue massive technical debt in a single afternoon.

Knowing where the handoff is

I got this wrong for a while. I assumed the AI was a direct replacement for an engineering team. It is not. The AI is a replacement for a whiteboard. The true value of vibe coding is purely communication. When I am working on Substrat, our AI infrastructure project, I now use this method to build functioning, ugly, completely insecure prototypes. I sit there and prompt the AI until I get the logic exactly how I want it to behave. Then, I hand that messy prototype over to actual, professional engineers. I show them the working application and say, "Look, this is exactly what it needs to do, but please throw all my code in the bin and build it properly."

It saves weeks of costly misunderstandings. The developers never have to guess what I mean by a certain feature because they can actually interact with it. They can see the flow. And in return, I never have to pretend I understand the server architecture required to keep user data secure or the best way to structure a production database. I stick to the commercial side, the initial shape of the product, and handing over a perfectly clear brief. I keep a written life plan that I update every year, rating my work, finances, and family time out of ten, and I can tell you that trying to maintain messy code will quickly drag your work score down to a two. I haven't got the entire future of software figured out yet. I still get things wrong regularly. But I know this much is true today: you should absolutely use AI to build your prototypes, and you should absolutely never let those prototypes near your real customers.