Transcription
Today, I'm going to drop some amazing stuff at you. I know it took me some nine months. I think it's nine months since the vibe coding trend started of daily vibe coding, and over 17 projects that I started, didn't finish all of them for me, for my clients, to learn all of the things that I'm going to share with you today in this video. And it's going to solve, if you implement those, and it will take you some time to implement. I'm going to really drop every single golden nugget I know and learned through those nine months. And if you will follow those instructions, I can promise you that your codebase, your design, your vibe coding, the code itself, the files themselves, the security itself of your application will be amazing, and you will be an actual vibe coder who is not just playing with code, but actually can create a real application that you can ship and make money from, or solve real business problems.
If you are a founder and you want to solve some problems in your business for your clients, whatever you are, an agency owner, a consultant, a business owner who wants to solve a problem, this will help you do this. And I really think that the hardest problem we have as vibe coders will be solved by the end of this video in point number five, because I have five points that I want to share with you. And let's not waste time. I want to start telling you the golden nugget.
Okay. So the first thing you want to do is you want to set clear rules and give boundaries and direct tasks. So your rules should give boundaries and direct tasks to the AI. Now, I know a lot of you are using rules and saying like, something like, "Hey, you are the best senior developer with 15 years of experience." This is not what I'm talking about. I'm talking about the fact that every single AI model has a way of reasoning, a way of thinking. And if you understand how they think, you will understand two different things.
The first thing is the context window. And if you don't know what context window is, let me explain real quick. So imagine that you start a conversation, and you start talking with a cursor agent, and you talk and you talk and you talk. Maybe you don't see. Okay, so you talk and you talk and talk, and that's the conversation, right? And that's the context window. It's the amount of information that the AI can save in its memory at every single time, or every given point. So at this point, when you finish the context window, the next thing that will happen is not this, you won't continue the conversation and the memory will grow. What will actually happen is it will start forgetting what you talked about in the meaning. And if you understand this, you understand that the longer it takes you to build a feature, the more confused the AI will become throughout the conversation.
So if you understand this, you will understand that there are ways, and this is why I think like we need to set up rules, because if we have rules that give direct tasks based on the understanding that one context window is finite, right? And every given model has a different context window. For example, Gemini has a much bigger context window, it's around 1 million tokens, which is 750,000 words, versus Claude or GPT that have much less context window. So that's the first thing you need to understand. And if you understand it, let's jump in the screen. You understand that sometimes when you want to, for example, use the AI for brainstorming without writing any code, right? Or for example, Claude, he will be very like, "You are right, you are right, you are right." I hate it when he says "you are right" for everything. "You are absolutely right. I'm so sorry." So I've created a guidelines, the "tell me brainstorming partner," right? So I don't need you to be "you are right." I don't give a if I'm right. I need a brainstorming partner, someone to counter my thought, to share his knowledge. So what we decide in the end is the fruit of wisdom-based conversation and not the need for approval and ego of each of us.
So when I will write something and I'll start talking with him, and I just move this brainstorming partner, I know that I have given him a very specific instruction, and I have systemized. This is how I made those rules and boundaries because I have started breaking down all of the different steps of building a new application, building a feature. First, you need a brainstorming partner, so you can literally start brainstorming what you want to have within the feature, what you are trying to build, and what are the best practices. And then, once we have finalized the initial PRD, the project requirement document, when we know exactly what we are trying to build, I will use this to turn it into a plan. And when I have the plan, and I want him to start executing something, I will make sure that he's 100% sure in the edits or the executions he's about to do. For example, when I'm telling him, "Okay, I want you to edit some file, and I don't want any other function to be destroyed or to be affected, right? I don't want you to start changing all everything. I just have clear instructions. This is what we're going to do. Here are my editing instructions. Pay extra attention while editing. Do not modify anything beyond what required. If edits are needed, make them in very small, focused steps. Don't go and do like complete file change because then you're probably going to destroy the file. Instead, change this line, and then this line, and then this line."
And how do I make sure that when he edits this file, he has the right context in his mind to not just do assumptions about what he's going to edit? "Only change a line of code (LOC) line of code once you are 100% certain it's the correct one." So that will make him read the file to make sure that's the correct one he needs to have in his mind when he's editing the code. So those are boundaries, those are direct tasks. I'll give you another example. So let's say that I have a problem in the design or in something in the backend, right? Like the way it saves information into the database. I will start recording. I'm using WhisperFlow, by the way. I will start recording. "Hey, I have this problem, and I'm trying to solve this and that, and this, and the problem is making me see this on the screen, and I have this error in the terminal, and blah, blah, blah, and blah, blah, blah." And then when I'll finish writing or texting all of this, and it should have been doing it right now, but I don't see it. Anyway, once I will write all the problem, I can ask him to mirror back. Mirror back means you are going to mirror back exactly what are the problems I told you, because I really want to understand that he understood my instructions, because when I'm just blabbing everything that I have in my mind, and I am never checking if he understands, and I think that this is probably, if you take one thing from this, like step in the video, is that the first rule is that the AI model can never know better than you what you are trying to build, because if he knows better than you what you are trying to build, you will have mistakes in the code. But if you know exactly what you are trying to build, and exactly how it's going to work, and exactly what is the feature, what are the functions within the feature, you will be able to understand exactly if he understands the instructions or not. This is why I have this "mirror back." "You're going to mirror back exactly what are the problems I told you. You're telling me you are going to tell me exactly how you're going to solve them, making sure nothing else will be affected." And if I remember the context window from before, then sometimes I know that we are like deep in the conversation, and we talked a lot right now about some feature or something. So I'll actually make him mirror back with data. "First, review the codebase carefully and gather the data you need. Report back with the actual problems you identified based on the codebase, not assumptions." If you are working with AI, you will know that they love assumptions. Especially Claude and Gemini, they do a lot of assumptions when they are writing code. "Mirror back exactly the problems I'm the problems I mentioned so we are aligned and explain precisely how you're planning to solve them, making sure nothing will be affected. And only after I approve your plan, you may implement the changes." This makes sure that you don't just start writing code without me knowing exactly what he's going to write.
So those are some of the rules. I have other rules that are regarding the design or regarding the project architecture, and they are always on. Meaning, before every single build or edit, you will go and check a specific, specific file. And this takes me to the next point in this video, which is there are specific functions and ways of designing things that you want them to always be the same, no matter which feature you are building. So I'll give you an example: authentication. You want that no matter which feature you are building, the way the application knows how to authenticate a user will always be the same. The problem is that if I'll go to the AI and I'll just tell him like, "Hey, let's create this feature and now go and build this for me," he will probably mess up the way he will build the architecture of the authentication. Right? So instead, what I did is in every single project, I'm just using the same code guidelines that I've created, and I will share it with you. You know what? I will just give you all my secrets, okay? For free. In the link in the description, you will find a way to join me and my partners Andrew's free community where you can learn everything about vibe coding, AI automations, vibe marketing, and then just go there, and all of those files will be there. I promise. Okay. So like code guidelines, every single thing I'm doing within the application is here. For example, AI API structured output. Whenever I'm creating an API for whatever AI service, for example, OpenAI, even though I use OpenRouter because it gives you an API to all of the like models, and you don't need to like install Gemini and install Claude and install like OpenAI, you just install OpenRouter, and it just gives you all of them. So like whenever I'm doing it, I'm just asking it to have structured output instead of just manual JSON, because most of the things I am requesting from the application are very strict. I need you to give me this and that and this data points. So I don't want him to randomly one time give it or not. I want consistent output throughout my application. So this is one of my guidelines, right? Or the authentication, or some of the way he is designing things. Those are guidelines that will always be there, and I will always keep on using. I have the same thing for the design guidelines, right? So I have very strict design guidelines that help me solve a lot of the guidelines problems that I have, because if you noticed, sometimes design is very hard to do with AI. And I'll talk about my specific system, and it's not mine. I didn't invent any of this. I just talked with a lot of people, learned how it works. And let's go to point number three, but let's just finish this for a second. It's like you want to have those specific guidelines for every single thing, right? So every time I want him to write prompts, I have context engineering. So like this is a complete guide on how to write prompts. Or every time I want him to follow the architecture, like we saw here in the rules, I will have a specific document that explains the entire project architecture, which we will touch in the video in the next couple of minutes, probably. Or when I want him to do the design, I want him to create token-driven design, which again, we will touch later in the video. So those are rules, step one, and then guidelines, step two.
Then the next thing, which I think is very important, and a lot of vibe coders like miss this, like a lot of people that I'm talking with them in the community and everything, they actually miss this, which is like, when you are trying to build something, right? Like you are trying to build an application, and you don't know how to do it, you trust AI to know how to do it. But honestly, like the level of intelligence that the models of AI have today is not that high to a point where someone with 20 years of actual experience, you write like a prompt, "You are a senior developer with 20 years experience." That doesn't give the AI 20 years of experience of writing code, versus maybe a friend of you, or someone in the network, or someone you don't even know, but you saw on LinkedIn, and you're just like, "Hey man, I saw that you are doing XYZ, and I just have a small question. If you can give me five minutes, that will be amazing. I really want to learn, and I will give you anything I can in return." And if you send it to 100 people, maybe one of them will answer, and you will have your answer. So ask questions. Ask questions about everything. Everything I learned came from like the project architecture. I know the token-driven system. I know the way of the like how authentication works. Everything I learned not just from asking AI, but actually going to people who are CTOs, who are senior developers, sitting with them, inviting them to a beer, to coffee, and asking them questions that I needed answers for so I can learn. So that's like number three, which I think is very important, and a lot of people don't understand. Use your network to validate the AI, to validate your application. You will find that there are so many small mistakes. Like I have built everything, and everything worked perfectly, but then I saw that one of my files was like 1,500 lines of code, and I just made a quick Zoom with a friend, and he's like, "Dude, you have 1,500 lines of code in one file. Like, refactor it." Refactor means break this down and rebuild it in a different way. So refactor it. And then when I refactored it, I was like, "I understand my application so much better," because now suddenly I could see that part of it is like the logic of how this window works. Part of it is like the API calls, part of it is like the Supabase authentication, part of it is how it saved it in the memory. And then suddenly I could see the system, see the process, instead of 1,500 lines of code, which is super overwhelming. So like, for example, one of my rules in the code guidelines is that every single file cannot go over 600 lines of code. And there are people I even heard that do it with 400 lines of code, which is amazing. But for me, 600 is the sweet spot. It works perfectly.
Okay. So now that you understand this, I want to talk about the last two things, and those are extremely important. This really helped me understand like the internal way of vibe coding. And let me tell you what I mean by this, right? So the first thing I want to talk with you about, and it's not the first thing, it's the fourth thing I wanted to talk with you about, is project architecture. And this is very important. Okay, I didn't understand this at all in the beginning. I was like, "Yeah, build the application," and then he started building all of those things, and I'm like, "Okay, I don't understand any of this, but I think it's cool because I can press on the screen and it works." No, because like when you start scaling the application, and you have, for example, a 1,500 lines of code file, maybe when you have one user, which is you testing it in a local server, that will work. But when you have 10 people, 100 people, 10,000 people, that won't work. So like you will find a lot of bugs happening in beta testing or after you launch the application. And you want to make sure that when you build everything, you build it from the foundation in a way that could be scalable. So like, even if you are a business owner, let's be honest, if you're a business owner, you want to make money, right? That's the value exchange of owning a business. So if you build something to solve your own problem, cool, amazing. You saved some time, which gives you more time to make more money for yourself. Could you save more time to other business owners? Probably yes. Do other business owners have the same problem as you? Probably yes. So if that's true, then your application, if you just follow those instructions, could be having a great foundation, a scalable foundation from day one. And yes, nothing is perfect. The first thing that my friend told me when I started vibe coding is like, "Everything in code is a trade-off." When you choose to do X, you remove all of the other options of doing it, and you choose to do it this way. So there is a trade-off every single time. So yeah, there is a lot of trade-off, and I'm sure that I don't know anything, and I have so much to learn. But the two cents I have is that if you already build, build it in a scalable way. And this project architecture, I promise you that if you follow this, you will want to understand your codebase so much better, and it will be much more scalable. And I got this, I learned this from a friend of mine who is a CTO, and he's a fractional CTO. He is like a project architecture guy, and he built this architecture working over 30 years in the industry, seeing thousands of companies, and worked with thousands of developers, and he found that that's the best way of building the architecture.
So the philosophy behind this is that there are two different types of components. There are smart components and there are dumb components. This helps us, this pattern helps us get maximum reusability and automation compatibility, and those are words that AI uses, not me. So let me explain what are smart components. A smart component is a feature. So let me show you in the codebase. I have this in the app. Sorry, in here, I have a folder called components, and then I have a folder called features. In the features, I have all of the features I have within the application. Each feature is a standalone feature. That means that in, for example, the offer bin, I have all of the components, containers, hooks, services, types that I need for this feature. So if tomorrow I want to remove this feature from my application, I can just press delete, and nothing else will be affected in the application. Great architecture, scalable. So the first thing is that a smart component is connected to external data sources, all of the Supabase connections, the APIs, the AI services, versus like dumb components. Those are pure presentational components. A button is a pure presentational component. A dialog, those are pure presentational components. A popup, like those are just components, they don't hold any data from external sources. While all of the components in the feature, for example, let's go on the list, all of those have logic, and they hold stuff from external sources, as well as if you see here, they have dumb components in them. Okay. So first of all, they connect to external sources. They handle business logic and state management. They manage the data fetching, the processing, and the prop injection. They are located in `src/features`. See how I went down with this? This is where they are located. Don't just change the the architecture of the project every time you write code. Each feature will include all its types, hooks, services, components, and templates. Inside a feature, we have containers, and we have components. A container holds smart components, and components hold dumb components. So that's the pyramid hierarchy like this. So at the top, we have containers. Those are the actual pages we see. This is if we have, for example, a window. Let me give you an example. Just a second.
So I'm just logging into the application. This is what we're building right now. So like when you see this, for example, or let's go here and I'll create a new brand guidelines. This is our vibe application, or vibe. We don't have the full name yet, but this will help business owners, and if you're one, this will be interesting for you. This will help you build your complete business from the button, all of the marketing stuff. So imagine for a moment that you have just a way to describe what you're offering, and it will build your complete offer doc, all of your brand guidelines with one click. Choose the offer, generate brand directions. Boom, you have brand guidelines, right? Then you will be able to take the brand guidelines and the offer and generate complete funnels, complete marketing campaigns. This is what we are building. It's a full vibe marketing platform. Again, if you want to learn more and you want to be part of the beta of this application, all you need to do, very simple, is stop for a second this video, come back because I have amazing golden nuggets to give you. Go to the description and just press on the community. Go there. You will be able to become one of our beta testers, which is like giving you a free way to build your business. Sounds good? Just go down. Okay.
So anyway, this window that you see right now, that's the wizard itself. This is a container. In this container, we have four different steps. So like I told you before, that I have this file with 1,500 lines of code, that was not the brand guidelines, the offer builder, but like all of the steps of the offer were in this one file. And then I refactored it. So now, for example, if I'll go here and I'll go to this actual feature branding, and I'll go to the containers, you just saw the branding call pirate wizard container. This is what you literally saw right now, right? 357 lines of code. But we have so much logic in there. We have all of the steps. So I have components, wizard steps, and those are all of the steps. So if, for example, in the future, I decide, you know what, I want to add another step. I don't need to change all of the other steps, our file, and everything. I just create a new file and integrate this here with all the designer already have somewhere here in their logic case for I want whatever final guidelines, final review guidelines. Okay. So that's being said, this becomes very easy to do with this architecture. And then all of the services, so like branding API, the branding service, the brand asset generator, so all of the different services that I have, all of the different hooks that I have, all of the different types, like what are the branding types, what is like the different input types from the database that I can use, or the expert type that I will have in the output are here. So everything lives within this one feature. This is very important. I want you to understand why, because this project architecture will help you build a very strong application. So we have smart components, dumb components, then we have mutual files. If we want to be able to really delete a feature without affecting anything else, we can't have features cross-referencing each other, because if the branding feature will get stuff from the offer, and I'm not saying get from the database, but literally a component from the offer, and I just deleted the offer folder, I won't have this component. So instead, everything that is mutual sits within the mutual library, which is in the library. All of the actions, the hooks, the schemas, the services, the types, the utilities. For example, content cleaner. When you saw this, that didn't came this beautiful written. It came as JSON, and I needed to clean this, but I need to clean not just this text. I need to clean, for example, in the offers, when you get a full offer. All of this information of your offer, which again, you can become a beta tester, just check the link in the description, you will be able to clean if you're just using the content cleaner. So that's like a utility that is using that are is used in many files. So this is why I have this mutual file thing. So that's like the project architecture. And again, I will give you this. I can't believe I'm actually doing this. This took me so much time to understand, but go to the community, and it will be there. Okay. I will literally give all of this in the classroom, in our school community for free. Absolutely free. So you can build your applications. I don't want to charge anything for this. Like, I just want to share my knowledge. I'm a teacher. I love doing this. So like, for free.
Anyway, so the last point I want to touch in this video is the design. And I know that most of you waited for this point because it's like it's going to blow your mind. It blew my mind when I understood this, and it's so deep important. Let me, let me draw this. Okay. So imagine for a moment that in your application, you have a button, and then you have a container, just like you saw here, a card. This is a card, and you have a card. Now, if you just let AI every single time write a different feature, different code on a different conversation, you have zero context of how you want your card to look like. Maybe it knows the colors of the app. Yeah, for sure. But what about the spacing, the gaps, the shadows, the animations? You want everything to be consistent, and you don't want to tell it again and again and again and again how to do it. So here is the system. Let's go back. No, let's go down. Okay. So it is part of an old system, very old one, that I think it has six different layers, like there are tokens, then molecules, then like token, atoms, molecules, and so on and so forth. I didn't really care about like dogmatic way of doing stuff. I'm like, taking this, figure out what I need, and implement this in my project. So the way it works is like there are small building blocks that we call tokens. They are the smallest building blocks in your application, and there are many different tokens. Let me show you the tokens. So there are animation tokens, there are breakpoint tokens, there are colors, there are shadows, spacing, and typography. Essentially, all of the different tokens that when combined build all of the different components and user interface elements that you will need. For example, the colors are all of the different colors that you need within your application. Define them by the hash or the RGB. And then imagine for a moment that we take those tokens, and then we use those tokens to create. I don't have enough space, and I write pretty bad, man. My handwriting is so much better. Like I, I'm. And this is not me. Those are my kids, and I love it. So cute. Look, my son did a heart for me. Okay. Anyway, so like utility class, and utility classes are essentially an element of the CSS file, which is all the design that you have, global design, and they define every single element within your application. So for example, we have the vibe green, or we have the spacing. And again, those are not too. Those are the like, we took the tokens, we implement the tokens, and we gave each token a name. So space-two is six pixels, space-xs is 8 pixels. But imagine for a moment that you want to do a card. A card is not just a space. It has a specific shadow. It has a specific spacing. It has specific colors. So when you take all of those different elements and you combine them together. So you have, for example, that would be the man, this is so slow writing, that would be color, that would be space. No, that will be space. And when you combine them together, you get a utility class. And a utility class looks like this. That's a container extra small. That's a container for pop-ups. That's the margin within the different cards and stuff. Those are the padding, the margins, the gaps, the height, the width, the spaces, the animations, the borders, like all of those, the the typography utilities, like unique vibe utilities. All of those became utilities. And when I have those utilities, just like if I'm going back to the beginning of the video, what I did was I created a token-driven way of working with the application. Now, why those utilities are important is because imagine for a moment that now I want to change all of the buttons in my application. I am rebranding. Hey, I have 100,000 users, and I want to rebrand. Congratulations if you reach that point. Now, all I need to do is literally comment. Okay, so I want to change the vibe working text from vibe gray to vibe gray 500. So every time in the application that everywhere it used vibe working text, now we changed it from 900 to 500. Okay. And then the highlight, when I'm literally using AI to write code, I just gave him the token-driven, which is always on, and it's just short instructions of there is a source of truth. Those are the tokens. There is a mapping, this is the tokens, that's the token to CSS. So every time there is a build, every time I run the application, or I'm building this online on a service that hosts the application, it's literally going to take the tokens and then it's going to map the tokens into the CSS file. So if I want to change a token later on, I can do it, and it will change the entire application. If I just decide, okay, I don't like our vibe green color anymore. I want to have a different vibe green color, I can just change it in the tokens, and boom, the entire application will change. I didn't need to go to every single page and change something. That's the first huge highlight for me. The second thing is that now, because I told him that we don't use emojis, we use icons. These are the icons libraries. I know that he will never use emojis. There will always be icons from the right libraries. And then utility first. Typography, surface, spacing, containers, layout, effects, icon. So every time we build something, he literally go to the global CSS, he reads the file, find what he needs. It doesn't really read, you just grab, search something and grab it. So like he finds that he's building whatever like a popup, and we have a specific way of of building a popup, right? Then he will come here and literally use those utility classes to build the design of the page. So all of the design of my page is consistent. I don't really need to go and start working on the design again and again and again, getting so pissed because AI cannot really understand my intent when I'm telling him like, "This, the vision is not in the right place, and the button should be on the right side." No, there is ways, there is consistent ways of doing things within the application, right? So like for me, it's first of all, I would make sure that he knows exactly what I want to do, and when he knows, and he mirrors back exactly this, I will tell you are 100% sure. And of course, use the token-driven system, and boom, I have a complete system to give me consistent results based on the actual application I'm trying to build.
So those from my perspective were the five things that like are very important to understand. And again, if you want to grab all of my code guidelines, my project architecture, just go to the free community. And anyway, if you want to learn more, like just go there. And I don't have a next video. Probably in the next video, I will push people towards this video. So like, you can check my channel if you like it, follow, and just thank you for being here. Appreciate you. Have a great day ahead. Ciao.