How To Build Your First App with AI - Lesson 5

Let AI Build Your First App (No Experience Needed)📅 2025-12-03

Watch on YouTube ↗

Transcript

[00:00] Welcome back to this series where I'm showing you how to build out an entire app with just human language. This is episode 5 and in this episode, we're going to be able to take our application here and make sure we clean it up and make it look absolutely beautiful for the back end. Therefore, I went ahead and added a little extra step here cuz I realized in order for me to truly show you how to build out a real application, we're going to need one last little step here, which I'm going to call prep. And the purpose of this step is going to be so we can cleaner code, have a wiring structure for how we're going to connect our data paths. This will make more sense as we jump in. There's going to be a bunch of other suggestions I give you

[00:30] so you don't get stuck in rabbit holes during the front-end phase. But essentially, by the end of this video, you should have an application that is ready to go for the next step. And the next step will be the sign up, the database, the monetization, all of that. Let's jump in. Welcome back. This video, we're going over prepping. Okay, this is like we're chefs in a kitchen and we need to prep for all the customers to come into our restaurant. If this is the first video you're ever seeing from me or you just found yourself on my channel, realize that you are in episode 5 of a very long series here. So, if you want full context, look at episode one description down below. Check out the

[01:01] playlist. In order for me to effectively show you how to prep your application, we're going to go over three fundamental blocks. First block, backend is king. And I'll explain what this means, but TLDDR, don't get stuck in rabbit holes when it comes to how you're storing data in the front end. You'll realize that the AI models aren't as smart as you think. Second, wiring time. How do we create the right paths? So, when we have a user, we know how to associate data to the user. Make it simple, guys. Who has the right email? Do you have the right email? this user has the right email. Nice. Third will be my method of cleaning up and certain prompts you

[01:31] should use to clean up your application. There's going to be code in your application that is what we like to call dead code. And this code occurs because of the fact that when you build out very large applications very fast. You find a lot of code that's not used on accident by the AI model and it doesn't even realize it's not using it. And then finally, some last little nice tips when it comes to making sure we launch fast and getting that backend ready to go. All right, step number one here. Back in is king. What do we mean? Little rabbit. It's time. So, I found myself while working in the front end, the AI model likes to quote unquote overoptimize things. So, what would occur is that I

[02:02] would find a bug and we'll jump over to the IDE pretty soon here. Don't worry, we'll jump over to curs and I'll show you. I would find a bug. I would, you know, go through my troubleshooting steps which I've shown on this channel, how to solve bugs. If you don't know what I'm talking about, check me out on this channel. Click my name and literally just look at the video for erroring. But the idea is that because of the fact that if we don't have a backend yet, what would occur is that the AI model is working within the boundaries that it exists in. Therefore, if it knows it can't use the back end as a way to store the data, it's going to really go down rabbit holes that's going to be making bad code, but it thinks

[02:32] it's making good code because it's solving the bug in the front end. Let me just make this simpler. Essentially, when you're working on your application here, if you're running into bugs and you solve the bug and then for some reason another bug just seems to appear or it doesn't seem that reliable, yeah, it's time to move on. What's occurring here and what I found when using these AI models is that they're really smart. Of course they are, but they're limited by the environment that we provide them. So when approaching just like front-end development with no backend, in order to store data in a browser, there is something called local storage. But

[03:02] there's also a more effective way to store data in a browser called index DB. Index.db can store larger data files, eg the thumbnail. And if anything I'm saying right now, you're really confused and you're like, "Oh no, he's speaking alien language again." Just go to a chat. What is the difference between local storage and index db or just db? You hit enter here. and what does it generate? But the idea is that local storage is going to be more for simple values. For example, project 2. This is a string. This is text. Yeah, in theory, we could jump and put this in index.db,

[03:34] but we might as well just store in local storage. Now, a really good method that big software companies use. Let me real quickly turn off this little cursor beep again. I always forget to turn this off for videos, y'all. But the completion sound I absolutely love when using cursor AI. Back to what I was saying, though. The idea is to make a powerful storage system so that your UI reflects extremely fast when you hit reload here. You want to go down a very specific path. TLDDR on local storage real quick. Think of it like text index.db could be text and bigger things like image files. What is this path, Corbin? Let me show you. A lot of this will make more sense

[04:04] to y'all as we keep going down the back end as well, but just taking this knowledge real quick. So, we got local storage here. And with local storage, think of it like, hey, you got your user's email. Store that in the browser to reflect the data. local storage can then be backed by index.db. index.db. If you want to actually see fundamentally what this is, let me show you. If I come over to my application here and I click my nice little Google Chrome console log and I go to application, look at that y'all. Right here is our storage found on our

[04:35] browser. Also cookies. Where's the cookies, Corbin? This is where the cookies are. Index.db right there. This is quite literally the storage on the browser. It's kind of cool to see it visually because now you're like, "Oh, so this isn't just like alien stuff. It's actually physically there. And your console log can print out what's being stored in your index.db and also your local storage, what's being stored there as well." Why is there this weird thing where it's like, why isn't this just local? Like, why aren't these combined? What's in current cure, Corbin? is because of the fact that when loading

[05:06] data, if you ever load data on anything, like go to YouTube and just like hard refresh, you'll notice is like it'll do like a little gradient loading UI where it's like a gray box, but there's nothing there, like no thumbnail, no title. That's because like that's the initial click, like the first milliseconds of like there's a page. The next thing that's going to be loaded into the page, the fastest is going to be from local storage. We're talking milliseconds here. Load the local storage, show them the title, show them the metadata of the views, whatever it is. The next thing that takes a couple more milliseconds is going to be the index.db. Seconds matter in development

[05:38] because if you don't do this kind of logic and you build an application, you could have pages that just look broken when you're loading them because of the fact that you're not loading the data correctly or it just looks horrible because if I reload this, my hay bells go to some dead value like null or zero when in reality we should be loading like this. We go local storage cuz it's super fast. It's like the cheetah. We go to index.b BB because it's a little slower than the cheetah. And then finally, we get the last leg here, which is going to be how you store it in your actual backend. There's other ways to go about this. There's other ways to

[06:09] structure this, but I'm showing you how I structure it. The back end is going to be the ultimate fail safe, and that's why I said backend is key. Now, what can incur here if you don't have a backend and you're going down rabbit holes like we saw with that little rabbit clock, Z rabbit clock? Uh, what can occur here is because of the fact that we're the AI model is limited. The AI model's over here and you're coding with the AI model. You're vibing with it. We're absolutely vibing. Let's go get a burger together. In and out. I love it. You're vibing with it. What's going to incur here is that the AI model is going to be like, uh, we're running into a bug because we can only use these two tools.

[06:40] But the user keeps being persistent. The user keeps telling me to fix the bug. Okay, I'll fix it. I'll fix it. And then the AI model will do a practice that is actually very negative for your software just to fix the bug. So what you need to understand and the whole point I went down this little tangent about data and how it's being stored in the front end is one you just need to understand fundamentally how this even works when you're building out applications but two you need to understand fundamentally that yes when you're building here and you don't have a backend you are going to run into errors that in theory you could fix but when you fix it you're

[07:11] putting on a band-aid on a broken arm let's do it the correct way let's put a cast on it and build the back end so backend is king and you just learned some really cool architecture when it comes to data so don't find yourself overoptimizing okay we'll deal with the optim optimization once we connect our back end. So, what is the next step I want to show in this video is that is going to be wiring time. And we put the yuza in all these little cheese blocks. Okay, I like mozzarella cheese sting the little string ones from Costco. You can get bulk. Amazing. I love snacking on those. I got cheese here. Cheese just represents data. What's an example of a data point, Corbin? Your email. But the idea is how do we create data paths that

[07:42] are effective? And I like doing this in this phase because this phase we still haven't connected to the back end, but we have all the context we need to even create said paths. So, let me show you some paths here and then we're going to create some together. Oh, it is absolutely pouring outside, y'all. I don't know where y'all live, but it's raining like crazy in California right now. Whoa, that is some intense rain. Okay, new chats. First off, let me show you some paths. All right, so we're going to come over here and first off, what I want you to create is I want you to create a folder. If you're watching my other videos up to this point, you probably already created this folder, but just do it for me now. This is going

[08:13] to be your DAX folder. And the whole purpose of your DAX folder is going to be to store what we call MD files. And MD files are like your readme file where it's not actually read in the application when you're sending it to a user. Rather, it's for the developer reference or the vibe coders reference. So you're going to create a folder here called DAX. And I already went to another video showing you how to solve any error using this troubleshoot folder. So go and find that. But the one that we care about today is going to be DAX. And then inside that folder, we're going to call it architecture. And I've already created one. This one's not fully up to date to be honest with you cuz I need to update it still. But this

[08:43] is an example of us setting up the wiring phase. And don't worry, we're going to do some props together so we can figure it out. But I want you to see this visually. What's incurring here? So, let's just go to one of these paths. First thing I want you to understand, what's occurring here is this users and UID. Users in software is what we call a global doc. What a global doc is is a doc that is at the top level of that little Google sheet, Excel sheet. Remember I was explaining it like super simple. The idea is that let's when you see our little database, you'll see it pretty soon here y'all. I think it's going to be the next episode that I get

[09:13] into authentication, but we're going to have like a database like this. And what's going to occur here is that all your global docs are going to be right here. And then you're going to be able to click into each one and then each one's going to have its own path. So to make this a little bit more clear because right now that's just lines and you're like Corbin, they're just lines. I know. Okay, let me just make it clear. An example of a global doc is users. So users and then what's the next thing that occurs here, Corbin? It would be users and then what you saw there was UID. UID is a unique identifier for each user. Think of it like their email, right? No one can, no two people can

[09:44] have the same email. But what's going to happen here is that if you have a thousand users, each one's going to have its own UID. So we're going to be creating a whole collection here of UIDs of each user. So in theory, you're seeing all these UIDs. That is 1 2 3 4 five users, which then go down further into a further data path. What's a further data path, Corbin? Users UID settings, preferences. You see how this is going down chronologically. Uh what's an example of a another global doc? Um you know we could do something along the lines of analytics or something along

[10:15] the lines of uh queuing or processing uh where basically we ran uh some type of global doc that shows all processing that's occurred on the platform and we store each one as its own doc. Point being here and maybe a better one that's more easy to understand is like analytics. So some of y'all might be thinking Corbin oh my gosh I spelled analytics wrong. I'm dumb. You might be thinking uh Corbin what about G4? Can G4 do your analytics? Yes 100%. The reason we do a global doc of analytics though is that you're going to have very custom things within your software that you're not only going to be able to track within G4 and we'll set that up but also be able to track within a doc system

[10:47] like this. What is a very custom thing Corbin? Let me show you what is unique to your platform. I don't know. But I know one thing that's unique to my platform that isn't a simple, hey Google, this is a conversion event. The user just bought a subscription plan. That's like a standardized thing of software. That's not unique. What's unique in my platform maybe for an example is every single time a user puts in a prompt and sends a prompt in edit mode, I can track that data. Every time a user goes into ask mode and sends a prompt, I can track that data. Why does that matter? Well, that matters because think about it. I have 100,000 users and I'm tracking that data at scale. And I

[11:18] realized through my analysis that hey, it seems like on average users are 70% more likely to use the edit tab over the ask tab. Or maybe I realize, wow, 90% of the users only really use the edit tab. They never even use the axe tab. So what's the next piece of logic that I gather from that or the next actionable thing? If I realize that over 100,000 users are only using the edit tab and not the ask tab, that tells me two things. The first thing it possibly tells me is that we need to upgrade the AST tab. It needs to be better cuz obviously the user doesn't really like

[11:49] to use it because it's trash. Or alternatively, it's pretty good, but no one just likes to use it in the workflow. it's not that important. So then I can make my next software decision as an executive to be like, do we upgrade the AS tab or do we maybe provide it in a different way, right? That's just one example. It's a specific example, but by giving you a specific example, now you can look at your platform and think, oh, this feature, I probably want to custom track that. It's pretty cool and it's honestly one of the cooler things in software development, the ability to track data that's only custom to your software. So now that you have a surface level idea of why wiring

[12:20] is important, let's come back to the schema here and just show one and then we're going to do a prompt together to create your schema. So this one's obvious. This one's going to make everyone be like, if you didn't understand what I was saying up to this point, you're going to be like, "Oh, now I get it." So look at this schema. And honestly, I'm probably might change this, but the point is, let me just show you how to do this. Users, UID, settings, preferences. What's incurring here? Well, look at this. email string plan free creator agency work roll YouTuber editor designer where is this coming from h go to my settings oh that's where it's coming from user email

[12:52] plan YouTuber editor designer you see it now I mean if that didn't make it click in your head let me do it again so if I'm coming back over to my schema here let's just scroll down here oh let's do another example default download format PNG JPEG JPEG quality number outfit string cowboy headphones astro where's this coming from Corbin Hm. Lead outfit classic afterparty. Nice. Oh, look at that. JPEG PNG quality number 44%. You see what I'm doing here? I'm showing you it like this because now you can understand all we're doing here. We're

[13:22] essentially grabbing the data. Any type of data that is a variable data, not a fixed data. What do I mean by that? Pick your llama fit. No matter if there's 100,000 users, 10,000 users, or just one user, me, myself, and I, that's always going to say pick your llama fit. I don't even need to care about that cuz I've hardcoded that. Download settings though. Coming over to file type JPEG and PNG. This is variable. The user can change between JPEG and PNG. And just for context, what does this even mean, Corbin? It's their default export. So if you like exporting your thumbnails in JPEG, you'll choose that. If you like exporting your thumbnails in PNG, you'll choose that. So that if you make a 100

[13:53] projects, every time you hit export, it'll be auto selected to PNG. This is variable. So then, how do you mentally look through this? How do you know what to do when building your wiring system and your data structures? Anything that is variable on your platform is going to require a data point. What best describes your work? YouTuber. Oh, the user can interact with it. Data point. Coming in over here. Oh, the user can change the title of their studio. Data point. The user sees a live feed of how many megabytes out of 100 gigabytes on the agency plan they have. Data point. The user can change their project name. Data point. The user can move this to a

[14:24] new folder. Data point. Any action, y'all. You see how simple this really is? I don't want you to over complicate this. It really is as simple as if it can be changed, then yeah, you're going to need a data point within the back end to track it. The whole purpose of local storage and index.b DB and then your backend like why isn't it just Corbin? Why don't we just load the backend and have no local storage or no index DB? The reason we don't create an application where we just frontload the backend data is one because the user experience would be absolute trash because when you reload the page it

[14:54] would take a couple seconds to show the data and two the whole UI would just be fundamentally broken because anytime you loaded new data to come in there is that latency that incurs with the backend the cloud the server in Nebraska as I said earlier communicating with the user's laptop that's in UK England like Germany France any of that right like that is fundamentally why you need to have that nice little protection layer of index of local storage. This is also another reason why a lot of experienced devs

[15:26] trash talk vibe coders because of that nuance when it comes to data. If you don't create an application with that kind of structuring your application is just going to fundamentally break. All right, let's keep going here. So now that you understand at a simple level why we create data pass like this and last thing I really want to harp here is that notice that everything after UID is going to be the exact same for every single user. So settings and preferences scroll down here UID achievements that path is all the same. Also let me show you y'all how to make an MD file look good cuz this looks scary right now. I

[15:57] know on Mac it's command shiftV. On Windows it's I don't know. Just ask an AI chat. But look at this. It looks a lot better now. Command shift V. And you can kind of see this look all all beautiful and clean UID achievements. So UID billing current subscription everything after UID will be the exact same for all 100,000 users, all a million users, all 10 million users. And the reason we can get away with that is because of the fact of the UID. No single user will have the exact same UID. Therefore, we have no issue or no worry about conflict that can occur. If for example we did something along the lines of users one little thing right

[16:29] here was like users user one billing and then the next user we did users user one billing there would be conflict because the fact that they're both going down the same path. I hope that makes sense. Let me know if that didn't in the comments. All right, enough talking. How do we create this? So let's go and create one together. Let me go ahead and create a separate branch for this y'all. Right now I'm in Maine and that's not good. So let me create a separate branch over this real quick. All right, so I want to create a new branch here called dummy. If you want to know how to create a new branch, just literally ask the AI model, hey, create a new branch and call it XYZ. Here's what we're going to do. Let's create our nice little prompt that

[17:01] you can use so you can create your own version of this. First thing you want to identify cuz I want to make this kind of a universal tutorial is what is going to be your back end. Is your back end superbase? Is your backend for sale? I don't know what your back end is. So identify your backend and go to specifically ask mode here. So here is the prompt we'll use. My back end will be Firebase and GCP. Knowing this, can we make the entire fire store schema? Schema, schema, schema. way you would think about schema there is like the little trees like the little tree branches you saw I go back to editor here fire store schema scroll up here like this stuff that's what we call schema agents you might be asking yourself why do we call it schema why do

[17:31] we call vanilla ice cream vanilla ice cream knowing this uh you can make the fire store schema for all the data points on my platform and put it in my architecture folder that I told you to make earlier as MD I need this to go down the path users UID this is important make sure to add this as this is going to be the most fundamental part of any path any questions before we begin now I am going to actually switch this up to plan mode. We can start a little early here. Son is pretty good about asking me questions before diving in too deep. Some other models are a little too like I just want to get going. Just chill out. So, let's see if there's any questions first. All right, here we go. And scope replace or extend.

[18:02] Replace the existing. So, this is like the one I have currently with a new comprehensive version. Keep the existing doc and create a new separate file. So, for me, I'm just going to create I'm just going to keep it. So, we'll do this. And let's go to question two here. Include collection for studio invitations. Da da da. Skip team feature for now. This is what we'll do. We don't need that for now. Add placeholder section for future team features. Actually, y'all, we're going to keep this. Um, this has to go with a older lesson I gave previous in the series where you kind of want to build out this architecture and have it ready. So, legacy users don't have to be migrated.

[18:34] Additional data points which should be included. Cookie, consent, preferences, currently local storage only, help centers, bookmark and favorites, user activity, logs, elementary, all above. So, this is all discretion, right? I mean, in theory, if you just want to be extra safe, you could say all of above. So we'll just say that for now. And then finally, documentation style. Keep the current detail style, TypeScript types, security rules, and field counts. Typically, you want to opt for more detail. More detail is always going to be better. And what's really cool here is it says add Firebase Storage Pass alongside the Fire Store schema. So let me explain this real quick. First off, when I answered my questions, but let me explain the difference between Firebase

[19:05] Storage and Fire Store. If you're using a different backend, then simply put in your backend's name and say, what is the equivalent in AI chat? Here is a situation, y'all. Fire store. What do we store in fire store? I almost want you to think of fire store. This might not be the best comparison to be honest with you, but it's almost like you know local storage like textbased stuff. What best describes you? Fire store text. It just says editor not that big. The storage is not massive. What do we put in firebase storage then? Not fire store. I know it sounds very familiar so it can be kind of confusing. It'll make more sense once we create our little Firebase project together. Here's what you put in the

[19:35] Firebase storage. Bigger stuff, right? So what's a gradea example for my platform? The thumbnail for sure. What's a grade a example for the other software I run which is bumpups.com which is a video analysis software AI model the video right so if a user uploads a local video which is like 10 gigs we need to store that somehow and we're definitely not storing that in the fire store we're storing that in firebase storage fire store and firebased storage it uses similar paths but firebased storage is optimized to handle larger files so what does that mean for you can the user

[20:07] upload PDFs yes storage can the user upload videos yes storage can the user Upload images. Yes, storage. That's the file process you need to go down. Everything looks good here, though. Let's go ahead and hit enter on Z plan. So, we're going to create this plan here. What's great about MD files is that you don't have to worry if they get a little crazy because end of the day, you can delete them. This is not like actual code. This is purely for the developer and the AI agent to reference for future development. And fundamentally, this step is very important for you to get done right the first time because the fact that you'd rather build your backend on the correct quote unquote schema, as we learned,

[20:39] than have incorrect data passed. Now, this is not fundamentally groundbreaking in the sense of if you don't do this correct, everything's done. In reality, when I implement this and integrate this for my software here, there's going to be some hiccups. There's going to be some data paths we change and then when I change them, I'll explain why I changed them to you. But for now, it's nice having an MD file like this because you can kind of reference it when you do things one by one. That is also why in this series I broke it down to first, let's get a user to sign up. Let's just build that out first. Let's get it perfect and then proceed from there. So, when building plans like this, you want to use a higher level model like 4.5,

[21:11] uh, GBT 5.1. Um, I've been noticing really bad code outputs for GBT 5.1 like by itself. So, you almost want to use like GBT 5.1 Codeex or Codex High. You'll be better off that way. And then, by the time you watch this video, those aren't the models. Just go with whatever the most powerful model is at the time. For the builder though, I've been noticing really good work with Composer. So, I'm going hit build here. Composer is amazing at being a good reasoning model, but executing tasks extremely fast. So, here we go. Once it is done, we can go ahead and come over to editor here. And let's check it out. So, we got this one right here. It's green, so that

[21:41] means it's brand new. And then remember that little trick I told you. Command shift V. Command shift V. Oh my gosh, it's absolutely beautiful. Now, so what this will do is it's pretty good, y'all. I would say this is going to get you 90% of the way there where you're going to have obviously your top fold here or your top line of users UID and then all the relevant subcategories within that or collections. What you'll notice though is I want you to actually review what's being said here and make sure that whatever it's adding you actually want. So first step how do we review this to make sure this is good such as

[22:11] users UID settings and preferences. To review all you simply do is open up your software in another application and I would go to settings and the first thing I would do is be like okay I noticed that login email this is a variable this is the actual user's email. Let me come back to this schema that we just created. Do we have that? Let's do this side by side, y'all. There we go. Side by side. If actually, if y'all are wondering how I did that, let me show you real quick. So, if you want to do side by side like I'm about to show you right now, which would be extremely helpful, let me delete this real quick. You're just going to simply come up here to Z panels right here. And then it's

[22:41] going to be like, oh, there's too much code going on. So, you're going to have your preview file here. And then this one is where we're going to put our other file here, which was our local browser, which actually went away. So, let me grab that real quick. We got to kind of just open it like that, I guess, y'all. So, do like this. and essentially grab the other tab, put it over here, and you can kind of walk through it, right? So, if I come down here, this is tablet mode, so obviously the UI looks a little bit different, but you'll notice I go to account, I go to member credentials here. I'm like, okay, where is this? Oh, yeah, this is the settings. Oh, this is the preferences. I scroll down here. Oh, it does look like it's storing it. So, emails here. Email. Oh

[23:13] gosh, y'all. Stay as command V. Come on. Email. Nice. Plan. Free creator agency. Agency plan. Now, one thing you want to learn real quick as you're noticing something. You're like Corbin, it's storing it as plan here, but in the UI, it's reflected as agency plan. This is very normal in front-end development. We will store data points like that as agency just all lowercase agency, but when reflecting it to the user, that kind of looks nasty. So, we'll literally just write in the front-end code. If you see the data point agency, reflect to the UI agency plan. Very common practice because I'm not going to store that data

[23:43] point as literally agency plan. I'm just going to store it as agency because all that's being read in the back end will be agency and in the front end it'll read it as agency. This is just let's make it look clean. That's why if I did creator here, this would say creator plan here. Keep scrolling down. What would best describe your work? Is this being used? Nice. Work role. It is being used. YouTuber YouTuber editor. Editor. You see the process here. Go through this process like a razor. Look at everything. Make sure it's all connected. Two things will incur. The first thing will incur is that you know you go to brand here. Some stuff will either not be there and if it's not

[24:14] there then you simply just screenshot put it into an AI chat and be like, "Hey, you missed this in the schema and then it would add it to the schema here." Or alternatively, it will add stuff that isn't even relevant. For example, brand logo. What are you talking about? That's not relevant. Where's the brand logo being used, Corbin? Nowhere. So why is it there? Delete it. AI is amazing. AI is beautiful. AI will get you 90% the way there. But yes, especially in this part of the phase, do look at this and go through it with a fine razor and find little things like this so you don't

[24:44] have it in your backend code and it's dead code. Sound good? All right, here is what's next because the fact now that you know how to wire the app and you made that MD file, it's cleanup time. Here is a couple things I noticed when coding with multiparallel agents and having all that code come out incurred. That was bad. The first thing was the logs. Those console logs got excessive. If I came back over here, what would occur is that anything I clicked, anything I pressed, any action I would run, it would just go crazy and it would give me like hundreds upon hundreds upon hundreds of logs like chill out. What I

[25:15] suggest you to do is do what I did. I granularized the logs. And what I mean by that is if I come up here, I go to the config, I go to feature flags, I use a thing where I'm doing debug flags. So what does this actually mean and how can you use it? What this means is that every single console log has its own line of code in your file. So let's just actually show a console log. So you know, let me see if I can find one. Oh yeah, it's right there, right? Console right here. So console, anytime you command F console or control F console to find it, you are going to see this

[25:47] incur in Google Chrome, right? So it's like the console log, console air, whatever. Some console logs you don't even write and it'll just happen naturally where it just breaks the app. Point being, the terminology you use is you're going to open up a chat and in that chat, you're just going to simply put, "Hey, I have a lot of console logs. Let's create a file that's like a feature flag that we simply create a granularized version of our console logs that I can turn on and off." Essentially, debug flags. True and false. If something's true, that means it's on. If something's false, that means it's off. This is what we call a

[26:17] boolean in software development. And we use this kind of logic for debug flags because now I can have all these debug flags off. What the AI model is going to do because it's not that it's inexperienced, but because it's going to be misguided or make assumptions is that it's going to originally try to be like, "Oh, you want all them off with a debug flag? I got you." And what will occur is that it will just do one flag that will essentially make it so all console logs turn off with one boolean. That sounds extremely confusing. I know what I just said sounded extremely confusing. So, let me explain. If you don't specify

[26:48] that you want this little debug flag to be off by component, what will happen is that you would turn off the debug flag. It would work. All console logs would be bye-bye. But that would mean that if you ran into an issue maybe in for example my feature of chat, I would turn the console log thing back on and then every single log for projects uploading would be shown. So we granualize the console logs by the thing that's occurring within our software. For example, chat. If I turn this to true, the only console logs I will see when debugging will be relevant to chat. That's important. That

[27:20] fundamentally just saved you thousands of hours. So, make sure to leave a like. It is completely free. This is good air handling. This is good way of making a scalable application to where other developers come to your application and you're like, "Hey, developer X, build out something in the chat log or the chat feature." Developer X runs into a feature. Developer X can literally just turn on this to true and solve it fast. Super cool stuff, y'all. All right, so here's the next three heavy hitters that I realized when using multi- aents. The first thing is that especially through a iteration process like this when you have a lot of code being created at

[27:51] once. I think at this point this entire project, this is extremely complex. And to be honest with you all, if I'm going to be completely transparent, it's getting to the point where I actually think this could be a million-doll product. No joke. The amount of value I'm getting out of this and realizing like, whoa, this could actually take market share from Photoshop, has gotten me to the point to realize that what incurs when building out such a large application that can do so much, and this is like maybe 50,000 lines of code, maybe way more. You're going to get a lot of dead code. You're going to get a lot of legacy code, and you're going to get a lot of backwards compatibility code. What do I mean by this? Here's what happens. When you're building, this

[28:22] is extremely fun. And when you're building a lot at once, the code can get very bulky, very fast. So, what is dead code? software development. What dead code means is that you have maybe 100 lines of code. Let's just go to somewhere. Give me some code. You have like, let's say this code right here. You have 18 to 28. Obviously, this is being used. But the idea behind dead code, oh my gosh, I was floating there for a second. The idea behind dead code is that the code if it's not being used. So, hypothetically, it's code that would be sit in your file like this, but literally serve no purpose. It's just

[28:53] dead code. You don't want dead code. You don't want dead code for a multiple of reasons, but let me just give you one that's going to make you be like, "Okay, I definitely don't want dead code." Dead code will make your AI outputs even worse. Why? Because you're loading in more data for the AI to analyze. And why give it 500 lines that is dead code in a 2,000line file where those 500 lines could utterly confuse the AI model and cause further issues down the road. Point being, phase one of cleaning is remove the dead code. How do I remove dead code, Corbin? Here's a prompt, but let me give you a caveat. Search through my entire repo and see if there's dead

[29:24] code. Use a highle model because you want it to actually search and not just give you an answer. Don't necess you can do this as a surface level one. Just shoot it off. See what happens. But in reality, go folder by folder. For example, don't do search through my entire repo. Search through at symbol folder. Come down here. I know studio editor is massive. We probably want to do this one. Enter. Then what is the next actionable steps? It will probably or maybe not find dead code. Make a plan. Put plan here. Hey, you see this dead code? Give me actionable steps to remove the dead code. I gave you the plan, then build it. Remove the dead

[29:55] code. Logically, you want to do those same steps for legacy code and backwards compatibility code. I would granularize by folder. And what I mean by that is if I come down here is I wouldn't necessarily do like, hey, you see my entire app, find all the dead code. It's just too much information. Unless your app's extremely small, then do it. But my app got so massive that what I needed to do was I needed to do by folder. And let's just take it one step further, maybe even by subfolders. So if I come down here, do pricing, do public, do settings, studio editor. Don't do all studio editor. No, just do the components. Just do the context. This is

[30:26] how I had to approach it. What is legacy code? Dead code and legacy code are kind of similar. Let's just do some drawing. I love this whiteboard. Okay. Dead code and legacy code is kind of similar. Not really. I mean, for example, like a dead code could be like you have a function you never ever used in your entire life and it's somehow in the application. Maybe it was like a fringe thing. Legacy code is yeah, it actually did have a use in your application at once. Maybe v1 of your application used that code. Maybe you had that specific function like me for example, a version of legacy code was the workspaces feature and I'm going

[30:57] to get into in the last part of this video why I removed it for now. It still has the ability to connect. Don't worry about it. When I say workspaces, I mean like the ability for the user to have teams and like invite seats, right? This would be example of legacy code where, you know, maybe it was in a previous version of the app, but it got deprecated. When I say deprecated, I mean it's not used anymore. Legacy code can be good in certain context. But if you haven't even launched V1, like there is no app, there is no website, just burn it. Who cares? Like there's a reason that's a legacy code before V1 even gets launched. You might as well just delete it. It's dead weight. So then that gets into the last one here.

[31:28] And how do I find legacy code, Corbin? Same process for dead code. Granularize it. Go by folder. You know, say like is this code that we used to use in the past, etc. Last one here is compatibility code. This one was very annoying and I know why it's doing it. So we just say comp. What is backward compatibility code? So you're going to use that exact terminology, backwards compatibility. When you have a live application, version one, it's production, you have a thousand users. Backwards compatibility code is fundamentally extremely important because when you push out an update, you still want those thousand users to have

[31:59] the experience that the additional next, thousand users will have. So, this is an example of where AI is being smart but dumb at the same time. And the reason it's being dumb is that it's making backwards compatibility for code that's not even live yet. Why are we migrating legacy users that don't even exist, but it doesn't know that? It thinks it's working on application that's potentially in production. So, this is like a prime AA example of like you needed to watch this video. So, you had a software engineers perspective to tell you this cuz no one's going to know

[32:30] this. But what I found out through developing using just straight prompts and this multi- aent parallel method is I would say I got like a couple days in and I realized wait a second did some search queries literally went to a prompt and said like hey searching my code is there like backwards compatibility occurring here that you didn't even tell me about. Oh there was and a lot. So without even realizing it because I didn't request it when I made a fundamental change, this thing was creating a ton of dead code and dead code that is only specific to the fact

[33:02] that I haven't launched in production yet. So where does backwards compatibility actually have value, it will have value and it's a real thing that I need if for some reason I have messed up and when I created this original fire store schema, I went about it in the wrong way. Facebook DAX architecture. And what I mean by that is, you know, we remember earlier in the series where I kind of had that Eureka moment where I was like, oh, if a user wanted to invite a team member, like this became a million-dollar platform, and I wanted to have it so that multiple users could use it, like the same

[33:32] project, the same studio, eg user could take their studio right here and share it with XYZ email or their team. My original structuring of those data paths, I would have been shooting myself in the foot. But now I don't have to migrate all these people and use backwards compatibility when I do add this feature because I went about it with the correct data path, the data path structure. This is a long-winded way of me saying that if your application is not even at a live website link yet, definitely look into your codebase to see if backwards compatibility is happening. If it's

[34:03] happening, that isn't a positive thing where it's like, "Oh, cool. Uh, it's compatible with previous versions. Why do you care? Delete it." until you get V1, that becomes relevant. But if you're not even at V1 yet, please delete it. There was hundreds of lines of code that I was like, I need to clean this. And I cleaned it. This is going to be a long video, y'all. This series is going to be massive, y'all. Make sure to leave a like. I don't even know how long this series is going to be at this point, but this is just information I need to just spew, right? Cuz you know, this is years upon years upon years of iteration and developer experience that you're getting

[34:34] compressed into like an hour video. If I were you, I would literally have a Google Docs or notes app open right now and just write down these fundamental little pieces of knowledge that I can't spew to you in like a 60-second Tik Tok. Let's go to launch. This is going to save you and your lives a ton of value, y'all. Create a feature MD file. Here's what happens when you vibe code or just build out any software. As you keep building, the wheels and your brain are going to be like, you know what' be super cool? I got to add this feature. Also, I got to add this feature. Oh, wait. I got to also add this. This would be awesome. There's a lot you're going to want to add in V1. What I'm telling

[35:05] you right now is for one, you're on the right track if you're having that kind of Eureka moments, but for two, don't add it yet. I stripped this application down to not have the workspaces on V1 because I just need to get this out. What you'll also notice is that within my settings, I don't even have the achievements feature set up yet. I just have it so that the user gets Classic and Afterparty Elite out of the box. But I did set up the data pass for the achievements cuz I know I'm going to build it next. But the reason I did that is cuz I just need to get V1 out. So, what you need to do because you're going to have a bunch of great ideas, is

[35:35] you're going to do something we do in software development, which is what we call a backlog. And what a backlog is, and I made a demo one for y'all. So, feature MD here. Let me go ahead and hide our little cursor. Let me do command shift V again so we can see it. Beautiful. What a backlog is is how we usually associate labor. This comes back to earlier lessons when I talked about when I was a project or a senior engineer essentially and then associating labor to junior engineers. We would use this after kajira. Now you can look this up. Look up jira.com. You'll know what I'm talking about. This will allow us to create road maps and

[36:06] associate labor to specific tasks. You need to create the same thing. You need to create what I like to call it feature road map. Go ahead. As you already know of my style of videos, this is a Corbin Brown video. So what you need to do is you need to screenshot this so you get your little feature template. What's an example of a feature Corbin? Export presets emotions addition tool template suggestions. So what this does and this needs to just stay beautiful. Okay, stop that. Uh what this does is go to export presets is that with that little template thing that you just screenshotted, you paused the video. You'll notice a couple things. First off, built and planned. Most of these are going to just be planned, right? Give you a little coffee cup here. It's

[36:36] going to give a time estimate. And you know what's absolutely hilarious about this? In the old ways of doing software development, like I've described before, this is probably a little accurate, but the AI doesn't even realize how fast it is now. And I'm able to build out features that would have taken 2 weeks in essentially an hour. It's ridiculous. Give the time estimate if you just want to laugh. Next one. You describe the issue, why it's not in V1 or V2 or whatever. the current states, like whether it needs to be built in or not, features, integration steps, dependencies, notes. You're going to have the AI do all of this. You're not even going to write these feature template, like these little feature logs. All you're going to do is simply

[37:08] create your little feature road map, and then you're going to talk to an AI agent and simply be like, I have an idea. I know some of you are like, I have an idea, but what is your new feature? So, one very specific feature that I know I wanted to add to my little app if I can find it to y'all is I was editing here and for some of y'all you're like, why does it keep going to the 404 page? Because I haven't set up the unique identifier for the studio yet. That's going to happen when I do the backlog or the backend episode. So, you notice in this thumbnail how my original data was me smiling. I'm going to add a feature here where the user can actually change

[37:38] the emotion with a simple click. This is cool. This is useful. You could literally look pissed off and make yourself look happy. This is a feature I added to my feature MD. I don't want to build it out right now for V1 because I don't need to yet. It's already functionally a really solid app, but I don't want to forget it. So, this is where you chuck it into your feature road map. What else is here? So, we structure typically in software when we have these big backlogs uh timelines of when we want it to be accomplished. So, what you would do is like target now would be under a month. These are features that once you have V1 out, you

[38:09] kind of want to build it and get it done fast. Next would be 1 to 3 months and then following that would be 3 to 6 months and then finally six plus months. How do we categorize here? I would suggest you just to know where you'd want to have the feature built into it long term. 6 plus months in the future. These are like this would be a cool idea or like I don't even know if this is a good idea but I thought of it. That's where you'd put those kind of ideas. 1 to 3 months this is like I really want to build this idea but I know it's going to take a little bit more time than I would like. You put in 1 to 3 months. three to six months. You know, we can

[38:40] kind of pair this with six plus months as well, but this is like more priority than six plus months. These are ideas that aren't necessarily like I don't know if I'm gonna do it. These are ideas of I'm going to do it, but first I need to build out all of this first because some stuff builds on top of each other. So therefore, build your feature road map. How do I do this? Go to an agent. Hello agent. Have one or two ideas that you don't want to put into V1. Just like if you don't have any ideas yet, just make up one just so it has a little bit of structuring. The next thing I want you to do is use this prep. I want to build a feature real map for my app. Make it an MD and put in docs folder. As

[39:11] you created the docs already, here is the image for context and here are my ideas. Now, you might be saying, Corbin, I don't have What image are you talking about? Literally, the image that's on this video right now, take pause this video, screenshot this, put it in that chat. It's going to be able to replicate that perfectly. Wait, hold up, hold up, hold up, hold up. Let me help you out, y'all. Yeah, screenshot the feature template as well. So, do both. Pause the other one. Use this right here. And then, you know, I'll be really nice, y'all. I'll be extra nice. I'll come down here. You can screenshot the one, three months, six months, etc. Love the screenshot. Corbin, why are you doing so many screenshots in your videos now? Because like, is it really worth me putting this as an MD, creating a whole

[39:42] separate repo just for this MD file? I don't think so. I really only do that for high high value ones. I'm just like, okay, even a screenshot won't do. Like my bug SOP or my bug template. So, you watch a Corbin video, you're going to screenshot a lot. So, that just about does this video. That's how you prep your application for what comes next. And what comes next, y'all, is the back end. Finally, the back end. So right now I have the order like signup, database, function, storage. I might have to move these around a little bit. Realistically, signup of course comes first. We need the signup next. In

[40:13] reality, the database actually does make sense. It be like fire store. It'll probably be storage after that cuz I want to get the thumbnail logic correct, then functions, then paid, then live app. So that might be the very rough edges of how we're going to approach this. But all I know for certainty is that the next episode in the series will be the sign up. So that just about does episode 5. Make sure to leave a like. It's completely free. should take the link to this video, spread it on social media, and be like, "Yo, we need episode 6 Pronto." Give it a like. So, without further ado, as you already know, these style videos, I'll see you in the next. Dick Corbin just showed me how to clean my code base so that when I launch my actual app to production, I don't have

[40:44] 20,000 lines of dead code that just sit there and you're just kind of like, "Wait, why is this code here?" Uh, because it's actually dead type of code. Affirmative.