#157 5-Step plan to get started with vibe-coding

One of the designers there was sharing the story of how when they started vibe coding, they had to learn a little bit of coding to better understand how to vibe code. So it was really an interesting effect, right? Vibe coding was their gateway to understanding frontend. It made them more fluent in tech. And that was really interesting for me because many people say that all these technologies are dumping us down and they're de-skilling us and we're going to over rely on technology to do things for us and we don't have to learn things anymore. But he was like the archetype of the opposite example. He learned how to code in order to be better at vibe coding and understand the possibilities, the constraints, the limitations and so on. And so that's a very interesting story for me. And something that I really cherish when it comes to every technological revolution, somehow it forces you to understand tech better. If it solves problem for you, it pushes you into hopefully critical thinking, exercising the systems thinking and increasing your tech fluency. Hello designers and welcome to a new episode of Honest UX Talks. Today we're stepping into the wild and wonderful world of vibe coding. A concept that's really hot right now for good reasons, because it's not just redefining how we build software, but also how we think about creativity, flow and even control as a larger theme in the age of AI. So this episode is going to feel a little bit different, like a field guide for stepping into the future of interface building. Because even if you're a designer, developer, PM, or just a curious, I want to give you a working model, like a mental map, for how to actually use these tools well. Because we're hearing a lot of buzzwords, fuzziness, abstractions and sometimes the best advice is as simple as just start. Just pick any tool and start experimenting, which is a good advice I stand by it, you just have to start. But sometimes you feel intimidated, you don't have time, you don't have direction, you don't have clarity, so maybe that kind of makes you postpone experimenting with these technologies. So I'm here to unblock you. Before we do that, I just want to mention that for more complex needs or complex projects, I still recommend relying on mature conventional technologies. When you need control and you need precision, you need platforms that will let you experiment, but won't fall apart when things get real. So I want to recommend Week Studio. It's a place that offers both creative freedom, but also the important reliability of clean production ready code. And because the layout engine has been around for such a long time, it's very smart, it's optimized, it's flexible, it gives you pixel level control, so you're not going to get weird breakpoints, no janky overrides. They're also bringing AI into the workflow. The AI assistant isn't just decoration. It actually helps you design faster and stay in the flow and through a conversation. So you can literally prompt it with things like make this layout feel more editorial or add scroll-based interactions that feel subtle but premium. So it gives you real editable outputs, not just mock-ups, but working components you can tweak and publish right away. And if you get access to full CSS and DevModes, you're never locked in, you can scale it. You can use it as a high-fidelity playground. It doesn't break when you push it harder. So if you're a designer who wants to vibe code, but also sometimes needs to deliver sometimes something solid, Week Studio is where you get that precision. And now let's get back to vibe coding. So where does this term come from anyway? Because we're hearing it everywhere. It came from André Carpetti, incredible brain intact that I very much admire. Even the name itself points to a simple but very radical shift. What if you could build complex software by just describing the vibe of what you want. So this is completely different than managing complex languages for coding or hundreds of files. It's moving into using AI as a pair programmer or an assistant or your sketchpad, even, and use natural language to go from vision to implementation. I don't think we're aware of how big this shift and transformation is and the larger impact it will have on the way we build tech. But yeah, it's very exciting. And it moves us from being limited by knowledge and skills to, I mean, almost no limitations, if executed properly. And so it really democratizes technology. It democratizes building. It lets us wear whatever hat we need to get our vision from our mind into an actionable, usable artifact. It sounds like magic. Because instead of getting stuck in the weeds, you can now focus on building a real experience. And AI handles the difficult groundwork of code generation debugging. So when it's done, right, it really can feel like magic. But it's not as simple as talk to AI and ship an app. There's a method and there's like a plan that would give you the best results and would also kind of help you get unstuck when you get stuck. Because that's one of the things that I keep hearing from people who are vibe-coding. They have a very good time of vibe-coding until they reach a wall or they get stuck. So yeah, I'm going to walk through a set of principles and strategies that may vibe-coding actually work. And the hope that this will feel like a clear process that encourages you to experiment and fry out the new possibilities. So the first step, and I think the most important one is plan the vibe extensively. Vive-coding is still coding. And so like any other serious build, success depends on what happens before the first line of code. And the most common mistake I see is jumping into generation without doing the conceptual work. So before anything else, sit down with your AI assistant, whether it's an LLM, GPT clause, or something else, and treat it like maybe a co-founder or your technical strategists, but let it help you think through questions like, what are you optimizing for? Is this a quick demo? Is it a research prototype? Will this go at some point to production? What kind of data do you need? What can be mocked? What needs to be real? Which parts of your system can leverage existing libraries or components? Don't reinvent the wheel. Reuse existing libraries whenever you can, right? So do this before you start vibe-coding or prompting the vibe-coding platform. Through this conversation with an LLM, by the end of it, you should have a few core artifacts. Let's call them brainstorming notes that captured essence of the product or whatever solution you're trying to build. Minimal PRD, product requirements document that outlines the purpose, the features, constraints, ideally some rough wireframes. Maybe in Figma, Figma MCP connected to cursor gives you an even tighter feedback loop. That would be amazing, but it could be just a Figma, mock-up, or even some references of products you like from a visual standpoint, UI standpoint. And you also need to ideally have a set of quality guidelines, like code structure, how to handle testing, architectural constraints. So this planning of the vibe is your north star. And it doesn't need to be perfect, but it needs to exist. Otherwise, you're going to go in a very random direction, if you want, because the vibe-coding platform will push you towards what it knows. And then step two, build ugly, test fast. At this stage, when you start, it's not a time for polish. You just want to validate that it works, right? So if the planning phase was about setting the vibe, this is where you test that vibe, sometimes brutally. So you want to get a working prototype that can show you whether your core assumptions are valid. So don't waste time at this point, making it pretty if the underlying idea is broken and will not scale or work. So your mantra here should be, build ugly, test early. Start with essential interactions, and let the AI scaffold the basics, right? So whether you're using tools like Firebase Studio for full stack scaffolding or something like cursor and Figma for tighter control, keep your expectations low and your feedback tight. Because the key to vibe coding is not to get a perfect result from the first prompt. It's to create a conversational feedback loop that can look like this prompt, describe what you want clearly. And then suggestion, let the AI generate code or components, then you review. Don't just accept, but read, understand, think, and then you refine your feedback, adjust it, and then you repeat. So you keep iterating in tight loops. Ideally, you want instruction at a time. So if you feel you want to take something in whatever it has produced at that point, don't give it multiple instructions to change or correct things at the same time, because it might not work as well, or it might break or it's harder to test. If it works, so one instruction at a time, one change at a time. So this is how the flow should happen. Let the AI do the heavy lifting, but steer, steer, steer, and make sure you give it small tasks, small nuggets of vibes, if you want. And this is a very important idea to vibe coding. Small increments, right? Every senior developer knows, but beginners often miss. Small changes are everything. So when you're building with AI, especially inside a life codebase, breaking in tiny increments is your best friend, because it's easier to test, easy to roll back and easy to debug when something will break. And probably things will break, right? And so that's why for any serious project, GitHub is non-negotiable, because you need version control, commit history, and a way to roll back when the AI goes off the rails or gets stuck in a loop or something just doesn't work out. So if you're building something over multiple days, don't just rely on your memory. Don't trust your memory, trust your commits. And also, always provide full context when debugging. If something fails, don't just tell it. It doesn't work. Give AI the error message, share the logs, upload a screenshot, these systems can be brilliant, but only if you speak to them in clarity, right? And then, sustain a flow, but stay sane. This is the part no one talks about. Vive coding can burn you out, if you don't build in some guard rails. There's a temptation to keep prompting endlessly, to tweak and refine without end, to fall into these loops, just one more change, until you forget what you were even building. And the antidote to that is structure. So here's how to sustain the flow without drowning in it. Connect your AI environment to GitHub, so you have rollbacks. Set daily goals, even just one feature per day. There's a win or it's a metric. Zoom out. Don't prompt forever. Step back. Test the build. Validate experience. See how it feels. See if it works. See if it captures your vision and so on. So don't get too stuck in the weeds and use high-fidelity tools when needed, like FEMA MCP is a great bridge between design and AI native development, because it can bring clarity to the UI when things get to abstract. Above all, be patient and be realistic, because these tools are accelerators, but even if we sometimes use the word magic, they're not magic. They will help you go faster, but only if you're clear on where you're going. That's why the first step is, essentially, I'm gonna refer back to it from time to time. After you hopefully arrived somewhere, what you need to do is to own your role, right? Now you're the architect of all of this, and it's exciting. It's empowering. It's a reason to celebrate, but it's also a moment where you should, I think, be honest. AI can't own this experience. It can write tests. It can set up databases. It can scaffold the backend, but it can't understand the problem it's solving for the architecture that's needed. It can protect your product from not being relevant to users. It doesn't understand the business model or your user psychology. So that's your job. You're the architect. You're the strategist. You're the maker. So AI can help you generate all of this, but it doesn't really understand any kind of contradictions or trade-ops, security concerns, long-term mentality. So if you let it go unchecked, it will produce systems that are not very sustainable, and can break easily, and so you really need to be the famous human in the loop. So you can continuously use AI to explain the code back to you, generate internal documentation, translate ideas into working logic, but always, always review. Always understand. Use every prompt as a chance to level up your own fluency. And this is how you get better at tech, which is another opportunity that vibe coding is presenting us with. I was recently at an event in London with Intercom's design team, and one of the designers there was sharing the story of how when they started vibe coding, they had to learn a little bit of coding to better understand how to vibe code. So it was really an interesting effect, right? Vibe coding was their gateway to understanding front end, and it made them more fluent in tech. And that was really interesting for me, because many people say that all these technologies are dumping us down, and they're deskilling us, and we're going to over rely on technology to do things for us, and we don't have to learn things anymore. But he was like the archetype of the opposite example, right? He learned how to code in order to be better at vibe coding and understand the possibilities, the constraints, the limitations, and so on. And so that's a very interesting story for me, and something that I really cherish when it comes to every technological revolution, somehow it forces you to understand tech better. If it solves problem for you, it pushes you into hopefully critical thinking, exercising systems thinking, and increasing your tech fluency. Yeah, so we've been through a plan. Let me just quickly, quickly, quickly re-iterate the steps. Step one, plan the vibe extensively. Go back to that, if it didn't stick. Step two, build ugly, test fast, focus on functionality and making it work. Step three, improve in small increments, keep the overarching clarity in that direction. Step four, sustain the flow. So keep improving, but stay sane. Take breaks, don't overprompt, and don't get stuck in endless prompting. And then step five, own the new role you have, like the architect of this product, okay? So where does this all leave us? So vibe coding is definitely from my perspective, not just the trend, it's definitely a shift in how we relate to software creation. It's fast, it's flexible, and it can be wildly powerful. But it's also demanding in a different way. It really requires us to have a lot of clarity of where we want to get to. Relentless and feedback and reviews and really understanding what's going on, and humble enough to learn and improve your own knowledge and understanding of technology as you operate these assistant systems, right? So if you embrace it with structure, clarity, intent, it really can become one of the most powerful creative tools we've ever had. So that's where the real flow begins. And yeah, I hope everyone feels a little bit more encouraged to start using any tool. And then the last question I think people have in their mind would be, okay, but what tool? Where do I start? Do I start with loveable, with replete, with cursor? Most of these tools, they are a little bit different in what they offer. If you want to just do rapid exploration of what vibe coding can offer and what it can entail, go for v0 from versatile or lovable, ideally. I think lovable is great for exploring broad ideas, getting somewhere quickly. So rapid exploration is great for lovable. If you want full control and deep complexity, I would say try open AI's codecs or cursor. And the most important thing here is just pick one tool, right? You can start with, I like magic patterns. Replet is also great. So just pick one tool, whatever you want. And start planning deeply and understanding first the process and then the products you want to build. So focus more on unpacking the framework and how to get this right. And then apply it again and again, like it's in like any exercise that we do to learn something. You just have to exercise it on different problems, different problem spaces and challenges and so on. So thank you for tuning in. If you have any other questions that you want us to explore in our future episodes, we will be very happy. Send us your podcasts, requirements on UX goodies or anywhere on Instagram. Honest UX docs, unfiesign and start vibe coding and share your results with me. Let's comment on them and let's understand what this technology is as it develops. Thanks for tuning in. Bye, everyone.