Michał Wilk: I remember a story from a VC firm where one of the partners mentioned a student who came up with a great idea for an app to rent clothing to each other. So he asked her, “Do people actually want this?” She didn’t know, but she thought the idea was brilliant. So he told her, “Alright, post a note on your dorm door asking if anyone wants to borrow clothes”. As it turned out, nobody did, which saved her a massive amount of time that would have been spent building the app. These are startup practices that large organizations have largely pushed aside.

Bartek Śliwa: Hi everyone, Bartek Śliwa here. Welcome to another episode of the Euvic Talks podcast, where we bridge business and technology. Today, we’re demystifying the buzzword of 2025: vibe coding. Joining me today as our guest is AI Solutions Lead, Michał Wilk. Welcome.

Michał Wilk: Hi there.

Bartek Śliwa: First off, before we start demystifying vibe coding, demystify what an AI Solutions Lead actually does.

Michał Wilk: Sure. I focus on building solutions that leverage AI across pretty much every stage—that is, solutions that use AI during programming, during prototyping, as well as building actual AI solutions themselves. A colleague in marketing came up with the title for LinkedIn.

Bartek Śliwa: Got it. And what was your path to getting where you are right now? How did you become an AI Solutions Lead?

Michał Wilk: You know, going from a developer to a team lead, to staying constantly up to date with modern solutions—I think that’s the short version. From someone who was always passionate about programming and building products, to someone who led teams, and now to co-creating these products with clients and helping them through the software development process, finding ideas, and validating those ideas. That’s how I’d describe it in a nutshell.

Bartek Śliwa: Got it. Modest guest we have today. So, what exactly is this mythical vibe coding? Because nowadays we hear a lot about it, and there’s this belief—which I hope we can debunk soon, or maybe not—that you can basically write down what you need, and within fifteen or a few dozen minutes, you’ll have a ready-made application and can go conquer the world. So how is it really?

Michał Wilk: Mm-hmm. The term vibe coding was coined by Andrej Karpathy. It became the word of the year, as you mentioned. Andrej is the former Head of AI at Tesla, a co-founder of OpenAI, and currently works at Anthropic. In a post on Twitter, if I’m not mistaken, he described it like this: the definition is simple—you write in natural language, you get a working application, and you don’t check the code, you don’t audit it line by line, you just check whether it does what you wanted. Pure vibes. That’s where vibe coding comes from.

Michał Wilk: No, this is actually the moment when they end up with even more work. Hmm, because we have to separate building an app with bad code that can’t be reused—which vibe coding is great at delivering—from software engineering. On LinkedIn recently, I’ve seen a lot of extreme comments claiming that vibe coding is the absolute best and solves everything, right? There are also articles on various industry portals saying that code won’t exist anymore and developers won’t exist anymore. But there’s a second spectrum of people who say vibe coding makes no sense, is dangerous, can’t be scaled, and so on.

Bartek Śliwa: Right, so we’re talking about building a Proof of Concept, maybe even an MVP, right? So that ultimately—as people like to say now—we can throw away what we vibe-coded and build it from scratch with proper diligence, quality, and security principles.

Michał Wilk: Yes, that’s the approach closest to me: using vibe coding during Discovery. During workshops, or throughout the process, or as a finale, we create something interactive. We don’t write a giant list of requirements or build Figma wireframes. We don’t rely solely on assumptions; instead, we build something clickable that can be handed to a user to confirm our hypothesis.

You can even reverse the process a bit—start with the prototype and draft the requirements later. And the prototype itself can serve as input for the team that will deliver the final solution and take care of security, scalability, SLAs, audits, GDPR, and all the other aspects that are incredibly important in software development and software engineering as a whole.

Bartek Śliwa: Got it. What’s the difference between vibe coding and a classic approach to building a Proof of Concept?

Michał Wilk: That we use natural language for the most part. We don’t need to know or focus on best practices, we don’t need to remember testing, and we don’t need to solve all the standard problems that tidy code caring about architecture and security would address. It’s enough that we prompt. And that’s the main difference, because it allows us to deliver faster—not better, but faster—working things, while keeping that division in mind, right?

Meaning that vibe coding ultimately serves Discovery, and its goal is to be thrown into the trash bin. It is meant to land in the trash eventually, and the more prototypes fall into that bin, the better, because that’s actually how we generate savings. Something that confirms our hypothesis or invalidates it can be validated very quickly.

Bartek Śliwa: I think that’s a key takeaway that decision-makers should take with them: the ability not to get attached to your own idea, but rather… Well, we can have infinitely many ideas. Maybe not infinitely many—that would border on bankruptcy—but a lot of them, assuming they are ideas we test, and then some of them end up in the trash, while a smaller portion might actually reach production deployment. And these are the practices of practically every venture capital firm and startup.

Michał Wilk: There’s one saying: “Ideas are cheap,” right? We are capable of generating an infinite number of ideas, but how do we check if they actually bring us value? By doing it as cheaply and quickly as possible.

I remember a story from one VC where a partner was sharing that a student came up with a great idea for a clothing-rental app. He asked, “Do people actually want this?” She didn’t know, but she had a great idea. He said, “Alright, go stick a note on your dorm room door asking if anyone wants to borrow clothes”. It turned out nobody wanted to, and thanks to that, she saved a ton of time that would have gone into launching the app. These are startup practices that large organizations kind of pushed out, simply forgot about, or…

Bartek Śliwa: Or never learned in the first place.

Michał Wilk: Or never learned. However, it is something definitely worth practicing simply to save long months of analysis and even longer months of implementation, only to find out that users don’t actually use the final solution.

Bartek Śliwa: When was that moment, that very first moment when you said to yourself, “Damn, this vibe coding actually works”? You wrote instructions to the guy about what you wanted to receive, and you basically received it. Surely, as a purist, a developer, a tech lead, you immediately thought, “No, this code is awful,” but I assume you slept on it and realized, “Well, it works, we can do something with this”.

Michał Wilk: That’s exactly how it was. You’re reading my mind on this, because…

Bartek Śliwa: I know the feeling too, right.

Michał Wilk: I love clean code and I love when best practices are followed. Everything reusable and beautifully structured.

However, for some time now, I haven’t really been sitting in the code or building solutions strictly as a developer. I’m more involved in the discovery stage, and I noticed that certain things we used to solve through analysis, lists of requirements, or creating interactive Figma prototypes—which is still helpful—changed when models got better. Especially when Sonnet came out, then Opus, and I tested a few solutions and made several attempts; the results were really great.

That was when I said, “Man, you could really do a lot at this Discovery stage—just test it, try it out”. Especially since it doesn’t cost us more than a $20 monthly subscription and a few prompts. Of course, the results aren’t perfect, although again, there are voices claiming they can take vibe coding all the way to production. But for me, that was the moment when I just had an idea and wanted to see what it could look like. I’m not a designer, so I didn’t have a great idea for UX, but one prompt cleared up all my doubts. Obviously, there were plenty of flaws, but if I’m not mistaken, Opus had a huge impact on that process.

Bartek Śliwa: Got it. With every new technology, people from the tech world approach it like a hedgehog. But now, let’s take a step back and imagine we are someone outside the tech world. I’m a business or back-office employee. Is vibe coding for me?

Michał Wilk: I think anyone who can write in Word can vibe code. We have tools built with a single goal: to separate the user from the code as much as possible and only provide the interface. Of course, it’s still technical to some extent, but Lovable, Base44, or other tools really focus on simplifying that whole software engineering wrapper—which is extremely important—down to a minimum, allowing even non-technical users to build solutions.

There’s also the aspect that we live in a time where technology is everywhere. You can’t avoid it.

Bartek Śliwa: I know people who do.

Michał Wilk: Okay, well, you can avoid it. But you can still test it out, and it costs nothing because most of these solutions have free plans where you can try running a single prompt and see what comes out. If it sparks a desire in someone to develop in this area, all the better. But it’s always worth a try. That’s how I’d…

Bartek Śliwa: Okay. Let’s pull on that thread. The thread of testing ideas: what should that process look like, or maybe we don’t need a special process if we are a non-technical employee who has an idea like, “Okay, I could use such and such a tool, I want to try vibe coding it, and then present my initiative higher up to get a budget for implementation”?

Michał Wilk: Okay, the first question I would ask myself—and this won’t be anything groundbreaking, it’s a standard startup question—is: What problem are we solving? What hypothesis are we validating? What do we actually want to solve, and what is the pain point?

Bartek Śliwa: Meaning it’s what you talked about: filtering out plain ideas from actual hypotheses where we want to see the gain.

Michał Wilk: Yes, because again, ideas are cheap, but actual solutions to problems are what we are looking for. What do we want to optimize, and where is the value? We are looking for value—that’s the first thing.

The second thing is validation itself, and I think this is the most important question: Who will see this prototype and when? Because it’s great if the board grants a budget, but it will still be guesswork. Even if we build something, vibe code a nice app, and it looks super pretty with animations—awesome! But so what, if users get it and state they don’t need it, right? The simplest way is to define users, go to them, and test it. Sure, it won’t be a complete solution, it will be an empty shell so to speak, but it’s already something.

And the third thing is: When will they see it? Because if we delay it—especially important in organizations, right—when we put off something until “someday,” it often becomes “never”. So it’s best to go with the prototype, ask for feedback, and either pivot or look for another idea. Definitely don’t be afraid to throw the idea into the trash, because the time spent on it will likely be relatively small compared to pursuing that idea, trying to implement it, and later finding out users don’t want to use it.

Bartek Śliwa: Exactly. How much time did we spend creating our first vibe-coded app? Going back to the case where I am a non-technical employee. I have an idea, and very often people feel overwhelmed by a new concept. Yeah, we want to try something, but learned from experience, we know we’ll only speak Spanish after sitting on Duolingo for at least six months, right? So how does it look with vibe coding? Should we reserve seven weekends to learn it, or can we approach it right off the bat?

Michał Wilk: That’s a good question, because in Silicon Valley I recently heard that a new term emerged: “AI vampire”. These are people so consumed by vibe coding and agent orchestration that they don’t sleep, focusing entirely on firing the right prompt at the right time, granting the right permissions, and so on.

So I definitely don’t encourage that. I think it depends heavily on the person and how much time they can dedicate to the process. However, it’s nice to set rigid boundaries, for example, deciding that by the end of the week I want a working prototype of my idea. It all depends on the idea, but we achieved results in as little as a few hours. In a few hours, we were able to deliver, for instance, a working chatbot connected to a local LLM model and dozens of data-retrieving functions, and that took three hours, for example, right? On the other hand, some solutions simply require more time, and depending on a person’s advancement, it might take longer, but we can do it within a week, so the deadline shouldn’t really be longer to test a single idea. We want to do it quickly.

Bartek Śliwa: Okay. Is there a specific type or category of ideas that fit vibe coding better than others?

Michał Wilk: Definitely all applications with user interfaces—meaning web and mobile apps where we have lots of graphical elements. That is definitely a category we can test really well. Back-office applications and user interfaces are classes where LLMs perform exceptionally well, but not only those.

Simple backend solutions without too many integrations work too, although we can also build integrations this way, though that touches on technical aspects. So if we divide this into business/non-technical people and technical people, non-technical business people will likely lean toward user interfaces. Meanwhile, programmers and technical people will also find something for themselves in vibe coding and can test ideas to improve their code or add funcionalidades.

We have a few interesting examples where an idea sat in the backlog for quarters because it was technically too difficult to implement. It sat in the backlog for a year. Exactly—and in two hours a developer vibe-coded the solution. It had some graphical interface, but was also heavily backend-driven. Afterwards, they concluded the Discovery phase and realized, “Okay, this can actually be done today”. So they focused on building the code proper, according to software engineering standards. And that solution is already in production, despite sitting in the backlog for a year, right? That’s an interesting example where both business and technical aspects were addressed after user confirmation.

Bartek Śliwa: It’s a pity vibe coding can’t be introduced to the Sejm to pull some ideas out of the parliamentary freezer! Just a side thought, maybe our decision-makers will do something about it. Inspired by what you said, I assume some product owners or business owners can take a look at the bottom of their backlogs. Things that would be nice to build, but there was never the time or space, or things that seemed too big, whereas today with available tools, maybe it’s not as heavy or costly, and we can try approaching them.

Michał Wilk: Absolutely. I’d even say business analysts, product owners, and designers are the main ones who can benefit from these tools. Everyone has their own toolkit and specialization, and everyone can bring something valuable to a prototype. A designer will focus on UX, an analyst on data, and a developer on how to deploy it fastest and most comfortably. I think these tools are definitely for them, helping translate what’s in their heads into reality instead of working on assumptions.

Bartek Śliwa: Okay. In your opinion, should C-level executives understand vibe coding?

Michał Wilk: Definitely, yes.

Bartek Śliwa: Why?

Michał Wilk: Definitely yes, because it’s something they can test themselves. I know they probably don’t have time to create full solutions. But then again, I’ve seen projects and teams where it became a language of communication, where we literally talked during meetings while modifying the prototype live according to user feedback.

So wherever C-level is involved in the product to any degree, I believe they should understand vibe coding and, above all, understand where the boundary lies. Meaning it’s not like we build a vibe-coded app in a few hours and release it to production tomorrow, because that doesn’t protect us, doesn’t allow us to scale, and doesn’t respect basic rules like GDPR. Vibe coding stays on the Discovery side. I’ve mentioned this three times already, but it’s worth emphasizing so C-level understands these aren’t finished solutions. When talking about medium-to-large applications, these are definitely not finished solutions.

Bartek Śliwa: Expand on that. How can vibe coding be used as a communication tool between business and IT?

Michał Wilk: Mm-hmm, sure. An example from a project where we collaborated with a client: the product owner in that team started using Lovable specifically to analyze and design final solutions with users. Users didn’t fully know what possibilities existed. They wanted to build a back-office system to improve work, but didn’t know what options they had or how to do it.

So during a one-hour meeting, the Product Owner prepared a few prototypes, showed options, and users tested them using dummy data—which didn’t matter in this case—and picked a direction. It went to the team, the team added their feedback, they tweaked the prototype, and created a feedback loop involving the user right from the start. So it’s not like we build a solution for a month, hand it over, and the user says, “Ah, that’s not what we wanted”. They are involved early on.

Even right from the beginning. Additionally, we can involve other stakeholders and C-level in this process. Look at Klarna: the CEO is non-technical, yet creates such solutions and validates them with users. That’s a real market example showing this process can be used at the C-level too.

Bartek Śliwa: Okay. Where is the line—since you mentioned it—where vibe coding stops being enough and you need to call in a bus full of developers?

Michał Wilk: I’d say very simple things… IT will definitely object if something touches our infrastructure. We definitely don’t want to throw unverified, untested code there.

However, in the project I mentioned earlier, we successfully deployed static marketing forms onto pages without needing to build them through a CMS. A simple form takes 5 minutes to get ready, even slightly complex ones. But that applies to simple applications. For anything medium or complex, I wouldn’t take the risk or push it directly to production under any circumstances, unless the delivery team verifies everything and decides the code is acceptable.

Again, we want to use vibe coding to confirm hypotheses, then hand it over to the team to decide what’s next. If it’s a small solution, maybe they reuse parts of the code; if it’s complex, they might rewrite it. Meanwhile, AI is used at virtually every stage of software development, so on the delivery side, it’s also AI-assisted, just differently. We build skills and create agents to help deliver code, but with significantly more human control compared to vibe coding, where control over the code itself is absent and built entirely on natural language.

Bartek Śliwa: Okay. Can you think of any traps people might fall into by getting lost in vibe coding?

Michał Wilk: Well, you can, because it’s kind of addictive, right? Something that was once a sealed black box no one could open—software development as a whole—was off-limits to business teams who didn’t understand what happened inside. Now they can create something tangible.

Understanding the flip side of the coin is vital: realizing it’s not a finished solution. I would warn against getting overly intoxicated by the technology and possibilities AI offers, thinking that once we make an app, it’s ready. The worst-case scenario is a CEO coming with an app saying, “I want to see this in production tomorrow”. It doesn’t work like that; it won’t scale and won’t be secure.

It still lets you validate things and test hypotheses. So on one hand, the creation process is pleasant and addictive. But on the other hand, keep in mind these are not production-ready solutions you can deploy, at least past a certain level of complexity.

Bartek Śliwa: Is there a universal piece of advice you could give our viewers and listeners if they decide to try vibe coding this coming weekend because of bad weather?

Michał Wilk: Okay, pull your list of ideas out of the closet.

Bartek Śliwa: I thought you were going to say pull your old First Communion computer out of the closet!

Michał Wilk: Well, you could do that too, but take an idea and describe its functionalities and goal. The more context you provide, the better. Don’t just prompt “build me a production-ready, secure, deployment-ready app,” but describe functionalities, create a document, list requirements, and pick any tool. Pick the first vibe coding tool that pops up—like Lovable, Base44, Claude; there are tons of them. Log in, paste your requirements prompt, and try. Nothing more is needed; the entry barrier is literally zero. Personally, I can recommend Base44 and Lovable for quick experimentation. They are great and focused on delivering nice visual results and functional apps.

Bartek Śliwa: To wrap up, a signature question for our show: What inspired you recently?

Michał Wilk: The freshest event was our AI Decision Room that we hosted on Wednesday, and…

Bartek Śliwa: You had to be dragged there by your ears!

Michał Wilk: That was the real inspiring part, right? But seriously, the conversations I had there were great. We met with C-level executives and others to discuss where we are heading. We touched heavily on vibe coding, how to use it in practice, how large organizations can apply it, and how to train employees to use AI tools, which isn’t always obvious. It was inspiring because I saw up close that this problem is tangible. It’s not just something I encounter on my own.

Bartek Śliwa: Yeah, even though you deal with it daily, it really hit home that there’s a real need to understand vibe coding and prototyping. I think the event itself was very interesting and inspiring.

Michał Wilk: Super. Thank you very much.

Bartek Śliwa: Thank you all for listening and watching, and see you in the next episode of the Euvic Talks podcast.