WEBVTT 00:00:00.000 --> 00:00:05.400 In this video, we're going to do a comprehensive Codex tutorial. I want to show you not just what 00:00:05.400 --> 00:00:12.580 Codex is, but how to actually use it as a serious app building agent. We'll start with the foundations, 00:00:13.040 --> 00:00:20.600 how Codex works, how the Mac app and the CLI fit together, how to choose models and thinking modes, 00:00:20.780 --> 00:00:27.760 how threads and context work, and how to use tools like the browser, terminal files, and external 00:00:27.760 --> 00:00:34.560 systems. Then we'll turn that foundation into a real workflow. We'll use Codex to plan, architect, 00:00:35.160 --> 00:00:42.760 design, implement, debug, and ultimately deploy a production-ready app from scratch. By the end, 00:00:42.820 --> 00:00:48.480 you should understand the full Codex workflow well enough to take your app idea, break it into 00:00:48.480 --> 00:00:54.720 manageable steps, and use Codex to build it with much more confidence. Now, when you Google for 00:00:54.720 --> 00:01:02.940 Codex, you're going to land on this website here. And here you can learn more about Codex and you can 00:01:02.940 --> 00:01:08.840 also download the app. Now, as you can see, it says here, download for macOS. That is because I have 00:01:08.840 --> 00:01:15.000 macOS. If you're running Windows, you're going to have a button that says download for Windows. So 00:01:15.000 --> 00:01:20.920 it does support macOS and Windows. And when you scroll down, you can see the main screenshot 00:01:20.920 --> 00:01:24.980 that kind of gives you a general overview, 00:01:25.200 --> 00:01:29.280 general idea of what this app looks like, okay? 00:01:29.300 --> 00:01:30.560 And you can kind of scroll down, 00:01:30.660 --> 00:01:32.060 you can learn more about it, 00:01:32.160 --> 00:01:35.760 or we can jump into my Codex instance here 00:01:35.760 --> 00:01:37.140 and I can give you a quick overview. 00:01:37.300 --> 00:01:38.600 So on the left-hand side, 00:01:39.020 --> 00:01:41.120 we have things like starting a new chat, 00:01:41.460 --> 00:01:43.880 search, various plugins, automations. 00:01:43.880 --> 00:01:49.320 Just below that, we have our main organization, right? 00:01:49.320 --> 00:01:51.840 And this is where you can organize your projects. 00:01:52.220 --> 00:01:52.380 Okay. 00:01:52.920 --> 00:02:06.420 And the idea here is that anytime you have a project, you want to click here and you want to actually either start it from scratch or you use an existing folder because these are not organized just logically. 00:02:06.420 --> 00:02:10.720 They're actually linked to folders on your disk. 00:02:11.000 --> 00:02:11.320 Okay. 00:02:11.420 --> 00:02:16.280 And so everything that you see here represents actual folders. 00:02:16.280 --> 00:02:19.980 Now, inside of these folders, we have some items here. 00:02:20.080 --> 00:02:23.840 Now, these are not files, and they do not represent anything on the disk. 00:02:24.220 --> 00:02:26.700 These are actually conversations, right? 00:02:26.760 --> 00:02:32.600 And you can think of them as, you know, similar to what you may have in chat GPT, okay? 00:02:32.680 --> 00:02:38.020 So if you're working on this project, you can create a new conversation simply by, you know, 00:02:38.100 --> 00:02:42.940 clicking here or pressing Command and telling it what you want to happen. 00:02:42.940 --> 00:02:48.220 Now, in the center pane over here, this is where you're going to be communicating, right? 00:02:48.300 --> 00:02:52.580 So if we scroll back up, this was my initial prompt here. 00:02:52.640 --> 00:02:58.420 I want to build a very, very simple web app that arranges items as a Trello Kanban board 00:02:58.420 --> 00:02:59.360 style, et cetera. 00:02:59.500 --> 00:03:01.980 And then I have this interaction here, right? 00:03:02.020 --> 00:03:02.940 It does something. 00:03:03.560 --> 00:03:06.480 I ask it to do something else, et cetera, et cetera. 00:03:06.820 --> 00:03:11.700 Now, just below that is where you're going to be entering your prompt, okay? 00:03:11.700 --> 00:03:17.520 So you're going to be selecting the model, the different reasoning, and we're going to be covering all that. 00:03:17.620 --> 00:03:19.640 But this is the main text box for the model. 00:03:20.180 --> 00:03:26.920 Now, on the right-hand side, there's a lot of interesting things happening here that a lot of people are not really aware of. 00:03:27.200 --> 00:03:30.620 And a lot of people are not really using it. 00:03:30.800 --> 00:03:34.380 And you need to understand to leverage this whole app experience. 00:03:34.380 --> 00:03:41.940 right? So right here, we have this little card that displays a little bit of information about 00:03:41.940 --> 00:03:47.780 this specific conversation, right? So we have branch details, we have some artifacts, right? 00:03:47.820 --> 00:03:54.080 And these are the data that happened as a result of this convo. And so if I go to another 00:03:54.080 --> 00:03:59.340 conversation, we might have different artifacts, right? And you can think of an artifact as a 00:03:59.340 --> 00:04:03.020 side effect of your conversation. 00:04:03.440 --> 00:04:06.740 So if you've created the readme file, you're going to see it here. 00:04:06.800 --> 00:04:09.320 If you did a web search, you're going to see it here. 00:04:09.440 --> 00:04:14.680 Now, one of the more interesting things happens when you click this button and open the right 00:04:14.680 --> 00:04:15.280 hand pane. 00:04:15.520 --> 00:04:17.960 And here you can see all kinds of interesting things. 00:04:18.200 --> 00:04:23.940 So for instance, if I click this button, I can have a side chat or I can have a browser. 00:04:23.940 --> 00:04:29.980 Now, the browser feature is actually very, very powerful because I can simply open this up here. 00:04:30.400 --> 00:04:37.680 And as I'm developing this app, it's going to give me a URL that I can open here in this browser. 00:04:37.680 --> 00:04:46.080 And that will allow me quick iteration because I'll be able to see exactly how the app looks as I'm developing it. 00:04:46.160 --> 00:04:50.940 And we're going to be doing all of that in more detail a little bit later in this tutorial. 00:04:53.940 --> 00:04:55.900 First, let's talk about Codex. 00:04:56.240 --> 00:05:03.100 The easiest way to understand Codex is that it starts from the same basic idea as ChatGPT, 00:05:03.100 --> 00:05:06.640 but it is connected to your actual working environment. 00:05:06.980 --> 00:05:13.500 So instead of only answering questions, it can inspect files, edit code, run commands, 00:05:14.020 --> 00:05:19.420 use the browser, test the app, and help move a project forward. 00:05:19.620 --> 00:05:21.160 The difference matters a lot. 00:05:21.160 --> 00:05:28.560 ChatGPT is great when I want an explanation, a rewrite, a brainstorm, or a quick answer. 00:05:28.840 --> 00:05:33.220 Codex is what I use when I want work to happen inside a real project. 00:05:33.640 --> 00:05:41.580 It can do many of the same reasoning tasks as ChatGPT, but it can also act on the project directly. 00:05:42.240 --> 00:05:47.020 That is why I keep ChatGPT mostly for pure informational questions, 00:05:47.020 --> 00:05:54.600 and I keep codecs for work threads so my project context stays focused and clean. 00:05:54.880 --> 00:05:56.980 There are two main ways to use codecs. 00:05:57.280 --> 00:06:02.300 The first is through the CLI, which is best when you already live in the terminal 00:06:02.300 --> 00:06:10.280 and want to run quick repo tasks, scripts, lightweight edits, or developer-style iterations. 00:06:10.720 --> 00:06:16.220 The second is the Mac app, which is usually better for visual app building work. 00:06:16.220 --> 00:06:32.060 If I want to see the browser preview, inspect file changes, manage a longer project, approve permissions, review artifacts, or teach the workflow on screen, the Mac app gives me a much clearer workspace. 00:06:32.720 --> 00:06:38.320 And that is why I highly prefer to use the Mac app, and that is what I recommend you use as well. 00:06:38.320 --> 00:06:58.740 Inside the Mac app, the main pieces to understand are the project or the workspace, the thread area, the model selector, the thinking mode selector, file changes, terminal output, browser preview, artifacts, permissions, and the review flow. 00:06:58.740 --> 00:07:08.700 Once those pieces make sense, Codex stops feeling like a chat box and starts feeling like an app-building environment. 00:07:08.940 --> 00:07:12.920 The project pane is where you open or switch between projects. 00:07:13.540 --> 00:07:17.980 The thread area is where the conversation and task history live. 00:07:18.720 --> 00:07:25.080 The file change view shows what Codex wants to edit before those changes are accepted. 00:07:25.080 --> 00:07:31.180 The terminal output shows commands, builds, errors, and verification steps. 00:07:31.480 --> 00:07:35.620 The browser preview is where you can inspect the running app visually. 00:07:36.420 --> 00:07:41.160 Together, these pieces make Codex feel less like a chatbot 00:07:41.160 --> 00:07:44.080 and more like a working development environment. 00:07:44.720 --> 00:07:46.520 Permission flow is also important. 00:07:47.220 --> 00:07:52.080 Codex should never feel like a black box that silently changes everything. 00:07:52.080 --> 00:07:57.660 everything. As soon as it finishes running commands, editing files, or taking an action 00:07:57.660 --> 00:08:03.760 that matters, you can always inspect what it's doing, approve the right actions, and 00:08:03.760 --> 00:08:05.820 keep control over the project. 00:08:08.412 --> 00:08:12.412 The next thing to understand is that Codex is not just one fixed experience. 00:08:13.412 --> 00:08:19.412 There are a few workflow decisions you make each time you use it, and the first one is which model to use. 00:08:19.412 --> 00:08:27.092 use. In practice, I usually default to the latest strongest model unless I have a clear reason not to, 00:08:27.732 --> 00:08:34.932 because most app building tasks benefit from better reasoning. Here's a rough guide to picking 00:08:34.932 --> 00:08:42.532 the correct model for your specific task. So for architecture, backend design, multi-step 00:08:42.532 --> 00:08:49.592 implementation, difficult debugging, or final review passes, I want a stronger model, such as 00:08:49.592 --> 00:09:00.612 GPT 5.5. For small copy tweaks, simple UI polish, short refactors, or low-risk tasks, a faster, 00:09:00.872 --> 00:09:08.192 a lighter model can be a better tool. And here's where you can use an older model, or a mini or a 00:09:08.192 --> 00:09:15.232 nano version of the current latest model. For example, if I'm asking Codex to rename a button, 00:09:15.812 --> 00:09:22.852 tighten some copy, or adjust spacing on one component, I do not need to overthink the model 00:09:22.852 --> 00:09:29.912 choice. But if I'm asking Codex to design the convex schema, think through permissions, 00:09:30.532 --> 00:09:37.252 restructure several files, or debug a problem that spans front-end and back-end code, 00:09:37.252 --> 00:09:41.352 That is where I want the strongest model available. 00:09:42.132 --> 00:09:50.332 The more expensive the mistake, the more I want to slow down and use the better reasoning setup. 00:09:53.032 --> 00:09:56.512 The next important decision is the reasoning mode. 00:09:57.072 --> 00:10:05.472 This controls how much time and effort Codex spends thinking through the task before and during the work. 00:10:05.472 --> 00:10:12.812 This decision is a little more nuanced than model choice because every reasoning mode has a place. 00:10:13.172 --> 00:10:18.992 Low thinking is useful for quick, obvious tasks where the risk is small. 00:10:19.512 --> 00:10:26.292 Medium is good for normal app building work, first pass UI implementation, 00:10:27.152 --> 00:10:31.212 straightforward debugging, and routine feature work. 00:10:31.212 --> 00:10:34.592 High is what I use when the decision is more expensive. 00:10:34.592 --> 00:10:43.092 architecture, convex, data model design, authentication, permissions, hard bugs, 00:10:43.772 --> 00:10:50.872 multi-file changes, and the final review. My default for serious app building work 00:10:50.872 --> 00:10:58.552 is usually a strong model with high thinking because that gives me the best balance between 00:10:58.552 --> 00:11:06.012 speed and quality. But the practical lesson is simple. Match the model and thinking mode 00:11:06.012 --> 00:11:14.292 to the risk of the decision. If the task is small and reversible, keep it fast. If the task affects 00:11:14.292 --> 00:11:21.112 the structure of the app, slow the model down and let it reason. Now, as you're working on your 00:11:21.112 --> 00:11:28.052 project and you're in this conversation view, you can enter your prompts here and just below 00:11:28.052 --> 00:11:34.432 you can select various things. Now, first of all, you have your context window here, right? Here, 00:11:34.532 --> 00:11:41.952 you can see how much of the context you have used. Now, Kodak says that it automatically compacts 00:11:41.952 --> 00:11:48.792 its context. And yeah, you can do that, but over time, it's not going to be as effective. And so 00:11:48.792 --> 00:11:54.872 you always want to be starting new conversations anytime you're working on something new that 00:11:54.872 --> 00:12:02.832 requires a context switch. Next, we have here the all-important model selector. So if I click over 00:12:02.832 --> 00:12:10.332 here, I have it automatically set to GPT 5.5, which is the newest model as of the time of recording 00:12:10.332 --> 00:12:16.732 this video. You can also switch it to some of the older models as well, but I see no reason to do 00:12:16.732 --> 00:12:24.492 that because this model has been very, very capable. We also have things like speed, standard versus fast, 00:12:24.872 --> 00:12:30.932 Fast is one and a half times faster, but it also uses more of your usage. 00:12:31.352 --> 00:12:35.572 Okay, so depending on which plan you're at, you may want to stay on standard. 00:12:35.692 --> 00:12:40.392 I mostly keep it on standard unless, you know, I'm in a hurry and I want to switch it on fast. 00:12:40.892 --> 00:12:42.732 Next, we have intelligence, right? 00:12:42.812 --> 00:12:44.312 Now, this is very, very important. 00:12:44.912 --> 00:12:47.532 By default, I keep this on high. 00:12:47.532 --> 00:12:56.052 I found that to be a good balance between speed and quality, because as you go towards lower 00:12:56.052 --> 00:13:02.352 intelligence, the model is going to be faster, but you're going to be giving up quality, right? 00:13:02.372 --> 00:13:06.912 You're going to be giving up intelligence. On the other hand, as you go into higher and higher 00:13:06.912 --> 00:13:12.392 intelligence, the model is going to be slower, but it's going to be thinking more, right? It's 00:13:12.392 --> 00:13:19.532 kind of like a person, right? You can ask a person a question and that person may think more, 00:13:19.992 --> 00:13:25.532 think through something longer, right? You know how people say, let me sleep on it, 00:13:25.532 --> 00:13:31.892 or let me think it over, right? The longer you think, the more you figure something out, 00:13:32.352 --> 00:13:39.352 and the higher chance you're going to arrive at the correct answer, at least for you. You're 00:13:39.352 --> 00:13:45.452 going to think through all the possibilities. Whereas the first answer might be wrong and 00:13:45.452 --> 00:13:50.752 usually is because you haven't thought everything through. And it's the exact same thing here, 00:13:50.852 --> 00:13:55.392 right? If you set something too low and you're working through something fairly complex, 00:13:55.852 --> 00:14:01.912 well, the model is not going to think it through. It's going to give you an answer that, well, 00:14:01.912 --> 00:14:08.652 it's an answer, but it might not be the ideal answer. Okay. On the other hand, with extra high, 00:14:08.652 --> 00:14:16.732 you know, the model is going to think longer, but it may not be necessary in a lot of situations. 00:14:16.732 --> 00:14:24.332 And so I typically keep it on high, sometimes medium, very rarely low, and also very rarely 00:14:24.332 --> 00:14:30.012 extra high, unless I'm working through something that the model has trouble with high. You know, 00:14:30.072 --> 00:14:35.732 the situations where extra high really proven itself over high, it hasn't been that many. And 00:14:35.732 --> 00:14:40.472 And so for the most part, I keep it on high, sometimes I also switch it back to medium. 00:14:40.472 --> 00:14:46.172 And as you start to use Codex more and more, and as you begin building more and more apps 00:14:46.172 --> 00:14:52.232 with it, you'll be able to better judge which thinking mode to select. 00:14:52.232 --> 00:14:59.652 Now, before we go deeper into the workflow, I want to quickly talk about pricing and plans, 00:14:59.652 --> 00:15:03.252 because this is one of the first practical questions people have with Codex. 00:15:03.252 --> 00:15:07.552 For most people learning codex, the important question is not what is the most expensive 00:15:07.552 --> 00:15:08.552 plan. 00:15:08.552 --> 00:15:12.252 The question is what do I actually need for the kind of work I'm doing. 00:15:12.252 --> 00:15:16.692 If you're learning, testing prompts, and building smaller projects, you can usually 00:15:16.692 --> 00:15:21.172 start with the normal ChatGPT plan access available to you. 00:15:21.172 --> 00:15:26.492 If you're doing heavier app builds, longer agent runs, team workflows, or professional 00:15:26.492 --> 00:15:32.412 coding work, then plan limits, credits, and business options start to matter more. 00:15:32.412 --> 00:15:36.352 Now, here I am on OpenAI's Codex pricing page. 00:15:36.412 --> 00:15:43.212 And if you scroll down, you can see the prices that are available at the time of filming this video, right? 00:15:43.272 --> 00:15:49.112 So we have the free plan, and this allows you to explore Codex capabilities and quick coding tasks. 00:15:49.112 --> 00:15:55.252 We have the go plan, which is $8 a month, and you can use Codex for lightweight coding tasks. 00:15:55.412 --> 00:16:00.052 We have the plus plan, which is fairly popular, $20 a month. 00:16:00.052 --> 00:16:05.592 And here you can finally start to actually do something meaningful, right? 00:16:05.712 --> 00:16:07.052 Something like, you know, building... 00:16:07.412 --> 00:16:09.492 Something like, you know, building a part of an app or building some scripts. 00:16:09.752 --> 00:16:14.612 And they say this can power a few focused coding sessions each week. 00:16:14.812 --> 00:16:16.572 Next, we have the Pro plan, right? 00:16:16.572 --> 00:16:22.992 And so here you can choose whether you want the 5X or the 20X higher rate limits than plus. 00:16:23.112 --> 00:16:24.872 And this is $100 a month. 00:16:24.932 --> 00:16:28.172 I'm actually using the ProPlan 20X. 00:16:28.432 --> 00:16:30.592 Okay, so I'm paying 200 bucks a month. 00:16:30.892 --> 00:16:37.132 And at this level, I am at a point where I pretty much never reach any limits. 00:16:37.392 --> 00:16:43.552 And that means I can build, you know, multiple projects at once and use codecs for all kinds 00:16:43.552 --> 00:16:46.432 of tasks and still not reach limits. 00:16:46.432 --> 00:16:54.252 And so during the time when I'm, you know, building heavy apps and doing some serious work, I may get close, right? 00:16:54.292 --> 00:16:56.372 But I never really get to the limit. 00:16:56.452 --> 00:16:59.552 You need to decide which plan is right for you. 00:16:59.632 --> 00:17:03.372 Now, from what I understand, Plus Plan is very, very popular. 00:17:03.592 --> 00:17:08.872 And so what I would do is I would obviously, you know, try the free plan, try to see how that goes. 00:17:08.992 --> 00:17:16.332 And, you know, obviously, you know, if you do anything serious or remotely serious, you're probably, you know, you're going to run out of this plan. 00:17:16.332 --> 00:17:19.492 And so the next logical step is to try out the plus plan. 00:17:19.572 --> 00:17:21.772 The plus plan is where a lot of people start. 00:17:22.112 --> 00:17:27.772 And it gives you a reference point as to, you know, the amount of work that you're doing. 00:17:27.872 --> 00:17:31.392 How much can this plan actually cover the amount of work you're doing? 00:17:31.412 --> 00:17:36.272 Because the fact of the matter is there are people that work on very heavy projects. 00:17:36.592 --> 00:17:39.312 And, you know, they work on big repos, right? 00:17:39.372 --> 00:17:40.752 Lots and lots of code base. 00:17:41.032 --> 00:17:43.632 They run out of their plan very, very quickly. 00:17:43.632 --> 00:17:48.292 But if you're working on the smaller projects, you're not using the fast mode. 00:17:48.432 --> 00:17:52.312 So for instance, you're not coming here and you're changing, you're not changing speed 00:17:52.312 --> 00:17:55.352 because I'm using the fast mode from time to time. 00:17:55.352 --> 00:17:57.852 And that, you know, increases the usage as well. 00:17:57.952 --> 00:18:01.852 So if you're on standard and you're using maybe medium often, right? 00:18:01.892 --> 00:18:06.332 You're not really using high that much and you're almost never using extra high. 00:18:06.552 --> 00:18:09.792 You can get a lot of mileage out of this plus plan. 00:18:09.792 --> 00:18:15.952 And when this plus plan starts to run out, you know, you're starting to notice some tight limits, 00:18:16.172 --> 00:18:22.172 you may want to switch to a higher plan, okay, such as the Pro, 5X, or 20X. Now, you can also 00:18:22.172 --> 00:18:27.392 ask Codex to help you choose the right Codex plan for your specific use case. For instance, 00:18:27.472 --> 00:18:32.932 you can use this prompt here, help me choose the right Codex plan for my use case, okay, 00:18:33.032 --> 00:18:38.472 use only current official OpenAI pricing and help center information. And I'm going to go ahead and 00:18:38.472 --> 00:18:43.612 run this and see what it says. Right. And this is what we got back. As of this day, 00:18:43.732 --> 00:18:50.412 ChatGPT plans that include codecs. Okay. So this is the practical read. Free, try codecs on quick 00:18:50.412 --> 00:18:57.012 tasks, go lightweight coding tasks, plus a few focused coding sessions each week. Okay. And this 00:18:57.012 --> 00:19:02.152 is exactly what I just told you from that official page. And so if you scroll down, you can see how 00:19:02.152 --> 00:19:08.232 codecs usage and credits work. You can learn, you can read this. Best fit for your use case. Okay. 00:19:08.232 --> 00:19:14.332 for learning codex and building small to medium apps, chat GPT plus is the sensible default. If 00:19:14.332 --> 00:19:19.492 your current plan is plus, I would not upgrade until you actually hit codex limits often enough 00:19:19.492 --> 00:19:25.192 that the friction matters. Okay, when heavier or business plans make sense, what to verify live 00:19:25.192 --> 00:19:31.432 before deciding. And so a sensible thing to do would be to try codex plus and see if that's 00:19:31.432 --> 00:19:36.432 enough for your specific use case. If you're not a heavy codex user, if you just want to experiment, 00:19:36.432 --> 00:19:41.192 it should be more than enough. And then you can decide whether you want to upgrade to the higher 00:19:41.192 --> 00:19:49.172 tier plans. Now, before we move into the app building workflow, I want to take a moment to 00:19:49.172 --> 00:19:54.152 talk about some of the things Codex does that can greatly increase your productivity. These are 00:19:54.152 --> 00:20:02.292 features I use all the time across different projects. Skills, plugins, automations, and MCP, 00:20:02.292 --> 00:20:09.872 along with its tools and connectors. The best way to think about all that is skills tell Codex how 00:20:09.872 --> 00:20:19.072 to do a workflow, plugins package capabilities, automations let work happen later, and MCP tools 00:20:19.072 --> 00:20:26.152 and connectors give Codex controlled access to outside systems. Once those pieces make sense, 00:20:26.152 --> 00:20:31.152 Codex feels less like a code editor and more like a project agent. 00:20:31.152 --> 00:20:37.152 First, let's talk about one of my favorite features that I use pretty much all the time – skills. 00:20:37.152 --> 00:20:42.152 Skills are reusable instructions for how Codex should do a workflow. 00:20:42.152 --> 00:20:45.152 They're not external tools by themselves. 00:20:45.152 --> 00:20:52.152 They're more like local playbooks that tell Codex the style, process, output format, 00:20:52.152 --> 00:20:56.912 format and validation steps for a specific kind of work. 00:20:56.912 --> 00:21:04.492 For example, this course uses skills for explainers, notion editing, video timelines, and other 00:21:04.492 --> 00:21:07.212 repeatable production tasks. 00:21:07.212 --> 00:21:13.192 Instead of explaining the same rules every time, I can point Codex to the skill and it 00:21:13.192 --> 00:21:18.632 knows the house style, the workflow, and the mistakes to avoid. 00:21:18.632 --> 00:21:25.472 The rule is simple. Anything that gets used over and over again becomes a skill. That matters 00:21:25.472 --> 00:21:30.712 because a lot of real work is not just about getting an answer. It's about getting an answer 00:21:30.712 --> 00:21:38.072 in the right format, following the right process, and producing something consistent with the rest 00:21:38.072 --> 00:21:43.712 of the project. All right, so here I am in my Codex instance here, and I want to show you some 00:21:43.712 --> 00:21:48.552 things that you can do with skills. So I have here a conversation for an app that I was building. 00:21:48.632 --> 00:21:54.712 And if I press the forward slash, you can see that I have many options here, right? 00:21:54.732 --> 00:21:56.072 I can do many, many things. 00:21:56.712 --> 00:22:00.072 And as you can see for skills, I have lots and lots of skills. 00:22:00.192 --> 00:22:02.352 I have tons and tons of skills over there. 00:22:02.592 --> 00:22:07.632 And skills allow me to package a repeatable process. 00:22:08.172 --> 00:22:11.072 You can think of it as a function that does something. 00:22:11.152 --> 00:22:13.972 It gets some input and it produces an output. 00:22:13.972 --> 00:22:18.232 And the goal is to produce consistent output as you've done before. 00:22:18.632 --> 00:22:22.672 And so as an example, let's say if I'm working in this convoy here, right? 00:22:23.132 --> 00:22:25.972 And I asked the model to do something for me. 00:22:25.972 --> 00:22:28.772 So here I have, I want to build a very simple web app 00:22:28.772 --> 00:22:31.972 that arranges items as a Trello Kanban board style. 00:22:31.972 --> 00:22:33.752 Okay. And it comes up with this. 00:22:33.752 --> 00:22:36.692 Now, right here, I can package that as a skill. 00:22:36.692 --> 00:22:39.052 Now, what do I want to package as a skill? 00:22:39.052 --> 00:22:42.532 Well, I want to package, for instance, maybe creating the architecture. 00:22:42.892 --> 00:22:48.032 So I can say something like package the architecture step 00:22:48.032 --> 00:22:56.632 as a skill, and then I just give it a name of the skill, sample art stack, okay? And that's going to 00:22:56.632 --> 00:23:04.932 create a repeatable skill that will allow me to generate an architecture for any kind of project 00:23:04.932 --> 00:23:10.212 that I may be working in the future. I'm going to go ahead and jump into the plan mode in case the 00:23:10.212 --> 00:23:15.392 model wants to confirm something or clarify something, and I'm going to go ahead and execute 00:23:15.392 --> 00:23:21.552 this and let's see what happens now it came back to me and it wants me to answer a question 00:23:22.352 --> 00:23:28.752 should the sample arch stack package this as a general architecture planning skill or specifically 00:23:28.752 --> 00:23:35.472 as the kanban trello architecture right so we want it to be general app architecture so i'm 00:23:35.472 --> 00:23:41.152 going to go ahead and save this and now it came back with a plan okay create the reusable codex 00:23:41.152 --> 00:23:48.692 skill named samplearchstack under wherever it's storing those skills, the skill will guide codecs 00:23:48.692 --> 00:23:53.872 through the architecture step for simple app ideas. And it's going to package that step into 00:23:53.872 --> 00:23:59.892 a reusable process. All right. And now it tells me that I created the skill at it contains skill.md 00:23:59.892 --> 00:24:07.112 and then agents forward slash openai.yaml. Validation passed, et cetera, et cetera. And now 00:24:07.112 --> 00:24:07.412 would I 00:24:07.412 --> 00:24:13.172 And now what I can do is I can enter a prompt and I can say use this skill for a brand new 00:24:13.172 --> 00:24:20.232 project management app. And it should use this skill to create an architecture stack 00:24:20.232 --> 00:24:25.072 for this kind of app. So it wants to know for the brand new project management app, 00:24:25.152 --> 00:24:29.552 what should the version one data model support? We're just going to do local only. And here it 00:24:29.552 --> 00:24:34.772 came back with a plan. Brand new local only project management app architecture, right? 00:24:34.812 --> 00:24:39.672 That's the purpose of the skill. Okay. We're going to expand this and it's coming up with 00:24:39.672 --> 00:24:46.752 this architecture, right? App shape, data state model, component architecture, test plan, et cetera, 00:24:46.752 --> 00:24:51.352 etc. And we can say yes, and it's going to go ahead and implement all that. And so this is 00:24:51.352 --> 00:24:57.172 actually a fairly valuable skill, because that is exactly what you want to be doing in those 00:24:57.172 --> 00:25:01.172 initial stages when you're building an app, as you're going to see a little bit later. 00:25:01.832 --> 00:25:09.232 But by having the skill, we do not need to explain all of that over and over again. So as you're 00:25:09.232 --> 00:25:15.892 building more and more apps, you can simply reuse this skill from now on. Now, before moving further, 00:25:15.892 --> 00:25:22.372 I also want to explain a few terms that can sound similar at first, plugins, automations, 00:25:22.512 --> 00:25:29.532 and MCP. They all expand what Codex can do, but they are not the same thing. Plugins are 00:25:29.532 --> 00:25:37.332 package capabilities or workflows that make Codex better at a specific kind of work. For example, 00:25:37.532 --> 00:25:44.872 a Notion plugin can help Codex read and update Notion pages. A Vercel plugin can help with 00:25:44.872 --> 00:25:51.712 deploys on project settings, a Hyperframes plugin can help create explainers, and browser 00:25:51.712 --> 00:25:57.332 or document tools can help Codex inspect apps or work with files. 00:25:58.012 --> 00:26:00.792 The simple way to think about plugins is this. 00:26:01.272 --> 00:26:06.712 They give Codex a more specialized tool set for a specific job. 00:26:07.512 --> 00:26:13.832 Codex still needs the right context and the right instruction, but the plugin gives it 00:26:13.832 --> 00:26:21.812 a cleaner way to operate inside that workflow. Automations are different. A plugin gives Codex 00:26:21.812 --> 00:26:30.752 a capability, but an automation gives Codex a time-based job or follow-up behavior. That might 00:26:30.752 --> 00:26:38.792 be a reminder, a recurring check, a scheduled review, or a request to come back to a thread 00:26:38.792 --> 00:26:46.892 later and continue the work. This is useful because not every task needs to happen immediately. 00:26:47.312 --> 00:26:54.232 Sometimes you may want Codex to check something again tomorrow, remind you to review an outline, 00:26:54.632 --> 00:27:02.092 monitor whether a deployment is still working, or wake this thread back up when you need it to 00:27:02.092 --> 00:27:09.472 continue. Automations turn Codex from a one-time assistant into something that can help manage 00:27:09.472 --> 00:27:16.332 longer running work. The important distinction is simple. Plugins are about what Codex can do, 00:27:16.952 --> 00:27:23.752 and automations are about when Codex should do it. All right, so here I am back in Codex, 00:27:23.872 --> 00:27:27.552 and I want to show you how plugins work, right? So if you click over here on plugins, 00:27:27.552 --> 00:27:30.812 you can see all the plugins that you have here, okay? 00:27:30.972 --> 00:27:34.212 And so it tells you that make Codex work your way. 00:27:34.472 --> 00:27:35.612 And if you scroll down, 00:27:35.692 --> 00:27:37.572 you can see all the different plugins, right? 00:27:37.592 --> 00:27:38.812 So you can click on the plugin 00:27:38.812 --> 00:27:40.932 and you can learn more about it, right? 00:27:40.972 --> 00:27:42.532 So for instance, this spreadsheets 00:27:42.532 --> 00:27:46.132 allows you to create and edit spreadsheet files, right? 00:27:46.492 --> 00:27:49.072 You can use this plugin to create a spreadsheet 00:27:49.072 --> 00:27:52.092 to analyze this company's financial, et cetera, et cetera, 00:27:52.212 --> 00:27:52.472 right? 00:27:53.012 --> 00:27:56.252 Create, edit, inspect, render, verify, and export 00:27:56.252 --> 00:28:03.392 Excel, SX, CSV, and TSV spreadsheets locally. Use spreadsheets when the durable output or target is 00:28:03.392 --> 00:28:09.652 a spreadsheet, workbook, etc., etc. So this includes the skill, right? So you can think of package 00:28:09.652 --> 00:28:19.012 as kind of an umbrella that includes a skill, but it also gives codecs an ability to connect 00:28:19.012 --> 00:28:24.572 to external systems, right? It's kind of this higher level structure, okay? Whereas the skill 00:28:24.572 --> 00:28:27.652 is a very, very specific thing. 00:28:28.072 --> 00:28:29.792 It's a specific piece of instruction, 00:28:29.932 --> 00:28:31.492 essentially a specific prompt. 00:28:31.712 --> 00:28:35.652 A plugin is this umbrella that contains a skill, right? 00:28:35.692 --> 00:28:36.612 So you can have that. 00:28:36.692 --> 00:28:39.412 One plugin that I use all the time is Notion. 00:28:39.512 --> 00:28:40.812 So if we click over here, 00:28:40.912 --> 00:28:43.212 you can see that this actually includes 00:28:43.212 --> 00:28:44.992 a lot more interesting things, right? 00:28:45.612 --> 00:28:48.732 Notion workflows for specs, research, meetings, 00:28:49.272 --> 00:28:50.992 and knowledge capture, right? 00:28:50.992 --> 00:28:52.812 So you can specify this, 00:28:53.212 --> 00:28:54.512 and then you can give it a prompt. 00:28:54.572 --> 00:28:59.852 And if you scroll down, you can see that it includes the Notion app, the knowledge capture. 00:29:00.012 --> 00:29:00.932 These are skills. 00:29:01.172 --> 00:29:02.152 This is an app. 00:29:02.632 --> 00:29:06.632 Okay, so this allows it to connect to an external system, right? 00:29:06.632 --> 00:29:12.012 So if I click over here, I can manage this in ChatGPT as well because it's an external app. 00:29:12.252 --> 00:29:14.592 And this right here, these are skills, right? 00:29:14.632 --> 00:29:18.432 I can open that, and that's going to open this skill right here, right? 00:29:18.532 --> 00:29:21.492 This is how the skill is actually stored. 00:29:21.492 --> 00:29:26.552 And I can also turn it off or turn it on, depending on if I want that skill enabled or not. 00:29:26.632 --> 00:29:29.212 Now, this is a plugin that I use all the time, right? 00:29:29.312 --> 00:29:37.072 I use Notion for my planning, for, you know, writing stuff, scheduling, stuff like that. 00:29:37.112 --> 00:29:40.372 It's the brain of my workflow, essentially. 00:29:40.712 --> 00:29:43.872 And then I installed this pre-built Notion plugin. 00:29:44.612 --> 00:29:51.392 And the first time I ran it, it authenticated against my Notion workspace, right? 00:29:51.392 --> 00:29:58.132 connected to my Notion account. And from then on, I can simply say, hey, use this Notion spec to do 00:29:58.132 --> 00:30:05.412 this or to do that, or edit this document, edit that document. And it's able to go out and edit 00:30:05.412 --> 00:30:12.732 the right documents and essentially make Notion an extension of codecs. That's kind of the purpose 00:30:12.732 --> 00:30:19.312 of a skill, to make something an extension of codecs. And that's the main idea with all of this. 00:30:19.312 --> 00:30:23.092 Another really cool one is, for instance, Google Calendar is another one. 00:30:23.092 --> 00:30:27.592 Instead of connecting to Notion, or in addition to connecting to Notion, 00:30:27.892 --> 00:30:29.752 you can also connect to Google Calendar. 00:30:29.752 --> 00:30:31.732 I personally do not use Google Calendar. 00:30:31.732 --> 00:30:34.852 I use Notion, so I do not have this skill set up. 00:30:35.232 --> 00:30:39.332 Another really useful skill that you're definitely going to be using 00:30:39.332 --> 00:30:41.432 if you're building apps is Vercel. 00:30:41.432 --> 00:30:47.412 Vercel or maybe something like Netlify for deploying your apps. 00:30:47.412 --> 00:30:55.172 right? I use Vercel when demoing apps. And by having this package installed, it can figure out 00:30:55.172 --> 00:31:00.692 how to deploy, how to check deployment, how to do everything without me needing to actually 00:31:00.692 --> 00:31:06.292 understand how all of that works, without me needing to go to Vercel and read their docs and 00:31:06.292 --> 00:31:13.012 understand how to deploy and all of that. I simply install this skill and then I click here and now 00:31:13.012 --> 00:31:19.412 can say you know vercel ordered this repo for vercel deployment risk or vercel which vercel 00:31:19.412 --> 00:31:26.772 tools will fit this app at best or vercel deployed this app right and if you scroll down you can see 00:31:26.772 --> 00:31:31.812 that this has this app and then it has all of these skills all of these different skills look 00:31:31.812 --> 00:31:38.292 at this it has a son a ton of skills vercel cli vercel agent all of these and obviously these 00:31:38.292 --> 00:31:45.412 skills are not just for deploying, because we also have payments, we have best practices, 00:31:45.412 --> 00:31:53.412 we have all of these other ones. These skills essentially map to different parts of our cell, 00:31:53.412 --> 00:31:58.612 to different features of our cell. We're not just talking about deploying your app, 00:31:58.612 --> 00:32:04.292 because this could be just a skill, deployment. This could be one skill that I may need. I may 00:32:04.292 --> 00:32:07.412 not need all of these other skills, but why not? 00:32:09.012 --> 00:32:15.092 out which skill it needs to consult, you know, according to the prompt that I give it. So it 00:32:15.092 --> 00:32:20.012 doesn't, you know, it's not a big deal to have all of these enabled if I'm using Vercel. And like I 00:32:20.012 --> 00:32:26.972 this allows me to basically bring Vercel into my Codex workflow. That's the beauty of these plugins. 00:32:27.372 --> 00:32:31.892 And that's the same idea with all of these plugins. You're essentially bringing an external 00:32:31.892 --> 00:32:38.592 system and letting Codex manage it for you. Now, automations work very, very differently. 00:32:39.252 --> 00:32:44.972 So if you click on automations here, you can see that automations, they allow you to automate work 00:32:44.972 --> 00:32:47.252 by setting up scheduled chats. 00:32:47.552 --> 00:32:49.052 Okay, and you can learn more here. 00:32:49.252 --> 00:32:51.112 Now, if you click on any of these automations, 00:32:51.232 --> 00:32:54.052 you can see exactly how they're going to be working. 00:32:54.152 --> 00:32:55.352 So if I click on something like 00:32:55.352 --> 00:32:58.972 summarize yesterday's Git activity for standup, 00:32:59.452 --> 00:33:02.272 you can see that it wants to create an automation for me. 00:33:02.392 --> 00:33:04.912 Okay, and what exactly is it trying to do? 00:33:04.912 --> 00:33:08.532 Well, it's essentially trying to create a conversation 00:33:08.532 --> 00:33:10.812 that will be repeatable. 00:33:11.092 --> 00:33:12.912 Okay, so it creates this automation. 00:33:13.092 --> 00:33:14.332 This is the name of the automation. 00:33:14.972 --> 00:33:21.092 right? This is the prompt. This right here is the prompt. And the prompt is summarize yesterday's 00:33:21.092 --> 00:33:26.172 Git activity for standup, grounding rules, et cetera, et cetera. We can select a work tree. 00:33:26.172 --> 00:33:34.152 We can select a project here. And then we can select the time where it's going to run over and 00:33:34.152 --> 00:33:40.132 over again, right? So with this kind of automation, you may want to run it on weekdays at 9 a.m. 00:33:40.132 --> 00:33:47.772 but you can also select it, make it hourly, daily, weekly, etc., etc. And you can also change the time, 00:33:47.972 --> 00:33:54.032 obviously. Now, here you can change the model, and here you can change the reasoning level. Now, 00:33:54.092 --> 00:33:58.592 with this kind of automation, you don't really need a high reasoning. Medium is going to be just 00:33:58.592 --> 00:34:03.732 fine. And after you're done, you can simply click create, and now you're going to have an automation 00:34:03.732 --> 00:34:09.552 that will run every weekday at 9 a.m. running this prompt. 00:34:09.692 --> 00:34:11.552 And remember, this is a special prompt. 00:34:11.732 --> 00:34:14.352 Here, you're asking it to consult Git activity. 00:34:14.812 --> 00:34:21.652 And so the idea is you may have Git connected via a plugin or something else, 00:34:22.072 --> 00:34:24.752 and it's going to connect to your Git environment 00:34:24.752 --> 00:34:26.972 and then figure something out for you. 00:34:26.992 --> 00:34:30.052 And that's going to run every weekday at 9 a.m., right? 00:34:30.052 --> 00:34:38.232 So instead of you needing to jump into Codex first thing weekday morning and execute this 00:34:38.232 --> 00:34:42.112 prompt manually, you can create an automation to do just that. 00:34:42.192 --> 00:34:44.512 If you scroll down, you can see some other automations here. 00:34:44.732 --> 00:34:47.852 You have incidents, you have code quality, right? 00:34:47.932 --> 00:34:52.212 Maybe you want to run a code quality check every 24 hours. 00:34:52.352 --> 00:34:55.692 Well, you can click here daily at 9 a.m., right? 00:34:55.692 --> 00:35:04.332 scan recent commits since the last run or last 24 hours for likely bugs and propose minimal fixes. 00:35:04.672 --> 00:35:12.892 That's another very, very useful automation. Repo maintenance. You have here growth and 00:35:12.892 --> 00:35:20.332 exploration. Click here. From recent PRs and reviews suggest next skills to deepen. This is 00:35:20.332 --> 00:35:25.852 great, right? So automations, they could be used for pretty much anything, right? And they are, 00:35:25.992 --> 00:35:29.512 you know, it doesn't really matter what kind of niche you're in. You don't need to be in software 00:35:29.512 --> 00:35:35.332 development or project management or anything like that. You can be a writer, right? You want 00:35:35.332 --> 00:35:39.812 a status. You're writing maybe a thousand words every day. You know, you can have an automation 00:35:39.812 --> 00:35:46.372 that checks for spelling, grammar errors that you may have done, and then it may suggest some fixes 00:35:46.372 --> 00:35:50.672 this. And also another automation that gives you more ideas, you know, to break through writer's 00:35:50.672 --> 00:35:58.672 block. And that can run every morning at 9 or 10 a.m. Okay. And so automations are very, very useful 00:35:58.672 --> 00:36:05.712 if you need some kind of a repeatable structure in your workflow. And I want to talk a little bit 00:36:05.712 --> 00:36:13.812 about MCP. So MCP or model context protocol is very, very important. Okay. So if you press 00:36:13.812 --> 00:36:18.692 command comma or you go into settings over here, you're going to be on this screen. And if you 00:36:18.692 --> 00:36:25.472 choose MCP servers, you're going to see all your MCP servers that you have here configured. And you 00:36:25.472 --> 00:36:32.072 can also see whether they're enabled or not. Now, an MCP server is basically a server. It's a remote 00:36:32.072 --> 00:36:38.632 system that your codex instance can connect to. So as you can see, I have a bunch of MCP servers here 00:36:38.632 --> 00:36:40.732 that do all kinds of interesting things. 00:36:40.832 --> 00:36:44.572 For instance, I have here a Stitch MCP server configured. 00:36:45.012 --> 00:36:47.472 I have here a Superbase MCP server. 00:36:48.032 --> 00:36:51.272 I also have, you know, Flutter Flow Designer, Flowbase, 00:36:51.372 --> 00:36:54.612 a bunch of apps that support MCP. 00:36:55.012 --> 00:36:56.752 And when you connect to them, 00:36:56.992 --> 00:36:59.732 Codex is acting like an MCP client. 00:36:59.732 --> 00:37:03.092 So you have that same client-server paradigm. 00:37:03.452 --> 00:37:05.672 Now, why would you want to use an MCP server 00:37:05.672 --> 00:37:08.692 to connect to something like Superbase or something else? 00:37:09.092 --> 00:37:11.052 Well, the reason is very simple. 00:37:11.612 --> 00:37:15.172 You want Codex to do all the administration, 00:37:15.432 --> 00:37:17.152 all the work for you, right? 00:37:17.232 --> 00:37:20.612 So if you're building an app using something like Superbase, 00:37:20.672 --> 00:37:23.552 and we're gonna touch upon that a little bit later 00:37:23.552 --> 00:37:27.412 in the video, you can set up Superbase yourself. 00:37:27.572 --> 00:37:28.752 You can configure all of that. 00:37:28.812 --> 00:37:31.312 That takes time, but it's very, very doable. 00:37:31.312 --> 00:37:38.152 or you can simply configure a Superbase MCP server in your Codex instance. 00:37:38.772 --> 00:37:47.032 And that will allow Codex to use that MCP server to essentially manage this remote server, 00:37:47.312 --> 00:37:49.732 this tool, this app for you. 00:37:50.152 --> 00:37:52.832 And as you're going to see a little bit later in this tutorial, 00:37:53.072 --> 00:37:57.512 this is very, very helpful to us because it saves a lot of time 00:37:57.672 --> 00:38:01.172 and it enables things that we couldn't really do before. 00:38:01.312 --> 00:38:09.272 because now Codex understands one piece, and via MCP, it can get more context and create a much 00:38:09.272 --> 00:38:15.872 more robust app for you, or a tool for you, or anything else, a system, if you will, because now 00:38:15.872 --> 00:38:21.452 it can connect to other remote systems and essentially consult that data with the data we 00:38:21.452 --> 00:38:28.192 already have, such as the code or things it has been working on, and figure out a unified solution. 00:38:28.192 --> 00:38:30.752 And this is extremely helpful to us, okay? 00:38:31.192 --> 00:38:33.952 And so there's a couple of ways that you can add a server. 00:38:34.092 --> 00:38:36.592 You can click here and you can fill all of this manually. 00:38:37.152 --> 00:38:42.632 Or you can simply tell Codex, set up and activate a Superbase MCP server. 00:38:42.692 --> 00:38:44.212 And it's going to figure out how to do that. 00:38:44.252 --> 00:38:45.272 It's going to search for it. 00:38:45.312 --> 00:38:46.612 It's going to figure out the specs. 00:38:47.072 --> 00:38:48.572 And it's going to set it up for you. 00:38:48.592 --> 00:38:50.472 And the same thing for all of these other ones. 00:38:50.732 --> 00:38:54.892 Now, after setting up the MCP server, you can simply tell Codex to use it. 00:38:54.892 --> 00:39:05.472 So I can say something like, use the Superbase MCP server to query data or check how many tables we have or pretty much anything else. 00:39:05.472 --> 00:39:12.952 And it's going to go ahead and connect to your Superbase instance in this example via the configured MCP server. 00:39:14.555 --> 00:39:20.335 server. Now that we have laid the foundation and before we start building the real app, 00:39:20.855 --> 00:39:27.155 let's talk about the ideal codex workflow. What is the best way to approach it? Before we begin 00:39:27.155 --> 00:39:32.295 building our app, you want to establish the workflow that you're going to use again and again. 00:39:32.875 --> 00:39:41.375 The loop is simple. Inspect, plan, edit, verify, and report. That sounds basic, but it is the 00:39:41.375 --> 00:39:48.355 difference between using Codex as a random code generator and using Codex as a controlled build 00:39:48.355 --> 00:39:55.915 partner. The mistake a lot of people make is that they jump straight to build this app or fix this 00:39:55.915 --> 00:40:02.875 problem without giving the agent a clean process. That can work for small tasks, 00:40:02.875 --> 00:40:09.355 but it breaks down quickly on real projects. For a serious build, you want Codex to understand the 00:40:09.355 --> 00:40:18.315 repo first, explain the plan, make a focus change, verify the result, and then report back in a way 00:40:18.315 --> 00:40:25.195 that you can review. A good Codex prompt is not just a request, it is a small project brief. 00:40:25.195 --> 00:40:31.115 The better the prompt is, the easier it is for Codex to understand the current state, 00:40:31.115 --> 00:40:37.035 choose the right amount of work, and verify the result. The basic structure is simple. 00:40:37.035 --> 00:40:45.435 Explain the goal, give the relevant context, define what should change, define what should not change, 00:40:45.435 --> 00:40:51.115 and tell Codex how to verify the work. If the task is risky or unclear, 00:40:51.115 --> 00:40:58.155 ask Codex to inspect first and make a plan before editing. For instance, instead of saying 00:40:58.155 --> 00:41:05.995 build the app, I would say inspect the project first, do not edit yet, identify the existing 00:41:05.995 --> 00:41:13.035 structure, propose the smallest first version, list the files you expect to touch, and explain 00:41:13.035 --> 00:41:20.715 how you will verify. That gives Codex a much cleaner job. For implementation prompts, I want 00:41:20.715 --> 00:41:28.315 the request to be specific enough that Codex can act, but not so over-specify that I accidentally 00:41:28.315 --> 00:41:35.435 force the wrong solution. I usually describe the outcome I want, the constraints I care about, 00:41:35.435 --> 00:41:42.235 and the checks that need to pass. Then Codex can use the actual project context to choose the 00:41:42.235 --> 00:41:48.075 cleanest path. As part of this workflow, I want to introduce you to one of the most important Codex 00:41:48.075 --> 00:41:56.975 features. Plan mode. Plan mode is a superpower that I use for 80 to 90% of my prompts. There are 00:41:56.975 --> 00:42:04.375 two main benefits to using the plan mode. First, it's a form of brainstorming where the model 00:42:04.375 --> 00:42:11.535 cannot change or alter your files. Second, it's a way for the model to clarify your requests 00:42:11.535 --> 00:42:18.055 by asking follow-up questions. This is especially useful when the request is under specified. 00:42:18.075 --> 00:42:23.875 If I say build the booking flow, there are a lot of hidden decisions inside that request. 00:42:24.495 --> 00:42:26.295 What fields does the form need? 00:42:26.755 --> 00:42:29.095 What status should the booking start with? 00:42:29.515 --> 00:42:32.195 Where should the booking appear for the helper? 00:42:32.795 --> 00:42:35.295 What should happen after submission? 00:42:35.655 --> 00:42:42.375 Plan mode gives Codex a chance to surface those questions before it edits the app. 00:42:42.495 --> 00:42:45.195 I also use plan mode as a quality filter. 00:42:45.195 --> 00:42:53.655 If the plan is vague, too large, or misses something important, I know the implementation will probably be messy. 00:42:53.855 --> 00:43:02.335 If the plan is specific, scope, and easy to verify, then the actual coding step becomes much safer. 00:43:02.575 --> 00:43:08.275 So you want to use plan mode initially while brainstorming, and also as you enhance your app, 00:43:08.275 --> 00:43:14.975 because it gives the model a chance to ask follow-up questions to ensure there's no misunderstanding. 00:43:15.535 --> 00:43:20.935 Now, if you're working with an existing repo, the first step should always be to inspect. 00:43:21.595 --> 00:43:29.415 Codex should understand the files, the app structure, the current state, and the goal before changing anything. 00:43:29.775 --> 00:43:34.295 Then it should plan the work in a way that is small enough to review, 00:43:34.295 --> 00:43:41.255 Only then, once Codex is fully in sync with your goals, should it make the actual edits 00:43:41.255 --> 00:43:42.615 and write code. 00:43:42.615 --> 00:43:47.975 Once the code is written, it should verify the code with the browser, terminal, using 00:43:47.975 --> 00:43:50.255 tests or the build output. 00:43:50.255 --> 00:43:56.595 And finally, it should report what changed and what still needs attention. 00:43:56.595 --> 00:43:58.635 Verification is the part I want to emphasize. 00:43:58.635 --> 00:44:03.435 A task is not finished just because Codex wrote code. 00:44:03.435 --> 00:44:06.255 For UI work, I want to see the browser. 00:44:06.255 --> 00:44:12.595 For backend work, I want to see the function call, the dashboard row, or the test results. 00:44:12.595 --> 00:44:18.315 For deployment work, I want the live URL and a real smoke test. 00:44:18.315 --> 00:44:23.775 That habit keeps the workflow grounded in evidence instead of trusting that the code 00:44:23.775 --> 00:44:25.675 is probably fine. 00:44:25.675 --> 00:44:30.915 Additionally, you always want to break big tasks into smaller ones. 00:44:30.915 --> 00:44:36.155 Instead of asking Codex to build the whole marketplace as one prompt, you want to ask 00:44:36.155 --> 00:44:43.575 it to plan the app, build the first UI shell, wire one initial database-backed version, 00:44:43.575 --> 00:44:48.155 add the booking flow, add the helper dashboard, and so on. 00:44:48.155 --> 00:44:53.675 Each step has a clear target and a clear way to check whether it worked. 00:44:53.675 --> 00:44:58.915 A good Codex task should usually fit into one reviewable outcome. 00:44:58.915 --> 00:45:02.975 Create the first static marketplace homepage is reviewable. 00:45:02.975 --> 00:45:07.975 Wire service listings from Convex is reviewable. 00:45:07.975 --> 00:45:13.295 Add booking creation and verify the booking row appears is reviewable. 00:45:13.295 --> 00:45:19.475 Build the whole app is not reviewable because there are too many decisions happening at 00:45:19.475 --> 00:45:20.475 once. 00:45:20.475 --> 00:45:23.775 So the workflow is not just a technical process. 00:45:23.775 --> 00:45:26.995 It is also a way to stay in control. 00:45:26.995 --> 00:45:33.435 We let Codex do meaningful work, but we keep the work divided into chunks where we can 00:45:33.435 --> 00:45:40.215 understand the change, approve the direction, and catch problems before they spread. 00:45:40.215 --> 00:45:45.355 And so here I am back in Codex, and you can enable plan mode by pressing Shift-Tab, and 00:45:45.355 --> 00:45:46.855 here you have plan mode. 00:45:46.855 --> 00:45:49.415 Or you can click here and toggle this. 00:45:49.415 --> 00:45:54.015 I typically just use Shift-Tab because it's a lot easier and it's a lot faster. 00:45:54.015 --> 00:45:57.675 And then whenever I'm in plan mode, I can start brainstorming. 00:45:57.675 --> 00:46:03.315 And not only that, it's useful because Codex will not make changes whenever it's in plan 00:46:03.315 --> 00:46:04.315 mode. 00:46:04.315 --> 00:46:09.255 And it also gives Codex to come back to you with follow-up, clarifying questions. 00:46:09.255 --> 00:46:15.615 And I find that super, super helpful because we always want to make sure that Codex knows 00:46:15.615 --> 00:46:18.835 exactly what it's doing. 00:46:18.835 --> 00:46:23.495 The last thing that we want is for Codex to assume something. 00:46:23.495 --> 00:46:25.495 We never wanted to assume anything. 00:46:25.495 --> 00:46:28.915 We always want to make sure that we are on the same page. 00:46:28.915 --> 00:46:33.655 And so let's say I have a convo here going and I want to build an architecture. 00:46:33.655 --> 00:46:37.935 I want to build some kind of an intricate architecture. 00:46:37.935 --> 00:46:41.615 And I want to make sure that we built out an architecture. 00:46:41.615 --> 00:46:47.155 I may not know exactly how far I want to go, exactly all the details, but I want to make 00:46:47.155 --> 00:46:49.895 sure that Codex is on the same page. 00:46:49.895 --> 00:47:02.475 I can say something like, come up with an architecture that will allow me to create both web and mobile and desktop versions of the app. 00:47:02.595 --> 00:47:05.435 Ensure it is fast and robust. 00:47:06.495 --> 00:47:13.155 I'm here in plan mode, and typically with this kind of prompt, it's not clear what I want. 00:47:13.275 --> 00:47:14.555 I don't even know what I want. 00:47:14.675 --> 00:47:20.075 I want Codex to figure it out, but I want Codex to come back to me and confirm with me. And so, 00:47:20.175 --> 00:47:24.815 if we execute this prompt, hopefully it's going to ask me some follow-up questions. Let's see. 00:47:24.815 --> 00:47:31.515 And so as expected, Codex came back with a question, which cross-platform strategy should 00:47:31.515 --> 00:47:37.275 the architecture optimize for? And there are two questions, okay? Do we want shared core native 00:47:37.275 --> 00:47:43.295 shells? And you can click here and you can get a little detail. Use shared TypeScript domain logic 00:47:43.295 --> 00:47:50.395 with separate Expo mobile, et cetera. Do we want a one universal app or do we want web-first 00:47:50.395 --> 00:47:57.035 wrappers, right? Because I asked for a cross-platform product, but there's many ways of 00:47:57.035 --> 00:48:02.555 doing it, and there's many trade-offs with each approach. And so it came back to me, 00:48:02.715 --> 00:48:08.835 and it wants to clarify one universal app, this or that. So I'm going to say this one. I'm going to 00:48:08.835 --> 00:48:14.455 go with recommended. And now it wants to know what should the app support for data and reliability. 00:48:14.455 --> 00:48:21.355 offline first cloud sync cloud only real time or local only and you can click and you can hover 00:48:21.355 --> 00:48:28.375 over the little i to get more details users can work can work offline then sync across devices 00:48:28.375 --> 00:48:34.255 cloud only simpler shared back and with live updates but weaker offline behavior now here 00:48:34.255 --> 00:48:40.435 you can also tell codex something else you can say well i want this this this this right or you 00:48:40.435 --> 00:48:45.975 can press escape and you can ask Codex to explain the question. I can say something like this, 00:48:46.335 --> 00:48:53.255 explain the last question in simple terms. Okay. I don't need to answer it right away. I can get 00:48:53.255 --> 00:48:57.915 Codex to kind of walk me through it. Right. Explain the last question. Let's see what it says. 00:48:57.915 --> 00:49:05.275 I was asking two choices. How should data work? My recommendation, shared code and native shells 00:49:05.275 --> 00:49:10.715 plus offline first cloud sync if you want this to become a serious app so it tells you these things 00:49:10.715 --> 00:49:17.515 and so you don't need to pick it pick a choice or tell it something else you can close that and you 00:49:17.515 --> 00:49:25.195 can ask codex to clarify and now what we can do is ask me those questions again you can do that 00:49:25.195 --> 00:49:28.875 or you can simply answer it here it doesn't matter so if you do that it's going to come back with 00:49:28.875 --> 00:49:33.595 that questionnaire again and here are the questions i'm going to say this and now i want to say this 00:49:33.595 --> 00:49:37.075 because I understood what it was asking me. 00:49:37.175 --> 00:49:37.755 Got it. 00:49:37.815 --> 00:49:38.955 Your choices are, 00:49:39.075 --> 00:49:41.035 that means the architecture should prioritize 00:49:41.035 --> 00:49:43.435 a shared TypeScript app, 00:49:43.555 --> 00:49:45.795 a brain used by this, this, this, this. 00:49:45.935 --> 00:49:46.475 And that's good. 00:49:46.535 --> 00:49:48.255 And now I can exit the plan mode 00:49:48.255 --> 00:49:49.955 and I can say, go ahead and do it. 00:49:50.115 --> 00:49:51.555 Go and implement this. 00:49:51.755 --> 00:49:53.735 Something like this or something more specific. 00:49:53.955 --> 00:49:56.975 And so plan mode is something that I use all the time. 00:49:57.215 --> 00:50:00.055 And you should definitely make it an integral part 00:50:00.055 --> 00:50:02.375 of your workflow as well. 00:50:03.595 --> 00:50:08.715 Now I want to talk to you about some advanced Codex workflow techniques. 00:50:08.715 --> 00:50:13.155 These are the little tips and tricks that I use all the time and will greatly help you when using 00:50:13.155 --> 00:50:19.295 Codex to build apps and solve problems. One thing I do all the time is asking Codex to create a 00:50:19.295 --> 00:50:25.175 handoff before I start a new thread. This is useful when a thread has gotten long, when the context 00:50:25.175 --> 00:50:30.395 has been compacted, or when I want to move from planning into implementation with a cleaner 00:50:30.395 --> 00:50:36.775 workspace. A good handoff is not a vague summary. I want the current state, the files that changed, 00:50:36.875 --> 00:50:43.695 the commands that were run, what still needs to happen, and any risks or open decisions. That way, 00:50:43.775 --> 00:50:49.675 the next codex thread can pick up the work without rereading the entire conversation or repeating 00:50:49.675 --> 00:50:55.995 mistakes. There are two main reasons that you may want to do that. The first reason is that after a 00:50:55.995 --> 00:51:03.135 while, this conversation here, it starts to degrade. As you keep typing new prompts and as the model 00:51:03.135 --> 00:51:10.755 answers, the convo starts to degrade. Now, Codex tells you that it automatically compacts its 00:51:10.755 --> 00:51:17.775 context. And that is true. You do not need to start a new convo every time. It does automatically 00:51:17.775 --> 00:51:24.395 compact it. But you're going to notice that as your conversations get long and you keep asking 00:51:24.395 --> 00:51:30.455 questions and it keeps answering, quality of the responses will degrade. And moreover, you know, 00:51:30.535 --> 00:51:35.675 your conversation is going to get fairly long and that might, you know, degrade the performance of 00:51:35.675 --> 00:51:42.255 the app itself. And that right there is a good use case to create a brand new convo using the 00:51:42.255 --> 00:51:48.455 handoff as the starting point. Another really, really good reason to create a new convo with a 00:51:48.455 --> 00:51:54.615 handle is when you're trying to solve a problem, but the model is not getting you the solution that 00:51:54.615 --> 00:51:59.115 you want. And so if you're trying to solve a particular problem and you've prompted the model 00:51:59.115 --> 00:52:04.175 a couple of ways and it's trying, it's giving you answers, but those answers are not ideal. 00:52:04.395 --> 00:52:09.075 It doesn't give you the right algorithm. It doesn't give you the right solution. There is a high chance 00:52:09.075 --> 00:52:14.095 that each additional prompt is not going to get you closer to a solution. So when you experience 00:52:14.095 --> 00:52:18.895 something like that, the best thing that you can do would be starting over by creating a new 00:52:18.895 --> 00:52:24.915 conversation and giving the model a handoff with the things that it has done and the things that 00:52:24.915 --> 00:52:30.415 are not working and where you are right now and selling the model as part of that handoff prompt 00:52:30.415 --> 00:52:36.855 to work on a different solution. And because AI can be fairly random in some ways, creating a new 00:52:36.855 --> 00:52:41.975 conversation usually gives you a different solution. That solution might actually work. 00:52:41.975 --> 00:52:48.975 Now, there are various ways to create this handoff prompt that's going to give you a handoff for a new conversation. 00:52:49.275 --> 00:52:53.435 One of the simplest ways would be by typing something like this. 00:52:53.515 --> 00:52:59.835 Okay, this is a very, very simple prompt that still delivers a fairly high quality handoff. 00:53:00.015 --> 00:53:06.535 Okay, so you can type create a detailed handoff prompt that I can use for a new Codex Convo. 00:53:06.775 --> 00:53:11.795 Okay, so let's go ahead and send this and see what answer we get. 00:53:11.795 --> 00:53:17.835 And this is the response we got. I want to design a fast, robust, cross-platform project management 00:53:17.835 --> 00:53:22.755 app. So it's essentially summarizing everything that has happened in the convo, right? This is 00:53:22.755 --> 00:53:27.875 the context. This is the product direction. This is the architecture preference. Please produce a 00:53:27.875 --> 00:53:33.315 detailed architecture plan covering all this important, right? Also some constraints. And so 00:53:33.315 --> 00:53:38.975 what you can do is you can copy that and then you can go ahead and create a brand new convo. For 00:53:38.975 --> 00:53:44.255 instance, you can click here and you can simply paste it. Okay, well, you want to delete that, 00:53:44.355 --> 00:53:49.375 you want to delete like the top, you want to delete that. And when you paste it, that's going 00:53:49.375 --> 00:53:55.475 to create a conversation and the model can simply continue where the other conversation ended. That 00:53:55.475 --> 00:54:02.455 is one way to do it. Another way to do it is by giving it a more detailed handoff prompt. So let's 00:54:02.455 --> 00:54:07.995 go back here and let's go ahead and give it a slightly different prompt. Create a clean handle 00:54:07.995 --> 00:54:14.515 for a new codex thread. Include all of this. Do not make any changes. So this prompt is slightly 00:54:14.515 --> 00:54:19.555 more detailed, and you can bet that it's going to give you a higher quality handoff. Okay, so let's 00:54:19.555 --> 00:54:26.215 go ahead and run this, and then we can compare the two handoffs and see which one is more detailed. 00:54:26.535 --> 00:54:33.175 Now take a look at this handoff right here. Look at how much more detail this handoff versus this 00:54:33.175 --> 00:54:38.395 handoff right here. Now, this handoff would definitely work, but this handoff would work 00:54:38.395 --> 00:54:43.495 even better. It's going to result in a higher quality conversation. Okay, so given an option, 00:54:43.715 --> 00:54:49.455 you can certainly use a prompt such as this, but it's a lot better to use something like this 00:54:49.455 --> 00:54:54.035 that's more detailed and it's going to save you a lot of time in the long run. 00:54:55.544 --> 00:55:00.424 save you a lot of time in the long run. The next practical habit is using Git as a 00:55:00.424 --> 00:55:05.764 checkpoint system. Before I let Codex do meaningful work, I want to know whether the current state 00:55:05.764 --> 00:55:12.644 is clean. After each milestone, I want a diff that is small enough to review and explain. That is what 00:55:12.644 --> 00:55:19.444 keeps an agentic workflow from turning into one giant mystery edit. The useful trick is to make 00:55:19.444 --> 00:55:25.204 Codex summarize the diff in plain English. I do not only want to know what files change, I want to 00:55:25.204 --> 00:55:31.124 know why they changed, whether each change belongs to the task, and whether anything looks unrelated 00:55:31.124 --> 00:55:38.104 before I accept it or move on. So when you are working in Codex, you do not want to be just 00:55:38.104 --> 00:55:45.004 creating edits without recording what the edit is all about. And in software development, you want 00:55:45.004 --> 00:55:52.304 to be using a source control system such as Git. We have here a convo where we were building an app 00:55:52.304 --> 00:55:59.524 and in this particular instance, we did not use Git. And so I do not know, I have no way to check 00:55:59.524 --> 00:56:06.344 which changes were made where. I have no way to revert the changes. I have no way to see what the 00:56:06.344 --> 00:56:13.504 actual change represents. And if working in bigger teams, I do not know who was the person responsible 00:56:13.504 --> 00:56:18.624 for the change. Now, in this convo, we have another problem. The current working directory 00:56:18.624 --> 00:56:24.304 is missing. So in this case, what we can do is we can take a handoff prompt and we can create a 00:56:24.304 --> 00:56:31.084 brand new project, insert that handoff prompt, start a new convo, and then enable git and set 00:56:31.084 --> 00:56:35.444 up so that we have git control. So I'm going to go over here. I'm just going to do start from scratch. 00:56:35.504 --> 00:56:41.444 I'm going to paste this handoff prompt to start a brand new convo. And I'm going to preface it 00:56:41.444 --> 00:56:50.444 by selling it to create a git repository. Create a git repo if it doesn't exist and do an initial 00:56:50.444 --> 00:56:56.964 commit with the code. So I'm going to run that. And the idea is we are going to initialize git 00:56:56.964 --> 00:57:03.004 if needed and then commit the current code as is. All right. So what it did was it initialized a git 00:57:03.004 --> 00:57:09.484 repo in this directory and made an initial commit, initial architecture plan here. Okay. The workspace 00:57:09.484 --> 00:57:14.404 was empty when inspected. There was nothing there. We just created a brand new project and it 00:57:14.404 --> 00:57:20.044 essentially created an architecture. And so at this point we have here a git repo, which means that 00:57:20.044 --> 00:57:25.404 each additional change will be automatically tracked. So for instance, I can say something like 00:57:25.404 --> 00:57:33.964 make the smallest possible change a route that displays hello world. Okay, let's go ahead and run 00:57:33.964 --> 00:57:39.724 that. So it now created this index.html. We're going to open it and it says hello world. And so 00:57:39.724 --> 00:57:47.544 now what we can do is we can say check the git status. And obviously this file is not going to 00:57:47.544 --> 00:57:53.804 be in our Git, right? You see, this is not tracked, an untracked file. And so what we want is we want 00:57:53.804 --> 00:58:01.064 to commit index.html as initial commit, because in Git, you can have files that are tracked and also 00:58:01.064 --> 00:58:05.564 files that are not tracked. The files that are not tracked are the files you don't really care about, 00:58:05.624 --> 00:58:11.964 right? You don't really need to store them in Git. These could be like media files or generated files, 00:58:11.964 --> 00:58:17.784 code generated files that can always be regenerated. But for your actual code, you always 00:58:17.784 --> 00:58:23.524 want to be tracking them, right? So we have this commit, and now this file is going to be tracked, 00:58:23.664 --> 00:58:28.924 and it's going to be committed as well. Okay, so now it says committed as initial commit, right? 00:58:28.984 --> 00:58:35.064 We have this, it's now on main, which is a type of branch. And so now we go into changes, you can see 00:58:35.064 --> 00:58:40.024 that we can select the branch here. And as you can see here, it says no file changes yet. And that is 00:58:40.024 --> 00:58:46.684 because we have not made any changes since tracking that file. So what I'm going to do now is that make 00:58:46.684 --> 00:58:53.764 index.html output hello, James. That has updated. And now it says hello, James. And now what we can 00:58:53.764 --> 00:59:00.564 do is we can commit it. Commit index.html. And now if you type give me git status, it's going to tell 00:59:00.564 --> 00:59:06.104 you that it hasn't been committed, right? It's modified. It's tracked, but it hasn't been committed. 00:59:06.104 --> 00:59:08.664 Okay, it has been modified and uncommitted, right? 00:59:09.124 --> 00:59:11.544 You see this M, which means this has been modified. 00:59:11.724 --> 00:59:15.024 So we're going to do commit index.html. 00:59:15.304 --> 00:59:18.764 And it will also generate a default message. 00:59:18.964 --> 00:59:20.164 Here it has committed it. 00:59:20.324 --> 00:59:22.604 We can click here and we can select review. 00:59:22.964 --> 00:59:26.584 And you can select the type of change you want to see. 00:59:26.664 --> 00:59:30.524 You can see on stage, stage, branch, or last turn. 00:59:30.764 --> 00:59:34.504 And when you click on last turn, you can see what was changed. 00:59:34.504 --> 00:59:40.024 because we are using source control. We can see the stuff that was changed. As you can see, 00:59:40.504 --> 00:59:46.124 this is the one line that was changed. Red means it was deleted, and green means it was inserted. 00:59:46.384 --> 00:59:50.904 So this was deleted, and this was inserted. We basically changed the message that it says from 00:59:50.904 --> 00:59:58.004 hello world to hello James. And so Git is very, very important. If you're working on any kind of 00:59:58.004 --> 01:00:03.924 project, anything beyond something super simple, you want to create a repo, and you want to 01:00:03.924 --> 01:00:12.724 implement source control into your workflow. One advanced trick that becomes more useful 01:00:12.724 --> 01:00:19.064 as projects get bigger is working with Git worktrees. A worktree is a separate working copy 01:00:19.064 --> 01:00:25.064 of the same repo connected to a different branch. The practical benefit is that you can keep one 01:00:25.064 --> 01:00:31.904 version of the app stable while trying a risky feature, UI direction, or refactor somewhere else. 01:00:31.904 --> 01:00:34.104 This matters a lot with agentic coding. 01:00:34.504 --> 01:00:39.684 If you want to try two approaches in parallel or keep a clean version ready for recording 01:00:39.684 --> 01:00:45.024 while another codex thread keeps building, a worktree gives you that separation. 01:00:45.384 --> 01:00:49.964 Now, what's nice about worktrees is that they give you parallelism. 01:00:50.204 --> 01:00:54.964 So if you are working on multiple features in your app, maybe you're using subagents 01:00:54.964 --> 01:01:02.704 or something else, it's important that no two processes work on the same file at the same time 01:01:02.704 --> 01:01:08.104 because that's going to create corruption. And so what you typically end up doing is you create a 01:01:08.104 --> 01:01:14.004 work tree for a specific feature and you work on that work tree. And when you're done, you merge 01:01:14.004 --> 01:01:19.844 the changes back onto your main tree. Now, that doesn't mean you can only create one work tree. 01:01:19.844 --> 01:01:30.544 You can create multiple work trees, as many as you want, and you can also work on the same feature because after one work tree is done, it's going to merge to main. 01:01:30.944 --> 01:01:33.884 And if there's a conflict, it's going to resolve that conflict. 01:01:34.044 --> 01:01:42.024 And then another work tree, when it is done, it's going to also merge into your main branch where your development is happening. 01:01:42.164 --> 01:01:49.244 And if there's a conflict because they ended up working on the same feature, it will also resolve that conflict so that there's no corruption. 01:01:49.244 --> 01:01:52.484 Now, this is a feature I use all the time in big projects. 01:01:52.724 --> 01:01:55.104 Now, let's say I'm working on this app over here. 01:01:55.204 --> 01:01:59.764 You can ask Codex to work in main without creating any work trees. 01:01:59.964 --> 01:02:04.664 Or I can ask it to create a new work tree while it makes changes. 01:02:04.904 --> 01:02:07.084 So let's continue what we were doing. 01:02:07.204 --> 01:02:11.684 So let's say I want to change this index.html, and I wanted to say something else. 01:02:11.764 --> 01:02:17.584 So I'm going to go ahead and tell it, make index.html output hello planet. 01:02:17.584 --> 01:02:21.504 But this time, we want to make sure that it works in a different work tree. 01:02:21.824 --> 01:02:27.764 So what I'm going to do is I'm going to say work in a new work tree and then merge cleanup 01:02:27.764 --> 01:02:29.064 after you're done. 01:02:29.344 --> 01:02:31.464 Okay, so we're going to go ahead and run this. 01:02:31.684 --> 01:02:35.344 And now it's not going to modify the file on our main branch. 01:02:35.544 --> 01:02:40.884 It's going to branch out, do the work, and then come back and merge the changes back 01:02:40.884 --> 01:02:41.064 in. 01:02:41.204 --> 01:02:44.064 And so as you can see here, there's more stuff happening. 01:02:44.064 --> 01:02:47.384 I'll make this in a separate Git work tree, commit there, 01:02:47.604 --> 01:02:49.824 fast forward merge changes to main, 01:02:49.924 --> 01:02:52.164 and then remove the work tree and delete the branch. 01:02:52.464 --> 01:02:55.544 And that's exactly what it did, except it did it very, very... 01:02:56.804 --> 01:03:04.024 you know, a very small change. But you saw it doing all that. And before you know it, it did all that, 01:03:04.264 --> 01:03:09.444 made the change, merged everything back, and deleted the worktree. And so that was a very, 01:03:09.444 --> 01:03:15.484 very small change. Now, another thing that you can do is you can click here and you can fork this 01:03:15.484 --> 01:03:22.364 whole convo in a separate work tree, right? So if I click over here, that will fork it into a separate 01:03:22.364 --> 01:03:28.204 work tree. And here you can see we're working in a separate work tree here, okay? So now as we're 01:03:28.204 --> 01:03:34.504 doing work, we need to constantly tell Codex, hey, you know, create a new work tree, clean up, 01:03:34.504 --> 01:03:35.744 and do all this when you're done. 01:03:35.904 --> 01:03:38.924 We can continue working and then merge our changes. 01:03:39.204 --> 01:03:41.124 So for instance, I can say something like 01:03:41.124 --> 01:03:43.164 to say hello USA. 01:03:43.604 --> 01:03:44.564 I can simply do that. 01:03:44.684 --> 01:03:46.844 I don't need to tell it to work in a separate work tree 01:03:46.844 --> 01:03:49.144 because we are isolated here. 01:03:49.244 --> 01:03:50.404 Okay, so here's the file. 01:03:50.524 --> 01:03:51.344 We can open it. 01:03:51.464 --> 01:03:52.584 Hello USA here. 01:03:52.684 --> 01:03:53.404 And so at this point, 01:03:53.404 --> 01:03:55.884 we have merged the work tree change into main 01:03:55.884 --> 01:03:58.304 and cleaned up the temporary work tree, right? 01:03:58.404 --> 01:03:59.984 Index now displays hello USA 01:03:59.984 --> 01:04:02.844 and we no longer have this temporary work tree. 01:04:02.844 --> 01:04:07.244 We've done everything that we needed to do separate from the main branch, and then we merged. 01:04:07.404 --> 01:04:12.964 And as far as we are concerned, this convo is now finished because it's tied to the old work tree, 01:04:13.104 --> 01:04:15.264 but we've did everything we needed to do. 01:04:15.404 --> 01:04:16.844 We've updated the files. 01:04:16.944 --> 01:04:18.624 We've merged back into main. 01:04:18.944 --> 01:04:22.724 And so now we can start a brand new convo to work on a different feature. 01:04:22.824 --> 01:04:26.024 And so this is really nice for feature isolation. 01:04:26.284 --> 01:04:29.604 Create a new work tree, work there, merge back into main, 01:04:29.604 --> 01:04:33.524 and then simply click here to archive this conversation. 01:04:36.404 --> 01:04:42.724 Another advanced trick is using sub-agents for parallel work. The idea is not to throw a whole 01:04:42.724 --> 01:04:47.924 project at a bunch of agents and hope it works. The useful version is much more controlled. 01:04:47.924 --> 01:04:53.524 One agent explores the codebase, another works on a clearly bounded part of the UI, 01:04:53.524 --> 01:04:59.044 another checks tests or reviews the results. The key is ownership. If you use sub-agents, 01:04:59.044 --> 01:05:04.404 You want each one to have a specific job, clear file area, and a clear output. 01:05:04.564 --> 01:05:09.084 That keeps the work parallel without turning it into a merge mess. 01:05:09.404 --> 01:05:14.484 Sub-agents are best when the tasks are independent enough to run side by side, 01:05:14.724 --> 01:05:17.844 but still simple enough to integrate at the end. 01:05:17.924 --> 01:05:23.644 Now, sub-agents is another really cool feature that will help speed up your workflows. 01:05:23.644 --> 01:05:32.344 And this is something that I use all the time, especially in big repos, in big code bases to do multiple tasks in parallel. 01:05:32.624 --> 01:05:32.804 All right. 01:05:32.844 --> 01:05:35.984 So here I have a very, very simple Kanban app. 01:05:36.224 --> 01:05:38.344 If I click over here, I have this. 01:05:38.524 --> 01:05:39.704 I can drag and drop. 01:05:39.824 --> 01:05:42.004 I can create new tasks, et cetera, et cetera. 01:05:42.244 --> 01:05:49.384 And so what I want to know is if I'm going to be building more and more features, complex stuff, new functionality, 01:05:49.384 --> 01:05:53.504 I want to use subagents to help me kind of make sense of it. 01:05:53.504 --> 01:05:58.604 and help me build it in the most efficient way possible. And so I'm going to paste this prompt 01:05:58.604 --> 01:06:04.084 here, plan how to split this feature across subagents, right? Do not edit files yet, recommend. 01:06:04.444 --> 01:06:10.684 We're going to jump into plan mode, preface this with the feature, add two party apps such as 01:06:10.684 --> 01:06:16.684 make.com, Zapier, et cetera. And so I'm going to leave it at this, and I'm going to go ahead and 01:06:16.684 --> 01:06:21.684 run this. And so let's go ahead and run this. And here we have the plan. The safest split 01:06:21.684 --> 01:06:26.724 is for the main thread to own architecture, shared data contracts. Subagents can work on 01:06:26.724 --> 01:06:34.364 isolated feature areas inside index.html, but they must not all edit the same broad sections at once. 01:06:34.624 --> 01:06:39.564 Okay, so we have main thread responsibilities, and then we have subagent delegation, 01:06:39.764 --> 01:06:45.744 integration settings, integration data model, webhook event dispatcher. So I'm going to copy 01:06:45.744 --> 01:06:50.924 this plan, and then I'm going to preface it by telling it spawn subagents right away to help 01:06:50.924 --> 01:06:55.984 design the third-party API functionality. Let's go ahead and run this. Right away, it's telling me 01:06:55.984 --> 01:07:01.864 I'll spawn the four focused subagents and keep the main thread responsible for the final. So as you 01:07:01.864 --> 01:07:06.984 can see, it's spawning them. And each subagent gets a prompt. It's basically like me creating 01:07:06.984 --> 01:07:11.804 a new conversation. You're a subagent one, integration. You're a subagent two, integration 01:07:11.804 --> 01:07:17.004 data model. You're a subagent three. And they're working independently. And here it tells you all 01:07:17.004 --> 01:07:22.244 four sub-agents are running. While they work, I'll inspect the current partial edit. And you can see 01:07:22.244 --> 01:07:27.144 these background agents here. Okay, so they're working in parallel. They're working on their own 01:07:27.144 --> 01:07:31.864 thing. They own different pieces of the app. And they're kind of working. And when they're done, 01:07:31.944 --> 01:07:37.524 they come back to this main agent, right, this convo here, and tell it what happened, right? 01:07:37.524 --> 01:07:42.184 They come back with a result. And so now it says the persistent sub-agent returned a cleaner data 01:07:42.184 --> 01:07:47.264 shape. And here you can actually click on any one of these and see what's happening. You can click 01:07:47.264 --> 01:07:52.364 here. You can come back. You can click on this one and see what it's doing. So this one is finished. 01:07:52.564 --> 01:07:57.564 Some are finished. How about this one? This one is also finished. And so that's how it works. And 01:07:57.564 --> 01:08:02.244 when they finish, they come back and then it decides what to do later. Maybe it's going to 01:08:02.244 --> 01:08:06.484 respawn them. Maybe it's going to spawn something else. Maybe it's done. They did what they needed 01:08:06.484 --> 01:08:12.044 to do. They finished their isolated task and their services are no longer needed. And again, 01:08:12.044 --> 01:08:17.464 sub-agents is something that I use all the time. I use it all the time, especially in big repos, 01:08:17.604 --> 01:08:24.464 because they help speed up the work by isolating different areas, different responsibility clusters 01:08:24.464 --> 01:08:28.224 to different agents. And that's a huge productivity boost. 01:08:30.924 --> 01:08:36.844 Now, in this section, we're going to bring all of the previous sections together by giving Codex 01:08:36.844 --> 01:08:43.624 project instructions in an agents.md file. This is where you can write down the rules you want 01:08:43.624 --> 01:08:50.024 Codex to follow every time it works in a specific repo. Which commands to run, which folders matter, 01:08:50.244 --> 01:08:57.044 which patterns to preserve, how to verify changes, and when to use work trees for subagents. This is 01:08:57.044 --> 01:09:02.644 useful because you do not want to repeat the same project rules in every prompt. If this project 01:09:02.644 --> 01:09:09.484 should always run a specific check, use a specific design system, avoid certain files, create work 01:09:09.484 --> 01:09:16.084 trees for risky experiments, or split large tasks into sub-agents, those instructions belong in 01:09:16.084 --> 01:09:23.984 agents.md. It turns your preferences into reusable project context. And here's a prompt that you can 01:09:23.984 --> 01:09:30.544 use which is going to draft agents.md for this project. Do not write the file yet. Include the 01:09:30.544 --> 01:09:35.484 project purpose, the main folders, work tree, subagents, stuff like that. So we're going to 01:09:35.484 --> 01:09:41.904 jump into plan mode. We're going to go ahead and run that. And here's the draft for this agents.md 01:09:41.904 --> 01:09:48.464 tailored to the current project, right? Project purpose, main folders, verification steps after 01:09:48.464 --> 01:09:55.064 changes. Serve the app locally, coding and design patterns to preserve. When codecs should use a 01:09:55.064 --> 01:10:00.944 work tree. Use a separate work tree when these happen. When codecs should use subagents. Use 01:10:00.944 --> 01:10:06.644 subagents when work can be split into clearly separate ownership areas such as these. What 01:10:06.644 --> 01:10:11.884 codecs should avoid changing without asking? All of this. Now, the beautiful thing about this 01:10:11.884 --> 01:10:20.504 agents.md file is that you no longer have to worry about asking codecs to spawn subagents 01:10:20.504 --> 01:10:26.744 or create separate work trees, it will be automatic. It's like saving you from typing 01:10:26.744 --> 01:10:32.564 those prompts every single time. So if you want to add a feature, well, you don't need to tell it, 01:10:32.644 --> 01:10:37.824 hey, create a new work tree or make sure you spawn sub-agents. It's going to be automatic. 01:10:38.104 --> 01:10:44.584 And so at this point, you want to review this proposal here and you want to save this as agents.md. 01:10:44.584 --> 01:10:47.444 So I'm going to say save it as agents. 01:10:47.664 --> 01:10:50.344 So now it's saved it as agents.md. 01:10:50.464 --> 01:10:54.224 You can click here and you can see the whole file right here. 01:10:54.384 --> 01:10:55.544 And this file will... 01:10:55.544 --> 01:11:01.984 will be used only for this specific project. They're based on a repo. So now for my next prompt, 01:11:02.084 --> 01:11:08.424 if it's a simple change, it's not going to create a work tree probably. And it will also not spawn 01:11:08.424 --> 01:11:14.184 subagents. But if it's a more complex change, it should probably create a work tree and maybe even 01:11:14.184 --> 01:11:19.384 spawn subagents. So let's go ahead and see if this works. So now let's go ahead and ask it, 01:11:19.384 --> 01:11:29.304 make a simple change that changes the title for the main index.html to Awesome Kanban app. 01:11:29.544 --> 01:11:34.784 Okay, I'm going to go ahead and run it directly. So now the title is Awesome Kanban app. Okay, 01:11:34.784 --> 01:11:54.684 But if we ask it something more complex, right, you know, figure out a third party, you know, integration, design, you know, support API calls or support MCP or anything like that, it should probably use subagents to figure it out and implement the changes in its own work tree. 01:11:54.684 --> 01:12:02.064 So let's see if this works. Add a robust API functionality for handling outgoing API calls 01:12:02.064 --> 01:12:07.924 and incoming webhooks. Okay, I'm going to jump into plan mode to see if it has any questions for 01:12:07.924 --> 01:12:14.104 me. See how it says agents.md explicitly says not to add a backend or proxy without asking. 01:12:14.424 --> 01:12:19.884 Okay, so it did consult this. So we're going to add a backend. We're going to create tasks. 01:12:19.884 --> 01:12:26.304 And let's see if it's going to create a work tree automatically and maybe even use subagents. 01:12:26.544 --> 01:12:30.984 Another question, should the new backend become the source of truth for Kanban tasks? 01:12:31.204 --> 01:12:35.784 Yes. Let's just go with recommended. Okay. We're going to expand this plan and we're going to see 01:12:35.784 --> 01:12:43.184 if it's going to be using a work tree or subagents for any of these things. Okay. So I do not see 01:12:43.184 --> 01:12:48.864 it's going to be using subagents. Update. So before we run it, let's ask it, do you plan 01:12:48.864 --> 01:12:54.844 on using a work tree for sub-agents for this task. There you go. Yes, for implementation, 01:12:55.244 --> 01:13:01.024 I'd use a work tree because this changes the project from a static-only app into a node 01:13:01.024 --> 01:13:06.844 server app with API routes and persistent states. I'd also use sub-agents, but only for bounded 01:13:06.844 --> 01:13:11.644 design review tasks. And so it's telling you right there that it will be using a work tree, 01:13:11.644 --> 01:13:16.584 and it will be using sub-agents. And you can bet that this would never happen if we didn't 01:13:16.584 --> 01:13:23.624 have this agents.md file. And so agents.md is super important. It's going to save you a lot of time 01:13:23.624 --> 01:13:30.184 because it basically codifies repeatable tasks. So you never have to re-prompt the same thing 01:13:30.184 --> 01:13:38.264 over and over again. Now, before we build real apps, there is one security habit you want to 01:13:38.264 --> 01:13:43.144 establish early. Codex can help inspect configuration, but we should be careful with 01:13:43.144 --> 01:13:48.984 secrets. An environment variable might be safe and public, like a front-end URL, or it might be 01:13:48.984 --> 01:13:55.524 private, like an API key or deploy token. These should not be casually pasted into a prompt or 01:13:55.524 --> 01:14:01.664 committed into the repo. The other important thing is that local config and deployment config are not 01:14:01.664 --> 01:14:07.924 the same thing. A local.n file helps the app run on my machine, but Vercel does not automatically 01:14:07.924 --> 01:14:13.804 copy that file into production. For a deployed app, the required variables need to exist in the 01:14:13.804 --> 01:14:19.644 deployment environment too. So the right workflow is to ask codecs to identify what variables are 01:14:19.644 --> 01:14:26.204 needed, classify them as public or private, and then advise you where each one needs to be configured. 01:14:26.444 --> 01:14:32.644 Now let's say we're building on this app and we are adding external services. So one of those 01:14:32.644 --> 01:14:38.344 services might be something like OpenAI, or another service could be OpenRouter. Well, 01:14:38.724 --> 01:14:44.004 every time we connect to external services, we need to connect them using an API key, 01:14:44.204 --> 01:14:50.444 and those API keys are needed for those services to track how much usage we have so that they can 01:14:50.444 --> 01:14:56.564 bill us accordingly. And so in your app, you need to be storing those API keys because when you're 01:14:56.564 --> 01:15:01.504 going to be making those requests, regardless whether that's an API token or some kind of 01:15:01.504 --> 01:15:06.524 deployment token or pretty much anything else, you need to be very, very careful how you are 01:15:06.524 --> 01:15:13.064 storing them. And so in this app, let's say we want to use OpenAI here. So I'm going to say 01:15:13.064 --> 01:15:21.944 API stack and use the following key. And let's say we give it a sample API key. Sample API key 01:15:21.944 --> 01:15:27.824 as a sample. We're going to jump into plan mode. We're going to select this API stack only. We're 01:15:27.824 --> 01:15:33.344 going to be doing native fetch. All right, so it went ahead and created our first API stack here. 01:15:33.524 --> 01:15:38.864 And right here, it mentions this file where it stores this key. And so if you want to use a real 01:15:38.864 --> 01:15:43.984 key, you never want to paste it in chat. What you want to do is you want to open this file and modify 01:15:43.984 --> 01:15:47.964 it directly. So that's what we're going to do. We're going to open this in the editor here, 01:15:48.144 --> 01:15:52.844 and I'm going to paste this key right here. And this right here is my actual key. And so now 01:15:52.844 --> 01:16:00.964 I have an open AI, I have an API stack, and I have a real key in this file here, okay? And now what I 01:16:00.964 --> 01:16:07.664 need to do is I need to run a check and ensure that we are storing the keys the right way, and, you 01:16:07.664 --> 01:16:12.124 know, they're going to be deployed correctly and all that. And so I have this prompt to do just that, 01:16:12.184 --> 01:16:16.624 and it says here, inspect this project for environment variables and deployment config. Do 01:16:16.624 --> 01:16:21.164 not print secret values, and then tell me all of these things. So we're going to run this. So now 01:16:21.164 --> 01:16:26.664 it's telling us that environment inspection, required environment variables, required only 01:16:26.664 --> 01:16:32.124 for post, open API front-end variables, right? We don't have any public because, you know, sometimes 01:16:32.124 --> 01:16:37.144 your app can have both private keys and public keys, right? So if you're using something like 01:16:37.144 --> 01:16:43.144 Superbase, Superbase has an Anon key or a secret key, or they call it something else now. And the 01:16:43.144 --> 01:16:48.864 idea is the public key can be made available, but it has very, very strict permissions. Whereas 01:16:48.864 --> 01:16:55.024 something like your OpenAI API key or your OpenRouter API key or something of that sort 01:16:55.024 --> 01:17:01.024 needs to be very, very secret, right? Because with that key, you can make a lot of calls and 01:17:01.024 --> 01:17:06.924 do a lot of things. And so here it says we have a private key. OpenAI key is private and must stay 01:17:06.924 --> 01:17:12.824 server-side. It is used here, needed locally. Hosted service config, Vercel or another node 01:17:12.824 --> 01:17:18.404 capable host configured as a private server environment variables, port, etc, etc. Okay, 01:17:18.544 --> 01:17:23.884 that end of example is currently on track. So what we have, safest next step before deploying, 01:17:24.004 --> 01:17:29.144 replace it with only this, only configure the real key in the deployment provider's private 01:17:29.144 --> 01:17:36.624 environment variable settings. Okay, so I want to store the key locally for testing, and I want to 01:17:36.624 --> 01:17:43.464 ensure that it will be deployed also later. And so we want that key locally so that we can test, 01:17:43.564 --> 01:17:49.244 but we also want it to deploy. And that means we need to create a couple of files, one for local 01:17:49.244 --> 01:17:54.424 settings and one for deployment settings. And it's telling us which is the wrong file for local 01:17:54.424 --> 01:18:00.264 secret because examples are usually committed. So let's say we're doing a Vercel deploy. We're 01:18:00.264 --> 01:18:05.724 going to switch that. And there we have it. Store the real key locally in an untrack, right? We need 01:18:05.724 --> 01:18:11.064 to make sure that this is never committed to git it needs to be untracked so we're going to expand 01:18:11.064 --> 01:18:18.544 this submit this do not use public these are not public keys replace dot end of example with 01:18:18.544 --> 01:18:24.784 create dot end okay so it's it's going to be creating this dot end the secret is now ignored 01:18:24.784 --> 01:18:31.784 in dot end and then i'm updating readme and agents to make the local and recel setup unambiguous 01:18:31.784 --> 01:18:35.584 And that way we have the local key stored for local testing. 01:18:35.784 --> 01:18:37.484 It's never going to be committed into Git. 01:18:37.944 --> 01:18:44.204 And then we'll be able to send that key, also deploy that key onto Vercel because Vercel 01:18:44.204 --> 01:18:45.484 is going to be running our app. 01:18:45.544 --> 01:18:47.044 It needs access to that key as well. 01:18:47.104 --> 01:18:48.004 It needs to be secret. 01:18:48.224 --> 01:18:51.184 Okay, implemented the local Vercel key setup. 01:18:51.344 --> 01:18:56.284 And so in this point, we've made the secret key management and not just secret key, any 01:18:56.284 --> 01:18:58.724 kind of key management as part of our workflow. 01:18:58.724 --> 01:19:03.684 and we can be assured that we have the key for local stuff and we're also going to be deploying 01:19:03.684 --> 01:19:10.714 the key correctly for production stuff regardless of what kind of host you are using 01:19:14.414 --> 01:19:20.434 to be writing code for the core stuff. But a lot of things that your app will be doing will be done 01:19:20.434 --> 01:19:25.074 by existing code. You're not going to be building your app from scratch, right? You're going to be 01:19:25.074 --> 01:19:31.194 using existing libraries, existing frameworks, stuff like that. And those are called dependencies. 01:19:31.434 --> 01:19:37.054 And that is because your app depends on them to function. Without those things, your app will not 01:19:37.054 --> 01:19:43.914 function. And you need to ensure that you have a process for managing these dependencies. And I 01:19:43.914 --> 01:19:49.474 have here a prompt that you can use that will help you. Inspect this project before adding any 01:19:49.474 --> 01:19:54.554 dependencies. Do not install anything yet. Tell me all of this. And so let's go ahead and run this 01:19:54.554 --> 01:20:00.034 prompt. Right. And this is what it came back with. Dependency project inspection. Framework and 01:20:00.034 --> 01:20:05.434 package manager. Framework non-detected. This appears to be a plain static JavaScript app 01:20:05.434 --> 01:20:11.634 served by a custom node server. Now, of course, this will definitely not be the case when it 01:20:11.634 --> 01:20:17.054 comes to your real apps. You're going to be using some kind of framework, something that will make 01:20:17.054 --> 01:20:22.934 your app behave like a real app. Here, we just have a very, very plain app. Package manager, 01:20:22.934 --> 01:20:27.754 non-detected, no, none of this. And of course, when you're going to be building your app, 01:20:27.794 --> 01:20:32.434 you're going to be having all this as well. Available scripts, no NPM scripts exist because 01:20:32.434 --> 01:20:37.954 there's no package manager, because there's no package.json. Current documented run command, 01:20:38.074 --> 01:20:43.294 we just have this very, very basic. Definitely not the case when it comes to production apps. 01:20:43.534 --> 01:20:49.934 OpenAI local and run command. So we have this. Relevant install dependencies. So we do have some 01:20:49.934 --> 01:20:57.354 basic node built-ins. All of these OpenAI calls native fetch. Okay, so it's native. It's not using 01:20:57.354 --> 01:21:03.654 the OpenAI SDK, which would have been a dependency. Can the task be completed without adding a package? 01:21:03.874 --> 01:21:09.774 Yes, for the current OpenAI API stack and local serving, the project already calls OpenAI via 01:21:09.774 --> 01:21:15.674 native fetch. If a new package is recommended, no package is recommended right now. A package could 01:21:15.674 --> 01:21:24.094 be recommended later. If we use Express, Fastify, we start using the official SDK.env. Files likely 01:21:24.094 --> 01:21:31.014 to change if preceding, right? API behavior, openA calls, frontend, et cetera, et cetera. 01:21:31.514 --> 01:21:36.474 And so dependencies are important and you want to limit your dependencies. You don't want the system 01:21:36.474 --> 01:21:43.174 to just add dependencies blindly. And so this is going to be super useful as you're building your 01:21:43.174 --> 01:21:48.834 app so that you can streamline it. Because as I was just building this simple app, Codex asked me 01:21:48.834 --> 01:21:55.154 whether I want to use OpenAI SDK or native fetch. And you always want to err on the side of native 01:21:55.154 --> 01:22:00.374 stuff. If you can avoid a dependency or an SDK, that would be the right move. And that's exactly 01:22:00.374 --> 01:22:04.974 what I did here. I just used native, right? I could have used an SDK, but I decided I'm just 01:22:04.974 --> 01:22:10.274 going to keep it as simple as possible. And that's really the goal here. And this prompt and making 01:22:10.274 --> 01:22:16.094 this part of your workflow is going to enable you to keep your app streamlined so that you have less 01:22:16.094 --> 01:22:22.514 dependencies, less chance for something to go wrong, less bloat, etc., etc. So definitely add 01:22:22.514 --> 01:22:28.574 this to your app building workflow and ensure that Codex knows about it by making this a part 01:22:28.574 --> 01:22:38.114 of your agent's MD for a separate step. Now that the Codex foundation is clear, we are going to 01:22:38.114 --> 01:22:45.414 start with something intentionally small. The first app is called HabitCard, and it is a tiny 01:22:45.414 --> 01:22:53.074 habit tracker where users can add habits, check them all for the day, and see a simple streak or 01:22:53.074 --> 01:23:00.294 count. This is a great starter project because the result is visual, easy to check, and small enough 01:23:00.294 --> 01:23:08.254 that every step stays clear. Codex can plan the app, build the UI, show us the file changes, 01:23:08.714 --> 01:23:16.254 open the browser, polish the result, and get the front end ready to deploy without also introducing 01:23:16.254 --> 01:23:24.254 backend complexity. HabitCard gives us the core app building pieces without much product complexity. 01:23:24.254 --> 01:23:33.274 a form, a list, a daily check-in state, simple feedback, and later local storage persistence. 01:23:33.614 --> 01:23:40.074 It does not need authentication, payments, APIs, or a real database at first. 01:23:40.254 --> 01:23:47.994 This first app is about getting comfortable with the full Codex loop on something we can understand immediately. 01:23:47.994 --> 01:23:57.994 Now, here in Codex, the first thing that you want to do is you want to click here, and you can select Start from Scratch, but I like to have it set to a specific folder. 01:23:58.574 --> 01:24:04.014 So I'm going to click on Use an Existing Folder, and I have here a folder prepared called Demo. 01:24:04.094 --> 01:24:11.454 So I'm going to open this here, and now we have a new project that has been associated with a specific folder. 01:24:11.734 --> 01:24:16.754 And here we can start a brand new conversation for the app that we are building. 01:24:16.754 --> 01:24:23.014 Now, anytime I start building a brand new app, I always want to create a visual architecture. 01:24:23.274 --> 01:24:32.714 Being a visual person, this gives me an understanding of the scope of an app, how the app looks, the user flow, and stuff like that. 01:24:32.774 --> 01:24:38.554 And we can actually use Codex to create that visual architecture for us. 01:24:38.654 --> 01:24:43.274 Now, I have here a prepared prompt that creates this visual architecture. 01:24:43.274 --> 01:24:52.314 And we want to ensure that we use the built-in image generation that we have in Codex as well as ChatGPT to do it. 01:24:52.794 --> 01:24:57.034 So I'm going to press forward slash, and I'm going to search for image gen. 01:24:57.274 --> 01:25:01.314 Okay, and then we can say something like use image gen for the following. 01:25:01.614 --> 01:25:05.894 And I'm going to go jump into plan mode, and I'm going to go ahead and execute this. 01:25:05.994 --> 01:25:09.894 Okay, and it came back with a habit card architecture diagram. 01:25:09.894 --> 01:25:15.314 And here it says create one raster infographic using this. 01:25:15.414 --> 01:25:16.614 So everything looks good. 01:25:16.734 --> 01:25:19.454 There's some diagram content, visual direction. 01:25:19.594 --> 01:25:20.854 It's a wide composition. 01:25:20.854 --> 01:25:21.454 Looks good. 01:25:21.974 --> 01:25:24.094 We're going to say, yes, implement this. 01:25:24.434 --> 01:25:24.634 Okay. 01:25:24.734 --> 01:25:26.194 And that is our habit card. 01:25:26.294 --> 01:25:27.974 That is our visual interface. 01:25:27.974 --> 01:25:32.234 And right away, I can see what this app is all about, right? 01:25:32.254 --> 01:25:33.314 We have add habit. 01:25:33.594 --> 01:25:35.034 We have habit list. 01:25:35.394 --> 01:25:36.794 We have today check-in. 01:25:37.074 --> 01:25:39.214 And we have a streak count. 01:25:39.214 --> 01:25:45.074 then we have an empty state we have local storage later and we have the Vercel deploy and so this is 01:25:45.074 --> 01:25:53.534 a very very simplified visual architecture but it is very very important I want to see right away 01:25:53.534 --> 01:26:00.074 what I'm dealing with what I'm working with how many pages you know how complex is the app how 01:26:00.074 --> 01:26:06.014 simple is the app I see that this is not going to be you know a very complex app it's going to be a 01:26:06.014 --> 01:26:12.534 fairly simple app, but we do have some interesting bits here, right? This empty state, we have some 01:26:12.534 --> 01:26:19.234 local storage, we have a Vercel deploy, and so it's a fairly simple app, but still a fairly workable 01:26:19.234 --> 01:26:23.694 app. Now, the next thing that I like to do is create the entity architecture, and this is where 01:26:23.694 --> 01:26:29.994 we're going to be mapping the small set of entities behind the app. So even though the first version 01:26:29.994 --> 01:26:38.034 is front-end only, it is useful to name the habit, the daily check-in, and the street count summary 01:26:38.034 --> 01:26:44.874 before we add a local storage later. And this right here is the entity diagram. And I'm just 01:26:44.874 --> 01:26:51.814 going to say use image gen for below. I'm going to go ahead and run that. And I can run it directly. 01:26:51.974 --> 01:26:57.694 I don't really need to run it in plan mode because it's just generating a diagram. I'm not asking it 01:26:57.694 --> 01:27:05.554 a complex, ambiguous coding question or giving it an ambiguous coding instruction. 01:27:05.914 --> 01:27:10.714 And here is our NTC architecture. And unlike the visual architecture that we... 01:27:10.834 --> 01:27:16.774 generated previously, here we're actually seeing the entities that will later become the actual 01:27:16.774 --> 01:27:23.534 storage schema. Okay, so we have the habit, we have a habit check-in, we have a streak summary, 01:27:23.534 --> 01:27:26.634 and then local storage as the backend. 01:27:26.774 --> 01:27:28.914 So no backend, everything is stored locally 01:27:28.914 --> 01:27:29.934 with local storage. 01:27:30.374 --> 01:27:32.534 And this is also very, very useful 01:27:32.534 --> 01:27:36.254 because unlike the visual diagram here, 01:27:36.254 --> 01:27:38.874 I wanna see the actual schema. 01:27:38.874 --> 01:27:42.074 I wanna see what kind of elements 01:27:42.074 --> 01:27:45.074 or what kind of tables we might need 01:27:45.074 --> 01:27:48.534 to translate this app schema into. 01:27:49.074 --> 01:27:51.254 And as you can see, this is fairly simple. 01:27:51.734 --> 01:27:53.214 Habit, habit check-in. 01:27:53.534 --> 01:27:59.834 streak summary, we have these three main functions here, these three main features that were 01:27:59.834 --> 01:28:05.874 translated into entities. Okay. And then we have, and for each entity, we have things like name, 01:28:05.974 --> 01:28:11.774 created at date, completed count. Now at this point, we have both the visual architecture as 01:28:11.774 --> 01:28:15.714 well as the entity architecture. And this is something that I like to do for pretty much 01:28:15.714 --> 01:28:21.614 every single app that I build, because I want to get an idea of what I'm really dealing with, 01:28:21.614 --> 01:28:28.654 right i want to have an understanding of the the scope of the app and right now i can see exactly 01:28:28.654 --> 01:28:34.974 where we are i can see that this is a fairly simple app i can see the entities i i see the app 01:28:34.974 --> 01:28:40.014 building i see the future of the app i see the app coming together now the next thing that we want 01:28:40.014 --> 01:28:48.654 to do is we want to use the plan mode to ask codex what stack makes sense for this first app 01:28:48.654 --> 01:28:55.794 The important part is that Codex should recommend the simplest path before it edits any files. 01:28:55.994 --> 01:28:59.474 And as you might have guessed, we are going to be doing this in plan mode. 01:28:59.574 --> 01:28:59.914 All right. 01:28:59.954 --> 01:29:01.854 And here's the prompt that we're going to be using. 01:29:01.854 --> 01:29:03.634 Do not edit files yet. 01:29:03.794 --> 01:29:08.694 Inspect the current project and recommend the simplest stack for HabitCard, right? 01:29:09.234 --> 01:29:11.634 And we ask him what it should come back with. 01:29:11.694 --> 01:29:16.554 And we're going to press Shift-Tab to enable the plan mode, of course, because we want 01:29:16.554 --> 01:29:24.474 it to come back to us if it needs to and ask any clarifying questions. We needed to clarify 01:29:24.474 --> 01:29:30.594 everything before we go deeper into the building the app. Okay, I'm going to go ahead and execute 01:29:30.594 --> 01:29:36.774 this. And let's see what it comes back with. And in this case, it did not come back with any 01:29:36.774 --> 01:29:43.314 clarifying questions. Okay, so it's writing a plan. And the recommended front end stack is going to be 01:29:43.314 --> 01:29:50.474 React TypeScript, right? It wants to use Tailwind CSS for fast, simple styling. This is testing 01:29:50.474 --> 01:29:57.594 library, no React router. It's a simple single screen app, no global state library, okay? 01:29:58.174 --> 01:30:02.874 Backend decision. No backend is needed for the first version, right? And that's what we told it. 01:30:02.874 --> 01:30:08.754 We set bias toward a front-end only implementation first. And then it's also going to use browser 01:30:08.754 --> 01:30:13.874 verification. Okay, open the app in the browser, verify all this. Okay, so let's go ahead and 01:30:13.874 --> 01:30:20.354 run this. All right, so it worked for about 10 minutes, and it has implemented the habit card 01:30:20.354 --> 01:30:25.574 as a front-end only React TypeScript app. This is where it is, and this is what it did, right? 01:30:25.614 --> 01:30:33.134 It built the app shell and UI, habit logic, local storage, components for adding form, for the ad 01:30:33.134 --> 01:30:40.734 form list card and empty state tests for app flow logic and storage and verification passed nine 01:30:40.734 --> 01:30:48.094 tests production build succeeded and it also gave us a dev server that is running the app and so this 01:30:48.094 --> 01:30:54.494 dev server is running on my machine right now and this allows us to quickly test things without 01:30:54.494 --> 01:30:59.614 needing to deploy and test there and on the right hand side we have this card that is always available 01:30:59.614 --> 01:31:07.694 and it shows us things like artifacts, background terminal, and basically things that were created 01:31:07.694 --> 01:31:13.214 as part of this conversation. Okay, so we have the images that were generated. We have the index.html 01:31:13.214 --> 01:31:18.534 for the app. We have the background terminal that is running here. And so I can click here, 01:31:18.634 --> 01:31:24.194 and that's going to go ahead and go to the server that's running our app. So let's do that. And 01:31:24.194 --> 01:31:29.014 that's going to go ahead and open. It's also going to open the browser right here in the right-hand 01:31:29.014 --> 01:31:34.414 pane. Now, before we had no right hand pane, but if you click here, you can see that it opens up 01:31:34.414 --> 01:31:38.934 here, right there. Another thing that you can do is you can open the browser directly. This is the 01:31:38.934 --> 01:31:45.354 front page here, and I can add a habit, habit one. I can click here, and we have a habit here. I can 01:31:45.354 --> 01:31:52.494 add another habit, habit two, or maybe gym, and that's creating these habits here. So I can check 01:31:52.494 --> 01:31:58.434 it off, and that is done. Check it off. And so it's a very, very simple app, and if you want to see the 01:31:58.434 --> 01:32:05.334 actual files that were created as part of this, you can simply right-click here and open in Finder. 01:32:05.474 --> 01:32:11.174 And this is the React app that was created for this here. Once the UI works, we'll add a small 01:32:11.174 --> 01:32:17.854 persistence step with local storage. Habits and today's check-ins can persist after refresh, 01:32:18.054 --> 01:32:25.174 so the app starts to feel real without introducing a backend yet. And this is the prompt that we're 01:32:25.174 --> 01:32:31.174 going to be using. Upgrade habit card. So habits in today's check-ins persist with local storage. 01:32:31.294 --> 01:32:36.574 I'm going to jump into the plan mode here just in case. And I'm going to go ahead and run this. 01:32:36.874 --> 01:32:41.374 Now it's actually telling us that inspection shows that habit card already implements the 01:32:41.374 --> 01:32:48.294 requested front-end only local storage persistence. Okay. So no file edits are needed for this upgrade. 01:32:48.294 --> 01:32:53.974 So we must have done this in one of the previous prompts. But if we hadn't done this, 01:32:53.974 --> 01:32:58.294 then we would run this prompt. But still, let's go ahead and run it. And now it tells us that 01:32:58.294 --> 01:33:05.574 persistence works through this storage using these keys and a lot of other details here. Okay, 01:33:05.594 --> 01:33:12.054 so we can reload this. And now we have something called local storage. And what this means is that 01:33:12.054 --> 01:33:18.494 this app does not have a backend, but this stuff is going to be stored on my browser. Okay, so 01:33:18.494 --> 01:33:23.874 if I'm using this instance, it's going to be stored on this browser. If I run it in a different 01:33:23.874 --> 01:33:29.594 browser, then it's not going to have the data. So whatever I do in that new browser is going to have 01:33:29.594 --> 01:33:36.734 fresh data. And so this is a way to create, you know, storage just for testing mail. I mean, you 01:33:36.734 --> 01:33:41.754 can use this in production as well for certain apps, for certain situations. It does have its 01:33:41.754 --> 01:33:47.734 place, but it's very, very limiting compared to something like Superbase or something of that 01:33:47.734 --> 01:33:54.354 sort. And so we can delete all this. We can do all that. We can start. And if I copy this, 01:33:54.494 --> 01:33:58.874 run this app, and I load this app, there's nothing there because I'm using a brand new 01:33:58.874 --> 01:34:06.014 browser instance. And I can create, I can do, I can check off, I can do this, I can do all that. 01:34:06.394 --> 01:34:12.694 But if I go back to Codex, there's nothing here, right? It's not syncing. It's not using my account 01:34:12.694 --> 01:34:15.734 and it's not using a unified backend 01:34:15.734 --> 01:34:19.794 so that no matter which browser I use, 01:34:20.234 --> 01:34:23.174 it will still store the data and keep track of everything. 01:34:23.314 --> 01:34:24.514 That is not happening. 01:34:24.774 --> 01:34:28.274 Now, once the app works locally, it's time to deploy it. 01:34:28.434 --> 01:34:30.194 Even though HabitCard is simple, 01:34:30.634 --> 01:34:34.354 this is the first moment where Codex helps move something 01:34:34.354 --> 01:34:37.954 from local code to a real-life URL. 01:34:37.954 --> 01:34:41.194 And so Codex can do the whole deployment process. 01:34:41.194 --> 01:34:47.334 It can run the local checks, prepare the projects, connect or create the Vercel project, 01:34:47.834 --> 01:34:52.814 deploy the frontend, and then verify that the live page actually loads. 01:34:53.094 --> 01:34:56.974 And additionally, you want that first deployment to feel very concrete. 01:34:57.274 --> 01:34:59.794 We're not just writing code and hoping it works. 01:35:00.334 --> 01:35:04.334 We're taking a small app, shipping it, opening the deployed URL, 01:35:04.794 --> 01:35:09.374 and checking the result like we would with a real project. 01:35:09.374 --> 01:35:15.534 And here is my Vercel deployment prompt. Prepare HabitCard for deployment on Vercel 01:35:15.534 --> 01:35:22.834 and verify it works as a small front-end only app. So at this point, we are just preparing it 01:35:22.834 --> 01:35:29.614 for deployment. We're not yet deploying it, but still, this is an important step because this will 01:35:29.614 --> 01:35:35.754 ensure that once we do deploy it, that it will work without any issues. I'm going to go jump 01:35:35.754 --> 01:35:41.674 into the plan mode. And remember, we do have that Versal plugin enabled, and so it should 01:35:41.674 --> 01:35:43.714 use it automatically with no issues. 01:35:44.652 --> 01:35:46.392 I'm going to go ahead and execute this. 01:35:46.392 --> 01:35:50.452 All right, so it went ahead and created a Vercel deployment plan. 01:35:50.452 --> 01:35:56.552 HabitCard is already suitable for a front-end only Vercel deployment. 01:35:56.552 --> 01:35:57.992 And this is what it's going to do. 01:35:57.992 --> 01:36:00.672 And here is the deployment implementation. 01:36:00.672 --> 01:36:01.952 Keep the app front-end only. 01:36:01.952 --> 01:36:08.272 Do not add convex, which is a backend, APIs, auth database, server functions, or external 01:36:08.272 --> 01:36:09.272 services. 01:36:09.272 --> 01:36:10.692 None of that. 01:36:10.692 --> 01:36:16.252 And local storage persistence is expected to be local to each browser and deployment 01:36:16.252 --> 01:36:17.252 origin. 01:36:17.252 --> 01:36:19.932 Data will not sync across devices or URLs. 01:36:19.932 --> 01:36:23.112 Okay, let's go ahead and implement this plan. 01:36:23.112 --> 01:36:28.992 three minutes later, it tells us that deployed HabitCard to resell and verified it live. Okay, 01:36:29.052 --> 01:36:36.232 so this is the live URL. We can click here, and that's going to open our HabitCard app running 01:36:36.232 --> 01:36:42.672 on the web, right? Accessible to everybody. And this, again, uses local storage. Okay, 01:36:42.812 --> 01:36:47.832 so we can do that over here. And of course, you know, it's not going to be available in another 01:36:47.832 --> 01:36:54.392 instance because it's all stored locally. And so at this point, we designed, architected, built, 01:36:54.912 --> 01:37:03.772 tested, and then deployed a very, very simple web app that uses local storage as our backend. And 01:37:03.772 --> 01:37:09.272 this proved the whole cycle for us. Now, in the next several modules, we're going to be doing the 01:37:09.272 --> 01:37:17.272 same, but with more complex apps, slowly adding things like authentication, backend, and other 01:37:17.272 --> 01:37:22.212 important components that you need for a real production app. 01:37:25.392 --> 01:37:30.712 The second app we'll be building will be a mini team voting app where people submit 01:37:30.712 --> 01:37:33.932 lunch or snack ideas and vote on the winner. 01:37:34.032 --> 01:37:38.872 It's a bit more complex with more features, but still fairly simple overall. 01:37:38.932 --> 01:37:46.932 SnackVote has a submit option form, a snack option list, vote buttons, a live leaderboard 01:37:47.272 --> 01:37:53.192 and a winner card. This app will serve as a bridge between a simple front-end and the larger 01:37:53.192 --> 01:37:58.552 marketplace app we'll build right after this. Instead of jumping straight into complex entities 01:37:58.552 --> 01:38:05.432 such as customers, bookings, and permissions, we can first learn the backend pattern on a much 01:38:05.432 --> 01:38:12.792 smaller app. SnackVote only needs snack options and votes. Someone can submit an option, other 01:38:12.792 --> 01:38:18.872 people can vote, and the leaderboard updates as the vote counts change. That gives us enough 01:38:18.872 --> 01:38:25.352 structure to understand live backend data without making the product itself hard to follow. 01:38:25.352 --> 01:38:31.752 As always, in this first step, we'll be mapping the SnackVote interface visually. The app should 01:38:31.752 --> 01:38:38.232 be simple enough to understand immediately. Create or join a voting room, submit a Snack 01:38:38.232 --> 01:38:46.452 option, vote once, watch the leaderboard update, and see a deadline-driven winner state. Now here 01:38:46.452 --> 01:38:51.712 in Codex, we're going to come here and we're going to create a new project from an existing folder. 01:38:51.832 --> 01:38:55.812 We're going to click over here. Here, we're going to create a new folder. I'm going to type 01:38:55.812 --> 01:39:02.472 snack vote, and we're going to click open. And now we have a brand new project configured here in 01:39:02.472 --> 01:39:07.932 Codex. And here's our prompt for the visual architecture. We want a preface that we want 01:39:07.932 --> 01:39:13.652 to use this image and we're going to jump into plan mode and execute this. That looks good. We're 01:39:13.652 --> 01:39:18.992 going to go ahead and expand that. Go ahead and implement that. And here's our snack vote visual 01:39:18.992 --> 01:39:25.172 architecture. And look at this beautiful diagram. So you can create or join a room. In the current 01:39:25.172 --> 01:39:31.852 room, you're going to be seeing this members and the time left. You have here a snack list. You 01:39:31.852 --> 01:39:38.732 have your voting buttons, you have a live leaderboard, and you have a closed winner state 01:39:38.732 --> 01:39:47.232 with some voting deadlines here, here as well. And then we also have our Vercel deploy. And so 01:39:47.232 --> 01:39:53.752 this looks like a fairly fun app with a lot of things going on. And so I can't wait to implement 01:39:53.752 --> 01:39:58.792 this. And we're also going to be adding more and more features as we go along. Next, I want to go 01:39:58.792 --> 01:40:06.012 ahead and create an entity diagram, an entity architecture diagram. So here's our prompt. We're 01:40:06.012 --> 01:40:11.092 going to do this, and we're going to go ahead and execute that. And here's our entity diagram. 01:40:11.512 --> 01:40:17.712 Okay, so a room contains multiple snack options and has one voting session, right? We have the 01:40:17.712 --> 01:40:24.052 voting room, many snack options, and many votes, right? We have here some winner logic, the winner 01:40:24.052 --> 01:40:31.332 logic snack option with the highest vote count when now is greater than or equal to closes at 01:40:31.332 --> 01:40:38.372 right so after the deadline we have here a legend and here we have a sample kind of workflow a 01:40:38.372 --> 01:40:44.852 pipeline build the ui first connect the to convex later convex is going to be our back end and we 01:40:44.852 --> 01:40:52.852 are going to be leveraging things like real-time updates persistence and live vote counts and so 01:40:52.852 --> 01:40:59.912 So now that we've generated a visual architecture diagram, as well as our entity diagram, the 01:40:59.912 --> 01:41:05.092 next thing that we want to do is we want to ask Codex for some stack recommendations, 01:41:05.692 --> 01:41:08.952 because there are lots of ways that we can build out this app. 01:41:09.092 --> 01:41:12.892 And we want Codex to tell us the best options for this specific app. 01:41:13.152 --> 01:41:14.812 Here's the prompt that we're going to be using. 01:41:14.812 --> 01:41:17.152 And I'm going to switch into plan mode here. 01:41:17.352 --> 01:41:20.312 And it's telling us, do not edit files yet. 01:41:20.312 --> 01:41:26.172 inspect the current project and recommend the simplest stack for Snackville. And here's the 01:41:26.172 --> 01:41:30.792 plan that it came back with. Here we have the stack recommendation. We're going to be using React, 01:41:31.332 --> 01:41:38.032 TypeScript, Tailwind. And here it says back and later convex with TypeScript server functions and 01:41:38.032 --> 01:41:44.712 generated client types. And so for the most part, this is very, very similar, if not the exact same 01:41:44.712 --> 01:41:50.792 architecture stack that we use for the first app, except we're going to be adding more and more 01:41:50.792 --> 01:41:58.392 features and also connecting a backend for the first time in this tutorial. Now here, instead 01:41:58.392 --> 01:42:04.072 of clicking submit, I'm going to give it another prompt, and this prompt is going to start building 01:42:04.072 --> 01:42:11.752 the app, writing the code. And here's the prompt, implement the first working SnackVote UI without 01:42:11.752 --> 01:42:18.532 a database or persistence. Inspect the current project first, then build the smallest useful 01:42:18.532 --> 01:42:25.712 SnackVote UI. And there's some verification steps as well. And we also explicitly tell it to not use 01:42:25.712 --> 01:42:32.832 Convex, local storage, or an API, nothing of that. Just keep it to these specs right here. And we also 01:42:32.832 --> 01:42:38.072 have some verification. So I'm going to go ahead and run this in plan mode in case it wants to ask 01:42:38.072 --> 01:42:42.932 me something. So it doesn't have any questions for us. And that is because in this specific 01:42:42.932 --> 01:42:49.392 conversation, we already fleshed out, you know, things like the architecture, the stack, and all 01:42:49.392 --> 01:42:55.092 of that stuff. And so it kind of knows what it needs to do to build out this app. So we're going 01:42:55.092 --> 01:43:00.172 to say, yes, implement this, because this is the step where we actually want the code written. 01:43:00.352 --> 01:43:06.532 All right, so this has completed. And it says here, implemented the first working UI only snack 01:43:06.532 --> 01:43:14.332 vote app here, created all of this, what works, verification completed, still needs attention 01:43:14.332 --> 01:43:19.592 later. Okay, all of these things. And we'll talk about that a little bit later. And so now we have 01:43:19.592 --> 01:43:25.472 a web preview. So we can click on open. And that's going to go ahead and open it right here in our 01:43:25.472 --> 01:43:31.812 built in browser here. This is our app right here. And so we have snack and lunch options, we can 01:43:31.812 --> 01:43:38.972 create, we can submit an option, add sample snacks, click here, and we have these snack options here 01:43:38.972 --> 01:43:44.212 with some votes here. Leaderboard, right? So this is where... 01:43:44.752 --> 01:43:46.352 Winner state, current winner, 01:43:46.552 --> 01:43:48.512 leader, spicy ramen bowls. 01:43:49.092 --> 01:43:51.312 And so if I vote on falafel wraps, 01:43:52.332 --> 01:43:53.392 six, right? 01:43:53.492 --> 01:43:54.412 So now it's six. 01:43:54.512 --> 01:43:55.472 I can keep voting. 01:43:55.992 --> 01:43:58.112 And that's a problem right away. 01:43:58.112 --> 01:44:04.012 and it's in memory and one person can vote multiple times, which is an issue. We're going 01:44:04.012 --> 01:44:09.832 to fix that a little bit later, but I can also add a snack or let's say sushi. I don't know, 01:44:09.972 --> 01:44:15.792 sushi. Add this and we have sushi and I can also vote on that. So it's a big, big issue. But 01:44:15.792 --> 01:44:21.832 for the most part, the logic works, the UI works. Now, once the snack vote UI exists, 01:44:21.832 --> 01:44:27.372 we're going to replace the mock snack data with real convex data. And for those of you that are 01:44:27.372 --> 01:44:34.432 not familiar, Convex is a backend that we're going to be using in this tutorial. It's an awesome 01:44:34.432 --> 01:44:39.992 backend, super fast. And if you want to learn more information, I actually did a dedicated video on 01:44:39.992 --> 01:44:47.632 it that you can find right there. And so once we add Convex, our app will stop being a static 01:44:47.632 --> 01:44:53.972 interface and start behaving like a real database-backed product. And the path is very, very 01:44:53.972 --> 01:45:01.412 simple codex, creates the convex schema, adds a query, adds mutations, connects it to the UI, 01:45:01.912 --> 01:45:08.772 and then we verify the result in both the browser and the convex dashboard. And so when we submit 01:45:08.772 --> 01:45:15.132 an option in the app, it should be written back to convex. When we look inside the convex dashboard, 01:45:15.612 --> 01:45:22.612 that snack option should be there. And when someone votes, the UI should update live so that 01:45:22.612 --> 01:45:28.372 we can see the front end and back end working together instead of treating the back end like 01:45:28.372 --> 01:45:34.772 a black box. And when you head over to convex.dev, you can learn more about this back end. And this 01:45:34.772 --> 01:45:41.852 is a great, great back end. It's very, very fast. And it works really great with agents, right? So 01:45:41.852 --> 01:45:46.812 the back end building blocks for your agents. Okay. So I'm going to go ahead and log into my 01:45:46.812 --> 01:45:51.512 free account. I'm using the free plan. I'm not paying for anything. And this is also an open 01:45:51.512 --> 01:45:55.632 source backend, so you can also self-host it if you want. So I'm going to go ahead and log in. 01:45:55.832 --> 01:46:01.012 All right, so here I am logged in, and as you can see, I have here two projects. Now, our app is 01:46:01.012 --> 01:46:06.752 going to automatically create a brand new project for its data, for its functions, for everything. 01:46:07.012 --> 01:46:11.992 And here, back in Codex, we're going to paste a new prompt that looks something like this. 01:46:12.152 --> 01:46:19.492 Upgrade snack vote, so snack options and votes are stored in convex instead of local in-memory 01:46:19.492 --> 01:46:25.092 state. Now, if I press Command, comma, and go to MCP servers, you can see that I do not have the 01:46:25.092 --> 01:46:31.392 convex MCP server. And that is because we're not going to be connecting to convex via MCP. We're 01:46:31.392 --> 01:46:36.932 actually going to be connecting to it using a much simpler method, and that is the CLI, which stands 01:46:36.932 --> 01:46:43.492 for Command Line Interface. And actually, before I run this prompt, we are going to check to make 01:46:43.492 --> 01:46:52.012 sure that we have a connection. Can you first check that we have the Convex CLI installed? 01:46:52.432 --> 01:46:58.312 And if not, do install it. I'm going to go ahead and run it. Now, I already have Convex CLI installed, 01:46:58.552 --> 01:47:04.732 but you can just tell Codex to install it. It's that easy. And so it's telling me that NPX, 01:47:04.732 --> 01:47:11.252 which is a package manager, could fetch Convex temporarily, but the project does not have it 01:47:11.252 --> 01:47:18.052 installed. I'm installing Convex into the project now as a dev dependency. Convex is installed 01:47:18.052 --> 01:47:24.512 locally now. I'll verify the CLI results. And so you don't need to read lots and lots of 01:47:24.512 --> 01:47:29.292 documentation, figure out how to connect to it. You just tell Codex that you want to connect to it. 01:47:29.572 --> 01:47:35.752 It's that easy. So Convex CLI is installed locally in the project now. So now we can paste the 01:47:35.752 --> 01:47:42.112 prompt, upgrade SnackVote. So SnackOptions and votes are stored in Convex instead of local in 01:47:42.112 --> 01:47:47.412 memory state. So I'm going to go ahead and do this. And let's go into plan mode, see if it wants to 01:47:47.412 --> 01:47:52.972 ask me something or clarify something. And so it's telling me one material setup choice is still 01:47:52.972 --> 01:47:59.072 open. There is no existing Convex folder. So this app is not linked to a Convex deployment yet. And 01:47:59.072 --> 01:48:04.392 that is correct. And that's what we want to do next. And now it's asking me which Convex backend 01:48:04.392 --> 01:48:10.332 should SnackVault use for this first backed version. We want to create a new one, right? So 01:48:10.332 --> 01:48:15.232 we're going to go with the recommended option. All right. And now we have a new plan to upgrade 01:48:15.232 --> 01:48:21.772 the existing app from in-memory SnackOptions to live convex data. Okay. So it's going to do 01:48:21.772 --> 01:48:27.632 everything. And it's going to essentially configure the backend to be convex, set up the schema, 01:48:28.292 --> 01:48:34.032 set up the data, everything. And once it's done, we should be able to go to convex and see a brand 01:48:34.032 --> 01:48:38.952 new project here automatically created. So I'm going to hit submit here. All right. So it says 01:48:38.952 --> 01:48:46.712 it has created a fresh cloud project and synced the backend function successfully. And now you 01:48:46.712 --> 01:48:53.272 see this cursor, it's testing out the UI. And so right now it's not running, so it should start it 01:48:53.272 --> 01:48:58.092 out. And here it says the existing browser tab was sitting on the browser error. So it has restarted 01:48:58.092 --> 01:49:04.692 it. And if we jump into Convex, you can see that we have a new project created. Now, I did 01:49:04.692 --> 01:49:10.152 authenticate this account with Codex, so it knows that this is my account. And so if we click over 01:49:10.152 --> 01:49:15.592 here, we should see some initial stuff happening, right? There's some data, functions, and it's not 01:49:15.592 --> 01:49:21.652 done yet, right? It's still working. And while it's working, we can see what has been done. And 01:49:21.652 --> 01:49:27.492 it's actually typing it. Look at that. Key press input. It's creating it. It's testing it right 01:49:27.492 --> 01:49:32.312 here. You can actually see it happening. The snack was submitted through the browser and appeared 01:49:32.312 --> 01:49:38.612 from Convex. I am voting on it. There it is. It's testing all the flows, which is pretty cool. 01:49:38.832 --> 01:49:44.872 All right. Now it's telling us implemented the Convex-backed snack vote upgrade, changed all 01:49:44.872 --> 01:49:51.992 of this. What changed? Verification, edge cases handled, and it is running. So we can test it 01:49:51.992 --> 01:49:59.572 ourselves. And so here's the app. And now it's convex backed. And so now if we head to convex, 01:49:59.912 --> 01:50:05.912 we should see the data. So as you can see, snack options, this has a vote of one. This is this 01:50:05.912 --> 01:50:11.852 nachos. Vote one. And if we increase the vote, it should be two. And it's automatic. It's 01:50:11.852 --> 01:50:18.092 absolutely automatic. Three, it's three. It does not need to do anything. And we can create a new 01:50:18.092 --> 01:50:24.592 snack option, let's say sushi, submit. And if we come over here, we see sushi, zero votes. Now it's 01:50:24.592 --> 01:50:31.932 winning. And so this is essentially the same app, except it's convex-backed. And we also have 01:50:31.932 --> 01:50:38.572 functions. And with convex, you need to create functions to access your data. It's not like 01:50:38.572 --> 01:50:44.172 with other systems where it's automatic. Here you need list, you need submit, you need a vote, 01:50:44.172 --> 01:50:53.092 you need functions. And so the snack options table or document has three functions. No files, 01:50:53.212 --> 01:50:58.392 no schedules, and there's some logs here so that you can see things are happening. Okay, so this 01:50:58.392 --> 01:51:06.052 was a fairly successful migration. We went to no backend to a convex backend very, very quickly. 01:51:06.372 --> 01:51:12.292 Now that SnackVault has real convex data, we can make it feel more like a shared group app. 01:51:12.292 --> 01:51:19.372 Instead of one global snack board, users can create or join a simple voting room like Friday 01:51:19.372 --> 01:51:27.152 lunch or team snacks. Each room should own its own snack options, votes, leaderboard, 01:51:27.572 --> 01:51:33.852 and winner's state. This keeps the app more interesting while teaching a clean backend 01:51:33.852 --> 01:51:41.652 concept, scoped data. We still do not need accounts, permissions, invites, or admin tools. 01:51:41.652 --> 01:51:44.112 And here's the prompt that we're going to be using. 01:51:44.352 --> 01:51:49.732 Upgrade snack vote so voting happens inside simple rooms. 01:51:49.932 --> 01:51:52.532 And I'm going to run this in a plan mode. 01:51:52.532 --> 01:51:55.212 All right, so it came back with a plan for us. 01:51:55.292 --> 01:51:58.232 This is the room-based snack vote upgrade. 01:51:58.232 --> 01:52:03.312 Upgrade the current ConvexBack app from one global snack board to simple rooms. 01:52:03.592 --> 01:52:04.812 Going to expand that. 01:52:05.052 --> 01:52:06.292 Yes, implement that. 01:52:06.412 --> 01:52:10.112 So as it's running, I am seeing an error message here. 01:52:10.712 --> 01:52:14.192 Did you forget to run npx convex dev? 01:52:14.512 --> 01:52:20.312 Okay, so let's see if it's able to catch that and solve it before the next prompt. 01:52:20.352 --> 01:52:21.152 It is done. 01:52:21.372 --> 01:52:24.012 So it has implemented room-based snack. 01:52:24.012 --> 01:52:25.532 Whoa, this is what it changed. 01:52:25.532 --> 01:52:32.432 files, things, verification, limits. Okay, very important. Limits is actually very, very useful. 01:52:33.032 --> 01:52:39.892 No auth ownership invites or duplicate vote guard yet. And we'll fix some of these a little later. 01:52:40.232 --> 01:52:44.672 Room selection, room codes. Okay, so how does this work? Let's go ahead and refresh this. 01:52:44.672 --> 01:52:50.872 All right, so we can create or join a room. And there are some rooms over here. So let's say we 01:52:50.872 --> 01:52:57.432 type Friday lunch. And so now we've switched the room. Okay. Current room, Friday lunch. And now 01:52:57.432 --> 01:53:04.532 we can do the same thing. We're now in the scope. It's all about scoping now, right? And so this is 01:53:04.532 --> 01:53:11.152 a specific room. And I can say, I don't know, submit. There we have it in this room. And now 01:53:11.152 --> 01:53:17.412 if I switch a room, let's say I switch to lunch ideas. So now it's brand new. There's nothing, 01:53:17.412 --> 01:53:23.552 nothing there. And I can say something like, I don't know, tacos. And now we have tacos here. 01:53:23.612 --> 01:53:29.252 And if we go into Codex, we should see that. So we have voting rooms here, and we have different 01:53:29.252 --> 01:53:35.632 ideas here. And now if we go into snack options, we can see that they belong to a specific room. 01:53:35.632 --> 01:53:40.152 We have the room IDs. These are the same, same room, then we have a bunch of different 01:53:40.152 --> 01:53:47.352 room IDs there. Probably some of them created by Codex as part of testing, like lunch ideas, 01:53:47.412 --> 01:53:52.612 Oh no, I created lunch ideas. These ones were created by Codex, these three rooms. 01:53:53.192 --> 01:53:59.492 And we can remove them. I can select these and we can delete these. And if we go into functions, 01:53:59.732 --> 01:54:05.192 we can see that for snack options, the same three functions, but for voting room, we have get, 01:54:05.332 --> 01:54:10.612 create or join, a bunch of other functions that we have. And so it pretty much did everything. 01:54:10.612 --> 01:54:17.832 It created the functions, it created the schema, it even created some test data while it was 01:54:17.832 --> 01:54:18.312 tested. 01:54:18.612 --> 01:54:23.452 We'll add one simple rule that makes the voting feel like a real product. 01:54:24.092 --> 01:54:30.272 After all, a person should not be able to spam the same room with repeated votes. 01:54:30.612 --> 01:54:33.372 And that is because we still do not have real authentication. 01:54:33.852 --> 01:54:39.572 And so for this tutorial, a local or session-based voter identity is enough. 01:54:39.572 --> 01:54:45.132 and that's what we're going to be doing right now. And here's my next prompt. We're going to 01:54:45.132 --> 01:54:52.372 upgrade SnackVotes so each person can only have one active vote per room. Jump into plan mode, 01:54:52.832 --> 01:55:00.092 run that. So here's the plan, one active vote per room. Add a lightweight session-based voting room. 01:55:00.092 --> 01:55:08.472 Each browser session gets a session ID, and Convex stores one active vote per room ID and 01:55:08.472 --> 01:55:15.852 session ID, right? So this needs to be unique. So if I voted in that room, my session ID was used to 01:55:15.852 --> 01:55:22.612 vote. And so this needs to be unique. So for that room, my session can only happen twice. If there 01:55:22.612 --> 01:55:29.112 is a chance for a repeat, it's not going to count it. Yeah, I can vote in other rooms, but per session, 01:55:29.272 --> 01:55:35.352 per room can only happen once. We're going to expand this, looks good, and submit this. So it 01:55:35.352 --> 01:55:43.032 done implemented one active vote per room okay change this what changed and it added this get 01:55:43.032 --> 01:55:49.672 my vote added votes with table so let's go ahead and try this out open this here so let's say i go 01:55:49.672 --> 01:55:55.192 to another room friend friday lunch i switch to that room and i have my burrito so i'm gonna vote 01:55:55.192 --> 01:56:01.512 for this i just voted and i can't vote again you see that i can't vote again because if i go to 01:56:01.512 --> 01:56:10.472 convex and I go into data and I go into votes, I should see a session ID with ROM ID. So let me go 01:56:10.472 --> 01:56:15.612 ahead and delete all of these so that we can see which one is mine. And so now I can vote again. 01:56:15.612 --> 01:56:23.792 You see it's back up. It's reactive. I'm going to hit vote. And now you see ROM ID and session ID. 01:56:23.992 --> 01:56:30.652 These two, they can only appear once in this table. And so obviously now it knows that my 01:56:30.652 --> 01:56:35.652 session ID and I'm trying to vote for this one and that's not going to work because I'm in this room. 01:56:35.872 --> 01:56:43.372 I'm in this room here, Friday lunch, Friday lunch right there. Now, if I switch rooms, let's say I go 01:56:43.372 --> 01:56:49.592 to another room. Let's say I go into Sunday brunch. Now I can vote, right? I can vote for anything. I 01:56:49.592 --> 01:56:56.252 can say tacos, submit. I can vote here and let's say I create another one. I can change my vote. 01:56:56.252 --> 01:57:02.832 So I can switch votes, but I cannot pad with multiple votes an item. 01:57:03.172 --> 01:57:05.752 And so if I go back here, now there are two options, right? 01:57:05.872 --> 01:57:11.972 Two different rooms, same session ID, but I cannot vote in the same room more than once. 01:57:12.152 --> 01:57:14.612 So this works really, really nice. 01:57:14.952 --> 01:57:21.232 And finally, we'll add a deadline so each room has a moment when voting closes. 01:57:21.892 --> 01:57:24.732 Before the deadline, people can submit and vote. 01:57:24.732 --> 01:57:31.772 After the deadline, voting locks and the app shows the winner or a simple tie state. 01:57:31.952 --> 01:57:37.292 This adds time-based product state without becoming a scheduling system. 01:57:37.452 --> 01:57:49.012 It is still a small group decision app, but now it shows how front-end UI and back-end data can derive open, closed, winner, and tie states from one field. 01:57:49.332 --> 01:57:51.572 And here's the prompt that we're going to be using. 01:57:51.572 --> 01:57:53.772 I'm going to switch into plan mode. 01:57:54.112 --> 01:57:54.752 Run this. 01:57:54.912 --> 01:57:56.812 Oh, it needs a product decision. 01:57:57.012 --> 01:58:02.152 Okay, how should users set a room deadline in this small tutorial version? 01:58:02.732 --> 01:58:03.792 Quick durations. 01:58:04.372 --> 01:58:07.932 Okay, add simple buttons like 1 minute, 5 minute, 15 minute. 01:58:08.152 --> 01:58:09.932 When creating opening a room. 01:58:10.292 --> 01:58:12.832 Daytime input or fixed default. 01:58:13.012 --> 01:58:14.352 Let's do quick durations. 01:58:14.712 --> 01:58:15.512 That sounds good. 01:58:15.612 --> 01:58:16.852 Let's implement this. 01:58:17.052 --> 01:58:18.272 And it is complete. 01:58:18.432 --> 01:58:20.612 Implemented simple voting deadlines. 01:58:20.612 --> 01:58:22.092 This is what was changed. 01:58:22.612 --> 01:58:24.672 Added quick deadline choices. 01:58:24.852 --> 01:58:28.312 No deadline, one minute, five minutes, 15 minutes. 01:58:28.472 --> 01:58:29.412 All of this. 01:58:29.652 --> 01:58:32.132 And let's go ahead and see how this works. 01:58:32.432 --> 01:58:32.812 All right. 01:58:32.872 --> 01:58:33.912 So here we are. 01:58:34.092 --> 01:58:37.112 And let's go ahead and create the room, Friday lunch. 01:58:37.412 --> 01:58:39.252 And let's say it's five minutes. 01:58:39.452 --> 01:58:40.632 Select five minutes. 01:58:41.072 --> 01:58:41.692 Open the room. 01:58:41.892 --> 01:58:43.392 This still says no deadline. 01:58:43.532 --> 01:58:44.532 Let's try another room. 01:58:44.612 --> 01:58:46.712 Let's say Sunday brunch. 01:58:46.972 --> 01:58:48.332 I can select no deadline. 01:58:48.532 --> 01:58:49.752 I can do 15 minutes. 01:58:49.752 --> 01:58:51.072 Let's try 15 minutes. 01:58:51.532 --> 01:58:52.932 See, it says no deadline. 01:58:53.092 --> 01:58:54.072 Okay, that's a bug. 01:58:54.272 --> 01:58:55.532 That's definitely a bug. 01:58:55.652 --> 01:58:57.632 So let's see if it's able to fix it. 01:58:57.672 --> 01:59:03.132 That's the first bug that has happened to us, as far as I remember. 01:59:03.892 --> 01:59:10.832 And so we're going to say, create it, tried creating a room and selecting a deadline, 01:59:10.832 --> 01:59:12.832 but it ended up creating... 01:59:15.448 --> 01:59:22.308 And we don't really need plan mode for this. There's no clarifying questions here. It's a 01:59:22.308 --> 01:59:28.348 simple bug. And we don't really want it to clarify. We know what the bug is. We just wanted to fix 01:59:28.348 --> 01:59:35.148 it so there's really no ambiguity there it's like it's like i'm not looking to negotiate with codex 01:59:35.148 --> 01:59:40.908 i know this is a bug and i wanted to fix it right there's no other ways there's nothing else 01:59:40.908 --> 01:59:46.028 happening unless i'm wrong and in that case it's going to tell me that i'm wrong that it works but 01:59:46.028 --> 01:59:53.948 there's no other paths here as far as i'm concerned now sometimes codex would output something like 01:59:53.948 --> 02:00:02.488 this and it tries to go into plan mode. And so right now it thinks it's in plan mode, but it's, 02:00:02.648 --> 02:00:08.488 it actually is not in plan mode. And so if I say something like do it, it's going to complain that, 02:00:08.648 --> 02:00:14.908 that I did not leave the plan mode while I'm not in the plan mode. So this is a bug that I have 02:00:14.908 --> 02:00:22.008 been experiencing from time to time. And it's annoying, but it's, it's easily fixable. You see, 02:00:22.008 --> 02:00:26.288 it says I can't edit files because this thread is in plan mode, but we're not in plan mode. 02:00:26.768 --> 02:00:32.908 And so the solution is to go into plan mode and type something. Okay, fix it. And then it's going 02:00:32.908 --> 02:00:37.648 to say something like, well, you know, I can't do it. I'm in plan mode. And then you can leave plan 02:00:37.648 --> 02:00:43.368 mode. Now it understands it. You see, now it's correct. Fix the bug where it's selecting a 02:00:43.368 --> 02:00:48.708 deadline and opening an existing no deadline room still leaves the room with no deadline. 02:00:48.708 --> 02:00:53.988 So we're going to submit this. All right. So it looks like it fixed it. And here it says in the 02:00:53.988 --> 02:01:00.648 browser, I created a no deadline room, reopened it with 15 minutes, and it showed open plus closes in, 02:01:00.788 --> 02:01:06.408 et cetera. So let's go ahead and test this out ourselves to ensure that it does really work. 02:01:06.528 --> 02:01:13.608 So we have this and let's do Friday lunch. And we said 15 minutes. And now it shows it. 02:01:13.608 --> 02:01:20.568 and let's say one minute. Room one, one minute. There we go. One minute. And let's try no deadline. 02:01:20.788 --> 02:01:28.248 Room two, select no deadline, open no deadline. Okay, so this looks like this was finally fixed. 02:01:28.248 --> 02:01:36.448 Now, once SnackVote has rooms, session-based voting, and a deadline, we are ready to deploy 02:01:36.448 --> 02:01:43.248 the front-end app with Vercel and verify that the deployed app points to the right backend 02:01:43.248 --> 02:01:49.808 environment. And this will round up this specific app build. And here's our prompt, prepare snack 02:01:49.808 --> 02:01:57.448 mode for deployment on Vercel and verify it works with the convex backend. Okay, I'm just going to do 02:01:57.448 --> 02:02:04.028 it in plan mode, run that. Here it's being very, very clever. One important deployment decision 02:02:04.028 --> 02:02:10.988 remains whether the Vercel app should use the existing Convex dev deployment or it should 02:02:10.988 --> 02:02:15.388 promote it to production. Okay and this is really really cool because this is something that I 02:02:15.388 --> 02:02:21.468 wanted to cover once this was done. So if we go into Convex and you click over here you can see 02:02:21.468 --> 02:02:27.548 all your deployments, your different deployments. So we are currently on the development deployment, 02:02:27.548 --> 02:02:33.228 on the development cloud. We can also have a production deployment, preview deployments, 02:02:33.228 --> 02:02:39.168 other deployments, stuff like that. So ideally, once we deploy it with Vercel, we wanted to use 02:02:39.168 --> 02:02:43.688 the production convex, and that's what we're going to select, because this makes sense. 02:02:43.868 --> 02:02:51.188 Production deployment uses the production convex. Development deployment uses the development 02:02:51.188 --> 02:02:58.768 convex. This is our plan, prepare, snack vote for a production Vercel deploy connected to the convex 02:02:58.768 --> 02:03:05.688 production backend. We're going to hit submit, and it's going to create a production. In fact, 02:03:05.748 --> 02:03:11.268 they already did it, right? We can switch to this, and it's going to have a production environment 02:03:11.268 --> 02:03:17.688 here created for us. All right, so it has deployed SnackVote to Vercel and verified it against 02:03:17.688 --> 02:03:24.048 convex production, okay? So this is the live URL, what we're seeing here, deployment URL, 02:03:24.048 --> 02:03:25.688 and the convex backend. 02:03:26.128 --> 02:03:27.548 And if we go into convex, 02:03:28.328 --> 02:03:30.308 you can see that it's currently pointing 02:03:30.308 --> 02:03:32.328 to the production URL here. 02:03:32.388 --> 02:03:34.068 And we have everything here in production. 02:03:34.328 --> 02:03:36.468 So we have the dev instance 02:03:36.468 --> 02:03:39.508 pointing to the dev deployment in convex 02:03:39.508 --> 02:03:42.508 and the production instance in Vercel 02:03:42.508 --> 02:03:46.088 pointing to the production instance here in convex. 02:03:46.368 --> 02:03:48.148 So we have all the same functions. 02:03:48.148 --> 02:03:49.868 We have all the same data. 02:03:49.968 --> 02:03:50.928 Everything is there. 02:03:51.128 --> 02:03:52.808 The data might be a little different, 02:03:52.808 --> 02:03:59.908 but the schema is exactly the same and it works, right? So we can create a room, whatever, new room, 02:04:00.128 --> 02:04:06.688 one minute, open it. And now 59 seconds, 58 seconds looks good. We can create another room, 02:04:06.928 --> 02:04:12.428 room three, no deadline. And that has no deadline. So I'm currently in this room. I can create 02:04:12.428 --> 02:04:19.168 a food option. I can vote. I can't vote anymore. One active vote per room. This is the leaderboard. 02:04:19.168 --> 02:04:48.308 So it looks really good. And this time we've actually built a fairly cool and a fun app along with a backend that uses several different deployments depending on where the app is running. So for local deployment, we have the local, the dev convex deployment. And for the production, we're cell deployment, we're using the production convex deployment. Okay, so this was a slightly more complex app. 02:04:48.308 --> 02:04:54.568 But there's still one more app that I want to build, and this app is going to be the most complex of them all. 02:04:54.648 --> 02:04:59.248 It's going to bring a lot of these things that we've been talking about so far together. 02:04:59.588 --> 02:05:06.728 And also, we're going to be introducing some new functionality, new features, and a lot of really cool things. 02:05:09.548 --> 02:05:13.808 Now, for this last app in the course, we're going to be building FlexHelp. 02:05:13.808 --> 02:05:20.228 And this is where we take the workflow from the first two smaller apps and apply it to a more realistic product. 02:05:20.488 --> 02:05:26.528 A two-sided marketplace where helpers offer fixer services and customers book them. 02:05:26.748 --> 02:05:30.388 The important thing is that we will still build it in controlled steps. 02:05:30.588 --> 02:05:34.028 We're not going to ask Codex to build the whole marketplace at once. 02:05:34.168 --> 02:05:38.808 We are going to architect it, design it, build the UI, then add feature by feature. 02:05:38.808 --> 02:05:43.968 feature. And last but not least, we're going to be deploying the app, making it available to anyone. 02:05:44.268 --> 02:05:50.348 As always, our first step will be creating the visual architecture. This gives us the shape of 02:05:50.348 --> 02:05:56.788 the product, the customer flow, the helper flow, the main screens, and the path from browsing a 02:05:56.788 --> 02:06:02.048 service to booking help. Now, here in Codex, we're going to click here and we're going to create a 02:06:02.048 --> 02:06:06.848 brand new project. Now, I like to start it from an existing folder, and I'm going to create a new 02:06:06.848 --> 02:06:12.988 folder. Flex help. I'm going to hit create and I'm going to click open and that creates a brand new 02:06:12.988 --> 02:06:18.008 project. Now the first thing that we're going to be doing is we're going to be building a visual 02:06:18.008 --> 02:06:23.128 architecture. The same thing that we did for the previous two apps and this is important because 02:06:23.128 --> 02:06:28.608 this gives us the shape of the product, the customer flow, the helper flow, the main screens 02:06:28.608 --> 02:06:34.288 and the path from browsing a service to booking help. And here's the prompt that I'm going to be 02:06:34.288 --> 02:06:40.808 using. And I want to specify that we want to use image gen. We're going to jump into plan mode and 02:06:40.808 --> 02:06:46.368 we're going to run this. And here we have the Flex Help Visual Architecture. And here's a better view. 02:06:46.648 --> 02:06:51.588 And so here we have the customer, we have the shared marketplace screens, and we have the helper, 02:06:51.768 --> 02:06:57.448 which are the two sides of this marketplace. We also have the convex and the versell here. 02:06:57.448 --> 02:07:03.408 On the customer side, we have browse services, get the service detail, and then send a booking 02:07:03.408 --> 02:07:08.608 request. The helper side, we have the helper dashboard and the status updates. And on the 02:07:08.608 --> 02:07:13.368 shared marketplace screens, we have explore the marketplace, buy bookings, and... 02:07:15.408 --> 02:07:20.268 bat, this app is a bit more complex than the previous apps that we were building. And that's 02:07:20.268 --> 02:07:27.788 really the goal to finish off with a more complex, but also a more realistic, more production-ready 02:07:27.788 --> 02:07:33.328 app. Next, we'll map the core entities. And this is where the product becomes more tangible, 02:07:33.588 --> 02:07:39.768 because we can actually see the real objects in the app before Codex starts writing the schema 02:07:39.768 --> 02:07:46.448 or code. And here's our prompt. We want to preface this with this image. All right, and here's our 02:07:46.448 --> 02:07:52.168 entity architecture. Okay, so we have the user that could be a customer or a helper profile. 02:07:52.168 --> 02:07:57.588 We have the booking here, booking status, service, category, review, and all of that 02:07:57.588 --> 02:07:59.908 backed with convex data. 02:08:00.148 --> 02:08:05.528 So at this point, we have a better idea of how the final app is going to look. 02:08:05.628 --> 02:08:10.168 I see that we need a user entity, and that could be a customer or a helper profile. 02:08:10.268 --> 02:08:14.648 And I see that booking is super important because everybody needs to have access to 02:08:14.648 --> 02:08:19.048 booking, both customers and helpers, booking status, service, category. 02:08:19.048 --> 02:08:25.728 And so right away, I see that this is a fairly sophisticated app, but I can see that it's not 02:08:25.728 --> 02:08:32.628 a super complex or like a super complicated app that has a ton of different entities, 02:08:32.848 --> 02:08:38.688 has lots of things happening. But still, as we are developing this app, we might be adding 02:08:38.688 --> 02:08:44.328 various entities. And so that will increase the complexity as the development continues. 02:08:44.328 --> 02:08:50.688 Now, the next step is before we start actually building the app is we want to ask Codex to 02:08:50.688 --> 02:08:58.608 recommend the simplest stack for FlexHelp based on what we need to build, based on what we've 02:08:58.608 --> 02:09:05.448 told it so far. This keeps the technology choices tied to the product instead of starting with tools 02:09:05.448 --> 02:09:11.508 first. And this is super important because we want to start with the blueprint before 02:09:11.508 --> 02:09:17.608 any code has been written. And here's the prompt to do that. Do not edit any files and spec 02:09:17.608 --> 02:09:22.408 everything. And I'm going to be running this in plan mode so that I can decide whether I want to 02:09:22.408 --> 02:09:27.548 accept its recommendations or just leave it in the conversation. I'm going to run this here. 02:09:27.648 --> 02:09:32.848 This is what it's suggesting. The workspace is currently empty. The simplest course-friendly 02:09:32.848 --> 02:09:41.208 stack is React, TypeScript, Convex for backend data, auth, Tailwind for UI, and Resell for hosting. 02:09:41.208 --> 02:09:44.488 And this is exactly what we've been doing so far. 02:09:44.728 --> 02:09:47.148 And here it's listing some primary routes. 02:09:47.428 --> 02:09:51.548 Services, bookings, customer bookings, helper, helper services. 02:09:51.948 --> 02:09:54.668 Here we have the data flow, the auth recommendations, 02:09:55.008 --> 02:09:56.948 UI and component approach, 02:09:57.228 --> 02:10:01.388 verse cell deployment path, stage build plan, everything. 02:10:01.648 --> 02:10:06.648 So I'm going to exit out because this was only a read-only plan mode. 02:10:06.808 --> 02:10:08.888 I don't want it to do anything just yet 02:10:08.888 --> 02:10:11.588 because that's what we're going to be doing in the next step. 02:10:11.688 --> 02:10:15.568 Now, from the visual architecture, the entity map, and the stack recommendation, 02:10:15.928 --> 02:10:21.008 we have a pretty good idea of how the Flex Help app is evolving. 02:10:21.328 --> 02:10:25.648 The next thing that we want to do is we want to get Codex to take a first pass 02:10:25.648 --> 02:10:29.168 at turning that plan into a static product UI. 02:10:29.628 --> 02:10:32.468 Now, this first version does not need any backend data. 02:10:32.468 --> 02:10:39.328 The goal is to see how far Codex can get from the architecture alone to viable UI mockups. 02:10:39.688 --> 02:10:41.328 And this is the prompt that I'm going to be using. 02:10:41.488 --> 02:10:47.428 Build the first static FlexHelp UI design from the existing architecture and stack direction. 02:10:47.748 --> 02:10:49.308 We're going to stay in the plan mode. 02:10:49.568 --> 02:10:51.008 I'm going to go ahead and execute that. 02:10:51.248 --> 02:10:52.868 And let's see how well it does. 02:10:53.168 --> 02:10:55.188 And here's the plan that it came up with. 02:10:55.268 --> 02:11:00.848 Okay, the goal is a polished visual prototype that matches the FlexHelp architecture. 02:11:00.848 --> 02:11:03.808 Okay, and here it lists some details about the architecture. 02:11:04.248 --> 02:11:07.248 And let's go ahead and run this prompt. 02:11:07.408 --> 02:11:08.988 So it finished working. 02:11:09.448 --> 02:11:12.068 And let's go ahead and see what we have here. 02:11:12.188 --> 02:11:13.848 Okay, so this is our app. 02:11:14.008 --> 02:11:15.888 And this is kind of how it looks like. 02:11:16.028 --> 02:11:17.588 Okay, book practical help. 02:11:17.748 --> 02:11:20.128 And we have some active requests. 02:11:20.368 --> 02:11:22.668 We have booking entry, helper dashboard. 02:11:23.228 --> 02:11:24.108 We have this. 02:11:24.428 --> 02:11:24.968 Look at this. 02:11:25.088 --> 02:11:25.988 It even works. 02:11:26.328 --> 02:11:30.828 Service detail, a small plumbing repair, helper dashboard. 02:11:30.848 --> 02:11:36.968 shell. And so this UI doesn't look too bad, but there is something that you need to know when you 02:11:36.968 --> 02:11:44.488 design UI with Codex. They all look pretty much the same, or at least very, very similar. And that 02:11:44.488 --> 02:11:51.708 is because Codex is not really an expert when it comes to designing pages. It's great for coding, 02:11:51.968 --> 02:11:57.988 for solving all kinds of problems, but for actually designing stuff, it's not the most 02:11:57.988 --> 02:12:03.708 ideal tool. There are a lot of other tools that do it a lot better. And so during this specific 02:12:03.708 --> 02:12:10.208 app build, I want to bring in another tool and show you how we can have a more specialized tool, 02:12:10.388 --> 02:12:16.868 actually design the UI, and then bring that UI back into Codex and get Codex to kind of implement 02:12:16.868 --> 02:12:23.068 it. Okay. Now, when it comes to UI designs, there's lots of cool tools. There's Google Stitch, 02:12:23.068 --> 02:12:28.528 there's Figma, and there's also a tool that I really like to use, and it is called Flutter 02:12:28.528 --> 02:12:34.828 Flow Designer. It's a very, very lightweight tool, and it works really great with Codex. 02:12:35.068 --> 02:12:41.488 And so if you head over to designer.flutterflow.io, you're going to be on this page here. And you can 02:12:41.488 --> 02:12:46.748 use the web app version here, but what I really like to do is I like to use their desktop app, 02:12:46.748 --> 02:12:52.028 okay? Here's the desktop app. And what's nice about the desktop app is that you have this 02:12:52.028 --> 02:12:59.928 tab integrations. So if you click over here, you can connect designer to external agents and IDE. 02:13:00.368 --> 02:13:06.328 So Claude Code, Gemini CLA, and Codex. And so I have this setup. So all you need to do is click 02:13:06.328 --> 02:13:14.188 here. Now it's installed. And now this app here is going to serve as an MCP server. Okay. Because 02:13:14.188 --> 02:13:21.688 if I go to Codex here and I press command comma, and I go into MCP servers, I also have this 02:13:21.688 --> 02:13:26.768 Flutterflow Designer configured here. And if you want to set this up, you can simply ask Codex to 02:13:26.768 --> 02:13:32.028 do it. It's going to research, it's going to figure out, and it's going to eventually set it up for you 02:13:32.028 --> 02:13:37.868 so that you can have this Flutterflow Designer as one of your MCP servers here. Okay, so now that we 02:13:37.868 --> 02:13:44.028 have this set up, what we want to do is we want to go into this Designer, and we want to click on 02:13:44.028 --> 02:13:49.628 New Design. And here you can enter a prompt, ask you to design any kind of app UI for you, whether 02:13:49.628 --> 02:13:55.708 it is a mobile app or desktop app. They also have, you know, explore styles feature, or you can have 02:13:55.708 --> 02:14:00.748 an instant generation. Now, what you don't want to do is you do not want to type this prompt directly. 02:14:00.748 --> 02:14:06.868 You want to ask Codex to generate a prompt for you, since it knows a lot more about the app, 02:14:07.008 --> 02:14:12.508 that you can input here. And this is the same workflow regardless of whether you're using this 02:14:12.508 --> 02:14:18.708 tool, Google Stitch, or pretty much any other tool out there. And so we're going to go ahead and we're 02:14:18.708 --> 02:14:23.548 going to grab a prompt to do just that. And here's a prompt that we can use. Create a polished 02:14:23.548 --> 02:14:29.708 Waterflow Designer concept for FlexHelp. FlexHelp is a two-sided marketplace, and we are telling it 02:14:29.708 --> 02:14:35.428 what kind of screens to design. We give it some design requirements. We give it some guardrails, 02:14:35.648 --> 02:14:39.908 stuff like that. And so we're going to input this prompt, and here we're going to stay on 02:14:39.908 --> 02:14:45.328 Explore Styles, and that way we can have different styles show up, and we can decide which one we 02:14:45.328 --> 02:14:50.488 like better. So I'm going to go ahead and run this. And here are the designs. So as you can see, 02:14:50.548 --> 02:14:56.888 they're all very different. We have this, we have this, we have this, we have these ones. So, 02:14:57.028 --> 02:15:03.088 and you got to admit that in my view, these look a lot better than what Codex did, right? So this 02:15:03.088 --> 02:15:10.528 is what Codex did. In my view, these designs are a lot more interesting than Codex's design. Okay, 02:15:10.528 --> 02:15:12.408 So I don't know which one you guys like. 02:15:12.628 --> 02:15:13.368 This is a classic. 02:15:13.368 --> 02:15:17.408 one you guys like this is a classical one this is nice let's take a look let's go ahead and use this 02:15:17.408 --> 02:15:22.368 classical one so i'm gonna say use this style and it's gonna use the sound that is gonna generate 02:15:22.368 --> 02:15:27.808 all the pages that we need so here we have seven pages that we need so now we have all the pages 02:15:27.808 --> 02:15:35.948 Here we have customer home, we have service details, really nice page, booking request form, customer booking status. 02:15:36.188 --> 02:15:41.648 We even have a map, helper dashboard, helper request management, and a user profile. 02:15:41.788 --> 02:15:50.528 The next thing that we want to do is we want to tell Codex to fetch these designs and implement them, bake them into our app. 02:15:50.608 --> 02:15:51.708 And so let's take a look. 02:15:51.788 --> 02:15:55.348 So this is called Flex Help Marketplace, the name of the project here. 02:15:55.348 --> 02:15:58.468 And so now what we're going to do is we're going to go back to Codex. 02:15:58.728 --> 02:16:00.868 We're going to close out this section here. 02:16:01.048 --> 02:16:05.648 And we're going to give it a prompt that's going to ask it to connect to Flutter Flow Designer. 02:16:06.008 --> 02:16:13.508 Look at that specific project and grab those designs and bake them into our app right here. 02:16:13.708 --> 02:16:15.968 And I have a prompt here to do just that. 02:16:16.088 --> 02:16:16.968 So here's the prompt. 02:16:17.048 --> 02:16:21.748 Update the FlexSelf Static UI to match the approved Flutter Flow Designer reference. 02:16:21.748 --> 02:16:28.988 So this is the main prompt, but we also need to ensure that we tell it that we want to use the Flutterflow Designer MCP. 02:16:29.168 --> 02:16:38.628 Use Flutterflow Designer MCP, and then project is, because there are multiple projects, so we want to copy this project here, this. 02:16:38.848 --> 02:16:43.628 And we're going to go into plan mode just to make sure that everything is good, and I'm going to run that. 02:16:43.628 --> 02:16:51.688 And here it says next, I'm opening a Designer MCP session, and once it does that, you can see, you can actually see the agent working. 02:16:51.748 --> 02:16:58.588 This is our agent, our client, because Codex is acting as an MCP client connecting to this MCP 02:16:58.588 --> 02:17:04.568 server. And as you can see, it's analyzing this page. And you can see this little Codex icon here. 02:17:04.708 --> 02:17:09.808 And you can see it says here, one active agent. It's studying the designs. And then it's going 02:17:09.808 --> 02:17:17.868 to pull the designs back here and build an actual UI using those designs. And the goal here is to 02:17:17.868 --> 02:17:23.768 ensure that it builds a pixel perfect, or at least as close as possible to what we see here. 02:17:24.008 --> 02:17:29.548 Okay, so let's see what it's doing. So now it came back with a plan. Update the existing React 02:17:29.548 --> 02:17:35.728 static UI to visually follow the approved Flutter Flow Designer reference. So here it has 02:17:35.728 --> 02:17:43.468 five pages, but over here we actually have more. We have seven pages. So I don't know if it missed 02:17:43.468 --> 02:17:50.768 it or that it wasn't part of the prompt or some mix-up. So we want to make sure that it captures 02:17:50.768 --> 02:17:58.588 all the seven pages. Ensure that it captures all the seven pages from Flutter Flow Designer project. 02:17:58.928 --> 02:18:04.728 Okay, and still in the plan mode, just to make sure we get this right, because our app ideally 02:18:04.728 --> 02:18:10.768 should have all of these pages. User profile helper, request management helper dashboard, 02:18:10.768 --> 02:18:16.528 etc etc all of these make sense okay so it went ahead and it updated it and it's going to add 02:18:16.528 --> 02:18:22.448 static page components for all seven pages okay submit this all right so it has implemented the 02:18:22.448 --> 02:18:28.768 seven page designer reference update let's go ahead and see how it looks all right so this looks 02:18:28.768 --> 02:18:36.048 a lot better in my opinion right we have settings we do have this ch customer home do we even see 02:18:36.048 --> 02:18:43.228 that? I don't even see that here. But this customer home service details, click on book. So this menu, 02:18:43.368 --> 02:18:48.828 we need to kind of remove this. So let me go ahead and sell it. What are those abbreviations? Let's 02:18:48.828 --> 02:18:56.308 see. They need to be there and see what it says. But it looks a lot cleaner than the original UI, 02:18:56.548 --> 02:19:03.388 at least to my eyes. And now we're doing a little bit of tweaking, cleanup plan. Okay. They were 02:19:03.388 --> 02:19:10.468 placeholder text icons used to mimic the nav icon column. So we need to remove that and we should 02:19:10.468 --> 02:19:16.008 probably remove any other placeholder icons. But right now it looks fairly clean. Static preview, 02:19:16.128 --> 02:19:22.448 what is that? This also needs to be removed. So we're going to actually tell it, check for any 02:19:22.448 --> 02:19:29.108 placeholders and see if you can match what it should be on the design. Pull the design elements 02:19:29.108 --> 02:19:33.168 and replace these placeholders with the actual design. 02:19:33.448 --> 02:19:34.708 All right, so let's fix it. 02:19:34.768 --> 02:19:35.868 Now it looks a lot better. 02:19:35.968 --> 02:19:38.268 We still see some other static preview. 02:19:38.368 --> 02:19:38.908 That's okay. 02:19:39.068 --> 02:19:43.148 Let's see if they go away once we have real data being fed. 02:19:43.288 --> 02:19:45.228 So once we're happy with the UI, 02:19:45.528 --> 02:19:48.128 we can start designing the backend. 02:19:48.128 --> 02:19:50.588 Data model should match the screens 02:19:50.588 --> 02:19:52.068 that we actually have here. 02:19:52.508 --> 02:19:53.648 And so for FlexHelp, 02:19:53.868 --> 02:19:56.848 the first schema should support service browsing, 02:19:57.028 --> 02:19:58.908 helper profiles, booking creation, 02:19:59.108 --> 02:20:06.068 and helper status updates anything beyond that can wait and here's a prompt that we can use 02:20:06.068 --> 02:20:12.868 to connect our app to convex okay we're going to be using convex for this app as well so we have 02:20:12.868 --> 02:20:19.828 here connect flex hill ui to live convex service and helper data let's go ahead and keep it in plan 02:20:19.828 --> 02:20:25.508 mode all right so this is our plan this is the convex read path plan connect the customer facing 02:20:25.508 --> 02:20:32.268 marketplace UI to convex for the first database-backed read path. The repo currently has 02:20:32.268 --> 02:20:39.108 no convex setup to add convex from scratch, et cetera, et cetera. And we have convex here running. 02:20:39.248 --> 02:20:44.628 We have these three projects, one that was created for the other app that we did. And so we're going 02:20:44.628 --> 02:20:50.888 to be creating another project for this app as well. So it has implemented the first convex-backed 02:20:50.888 --> 02:20:55.668 read path for the customer marketplace. And these are the files that has changed. This is what's 02:20:55.668 --> 02:21:01.608 connected. And if we jump into our Convex dashboard, we can see we have a brand new project here that 02:21:01.608 --> 02:21:08.068 wasn't there before. And if we jump here, we should see that we have a deployment here on my 02:21:08.068 --> 02:21:15.348 own machine. This is a local deployment that Convex is running on, right? This is not on Convex. It's 02:21:15.348 --> 02:21:20.988 on my own machine. And we also have a production, right? So with this deployment here, you go into 02:21:20.988 --> 02:21:27.288 data, we can see that we have categories, we have helper profiles, we also have services, and then 02:21:27.288 --> 02:21:32.928 we have a bunch of functions, right? Marketplace list, and then we have seed, creating seed data. 02:21:33.168 --> 02:21:37.828 Now, if you go into production, we may not see anything there, right? There's nothing there 02:21:37.828 --> 02:21:43.748 because we haven't deployed this app to production. There's no need for a production deployment. Now, 02:21:43.748 --> 02:21:50.068 if you jump back to Codex and we refresh the app, this is now data that it's pulling from my local 02:21:50.068 --> 02:21:55.788 convex deployment. Okay, so we have here Marcus. If we go back here, we should see Marcus, right? 02:21:55.868 --> 02:22:01.528 Helper profiles, there's Marcus. And if I change Marcus, if I edit name and I change, let's say, 02:22:01.628 --> 02:22:06.568 Marcus, right? And I go back here, now it's automatically Marcus E here. It automatically 02:22:06.568 --> 02:22:12.268 updates. If I change that to James, guess what? Now it says James S. So as you can see, this is 02:22:12.268 --> 02:22:17.868 now linked to our local Convex instance on my machine. Both of these are on my machine. Now, 02:22:17.888 --> 02:22:22.748 the next thing that I want to do is I want to build out the booking flow because that's the key 02:22:22.748 --> 02:22:28.668 in this app, right? The ability to book these services. And I have a prompt here as well. 02:22:28.888 --> 02:22:34.008 We're going to be using this prompt right here. Okay. Add the customer booking flow to FlexHelp, 02:22:34.288 --> 02:22:39.808 inspect all of this, and I'm going to set this to plan mode. And let's go ahead and run that. 02:22:39.808 --> 02:22:45.168 That's our plan. We're going to be adding the first customer site booking creation path on top 02:22:45.168 --> 02:22:50.448 of the existing convex back service listing. And there's some information there. We're going to 02:22:50.448 --> 02:22:55.508 implement this plan. All right. So it has implemented the customer booking creation path. 02:22:55.728 --> 02:23:02.388 And it also tested it out. As you can see, there's also a booking here as well. So let's go ahead and 02:23:02.388 --> 02:23:07.968 see if this works. All right. So let's say I want to book James. Click over here. So I can't quite 02:23:07.968 --> 02:23:13.348 pick anything here, but I can do request to book, send booking request, and I need an 02:23:16.168 --> 02:23:22.908 We need autocomplete here as well. Fill in every field. Okay. So task, task. Okay. This I cannot 02:23:22.908 --> 02:23:30.328 fill. Every fill. Okay. Customer schedule at 10 a.m. And this obviously needs to be, you know, 02:23:30.348 --> 02:23:35.408 like a calendar picker, that kind of thing. Okay. And now we have the booking request. And I can 02:23:35.408 --> 02:23:41.948 click on view bookings and I see my bookings. Okay. So this was done by the Codex while it was 02:23:41.948 --> 02:23:48.428 testing. So now if we jump into Codex, we should see on my local instance here, we should see 02:23:48.428 --> 02:23:54.088 bookings. And we see two bookings. Okay, right here. So the booking flow seems to work. There 02:23:54.088 --> 02:23:58.808 are some rough edges here and there that we need to fix. But for the most part, it is coming 02:23:58.808 --> 02:24:04.508 together. Now, once customers can create bookings, helpers need a place to see and manage them. 02:24:04.968 --> 02:24:10.788 The helper dashboard should show incoming requests and make it obvious what action the helper can 02:24:10.788 --> 02:24:16.328 take next. At the simplest level, the helper should be able to accept or decline a request. 02:24:16.328 --> 02:24:22.708 After accepting, the helper should be able to move the job into progress and then mark it completed. 02:24:23.068 --> 02:24:27.268 Those status changes are what turn the app into a workflow. 02:24:27.608 --> 02:24:31.088 This is also a good place to show the power of live data. 02:24:31.348 --> 02:24:36.428 When a status changes, the UI should update and the convex row should change. 02:24:36.588 --> 02:24:39.868 That gives us a real end-to-end marketplace loop. 02:24:40.068 --> 02:24:44.288 Customer request, helper action, back-end stay, and UI update. 02:24:44.288 --> 02:24:49.048 And this is the prompt that we're going to be using. Add the helper dashboard workflow for 02:24:49.048 --> 02:24:54.948 viewing booking requests and updating booking status. Okay, I'm going to switch into plan mode, 02:24:55.148 --> 02:25:00.548 and we're going to go ahead and send this. So it's asking me that how should the helper workflow 02:25:00.548 --> 02:25:06.008 handle the existing requested booking status? Keep requested. This is recommended. Preserve 02:25:06.008 --> 02:25:11.488 existing created bookings. Show it as pending in the UI or rename to pending. Change the stored 02:25:11.488 --> 02:25:16.928 initial status to pending and requires more data. So we don't want any migration. We just want to 02:25:16.928 --> 02:25:22.928 go with the easiest option. And then how should the helper request visibility work before auth 02:25:22.928 --> 02:25:29.328 is added? Helper selected. This is add a simple static helper switcher filter so each helper sees 02:25:29.328 --> 02:25:34.828 bookings for their convex helper profile only. Simplest UI and backend, but less realistic. So 02:25:34.828 --> 02:25:40.228 we want helper selected. Okay, we're going to select that. All right, there's the plan. Add the 02:25:40.228 --> 02:25:45.148 first helper-facing workflow on top of existing convex booking creation path. We're going to 02:25:45.148 --> 02:25:50.828 submit this. Here's our progress. All right, so we just implemented the helper booking status 02:25:50.828 --> 02:25:55.508 workflow. These are the files that changed. This is what it did. So it updated it through pending, 02:25:55.828 --> 02:26:02.228 accepted, in progress, completed. It viewed it under helper James, created booking this. So it 02:26:02.228 --> 02:26:07.088 did all that. It did some tests. Let's go ahead and open it, and let's see what we can do. So this 02:26:07.088 --> 02:26:13.328 is the helper booking status. By going to helper dashboard, have my incoming requests, right? So I 02:26:13.328 --> 02:26:19.328 can accept it, I can start it, and I can complete it, okay? So that's the piece that is working. I 02:26:19.328 --> 02:26:24.688 can also cancel it, and that is canceled, and that's it. I can't come back to it. I can't do 02:26:24.688 --> 02:26:29.508 anything. Here we have recent activity, right? Completed, completed, canceled. And this is the 02:26:29.508 --> 02:26:36.108 one that did, 148.116. This is the one that it has completed. This seems to work, right? And we have 02:26:36.108 --> 02:26:41.308 canceled, we have completed. Even a simple marketplace has different responsibilities. 02:26:41.548 --> 02:26:47.008 Customers create booking requests and view their own bookings. Helpers manage requests that belong 02:26:47.008 --> 02:26:53.728 to them or are available to them. Admin or system logic may handle category moderation or platform 02:26:53.728 --> 02:26:59.408 level controls later. The key point is that these rules should not only live in the UI. Backend 02:26:59.408 --> 02:27:05.728 functions need to enforce ownership and permissions because the UI can always be bypassed. 02:27:05.728 --> 02:27:11.888 This is where Codex needs to think carefully instead of just adding buttons. And so now what 02:27:11.888 --> 02:27:17.488 we want to do is we want to add the roles, auth, and the access boundary layer. And here's the 02:27:17.488 --> 02:27:23.648 prompt to do that. Add the first practical roles, auth, and access boundary layer around the existing 02:27:23.648 --> 02:27:28.528 FlexHelp workflows. Okay? So we're going to go definitely in the plan mode. We're going to run 02:27:28.528 --> 02:27:34.208 this and see what it says. And so it has a question for us. Which identity approach should this plan, 02:27:34.208 --> 02:27:41.768 should this step plan for demo sessions add convex back demo users and or convex 02:27:41.768 --> 02:27:47.288 or add real convex or sign and sign up more production shape but larger and 02:27:47.288 --> 02:27:51.548 currently beta or this clerk use third-party auth provider let's go with 02:27:51.548 --> 02:27:56.828 convex or how should customer helper roles be represented for version one 02:27:56.828 --> 02:28:02.768 role plus profile so what is this each demo user has customer helper both and 02:28:02.768 --> 02:28:08.188 and helpers linked to one helper profile for requests. Separate accounts. Customer and helper 02:28:08.188 --> 02:28:15.488 are always separate demo users. Simpler boundaries, but less flexible. And sometimes when I'm not sure, 02:28:15.688 --> 02:28:20.888 but I want the system to come up with a really solid answer, this is what I usually type. For 02:28:20.888 --> 02:28:28.228 the second question, what's the most durable long-term option? Okay, that's the key here, 02:28:28.228 --> 02:28:34.188 durable. And let's see what it says. The most durable long-term option is role plus profile. 02:28:34.268 --> 02:28:39.948 Perfect. That's it. And for the first question, choose demo sessions for this course step. Okay, 02:28:40.008 --> 02:28:47.348 so let's go ahead with demo sessions. Okay, so do demo sessions and role plus profile. Let's just 02:28:47.348 --> 02:28:53.628 go with the recommendations. Expand it. All right, so now you can see that Codex is testing everything, 02:28:53.628 --> 02:28:59.588 right? It's testing on the UI in the browser. And you see this cursor right here. The browser 02:28:59.588 --> 02:29:05.148 flow now confirms a customer created booking appears for the linked helper and can be moved 02:29:05.148 --> 02:29:10.668 into in progress. All right. So it has finished and it has implemented the demo roles and access 02:29:10.668 --> 02:29:17.428 boundary layer over here. Okay. So marketplace browsing stays public. Booking creation requires 02:29:17.428 --> 02:29:24.348 a customer or both demo user. Customer booking status only shows bookings owned by the signed 02:29:24.348 --> 02:29:31.128 in customer. Helper request status updates require a helper or both demo user with a linked helper 02:29:31.128 --> 02:29:37.828 profile ID. And so remaining limitation, this is still tutorial demo auth, not production 02:29:37.828 --> 02:29:43.828 authentication. Real convex auth or clerk can replace demo session issuance later while keeping 02:29:43.828 --> 02:29:50.948 the same role profile access model. And so this should give us some role separation, right? Some 02:29:50.948 --> 02:29:56.028 kind of authentication on the backend. And here, if we jump into Convex, you can see we now have 02:29:56.028 --> 02:30:01.768 users over here, right? These are the users and there's a role. So you can be either both or you 02:30:01.768 --> 02:30:07.208 can be a helper or you can be a customer. And depending on which role you're in, you can do 02:30:07.208 --> 02:30:14.968 various operations. Here we have sessions, we have various services, we also have functions that also 02:30:14.968 --> 02:30:21.748 handle these roles. So you can list demo users, you can start demo session, viewer, list for helper, 02:30:21.748 --> 02:30:29.028 list for customer, etc. And these functions, they are meant to work with specific roles, 02:30:29.168 --> 02:30:34.988 so that authentication is baked in into these functions. Now, when something breaks, the wrong 02:30:34.988 --> 02:30:41.148 move is to immediately ask Codex to rewrite a whole section. The better move is to give it the 02:30:41.148 --> 02:30:48.008 error, ask it to inspect the relevant files, and make it explain the likely cause before changing 02:30:48.008 --> 02:30:54.008 anything. That debugging loop is the same whether the problem is a browser error, a build failure, 02:30:54.288 --> 02:31:01.668 a convex function error, or a UI state that does not make sense. Observe the issue, diagnose it, 02:31:01.668 --> 02:31:09.028 patch it narrowly and verify the fix. And so let's give it a prompt that will deal with this 02:31:09.028 --> 02:31:13.368 sort of issue regarding debugging, polish, verification, stuff. 02:31:13.368 --> 02:31:18.248 stuff like that. We're going to be using this prompt over here. Debug, polish, and verify the 02:31:18.248 --> 02:31:24.348 existing FlexHelp product workflow. Inspect the current app first, then identify the smallest set 02:31:24.348 --> 02:31:31.108 of fixes and polish improvements needed to make the current workflow feel credible. Let's jump 02:31:31.108 --> 02:31:37.968 into plan mode. Right away, it tells us that I see a few concrete polish fixed candidates already, 02:31:37.968 --> 02:31:44.088 and it lists them here. Okay. And so the build passes and both local servers are responding. 02:31:44.368 --> 02:31:50.308 So it's using an in-app browser now for a quick workflow probe. So the plan targets actual UI 02:31:50.308 --> 02:31:56.348 issues rather than guesses. Okay, so let's wait to see what it finds. And this is the plan that 02:31:56.348 --> 02:32:02.768 it came up with. Tighten the existing customer, helper, convex, and demo OAuth workflows without 02:32:02.768 --> 02:32:08.928 adding new product scope. Okay, so it lists a bunch of things. And we want to quickly scan 02:32:08.928 --> 02:32:15.108 assumptions. No new marketplace features will be added, no payments, nothing. Okay, that stays. 02:32:15.108 --> 02:32:20.608 and here are some key changes. You can kind of scan through that. Let's go ahead and submit this. 02:32:20.748 --> 02:32:26.908 Right. So it is done and it has implemented the debug polish pass and it actually fixed a lot of 02:32:26.908 --> 02:32:32.668 interesting things. It fixed some placeholders. It did some testing. It switched to different 02:32:32.668 --> 02:32:38.468 accounts. Actually cleaned up a lot of cool stuff. So if we take a look here, we can see that we can 02:32:38.468 --> 02:32:44.608 book. We can request a book. We can describe the task. We can fill all of this out, send, 02:32:44.608 --> 02:32:50.768 at the preferred date. And now it's showing in that I'm signed in as the customer, right? And 02:32:50.768 --> 02:32:55.748 I can switch a demo user. Now I'm signed in as the helper, and now I'm signed in as both. 02:32:55.988 --> 02:33:01.688 Customer access, choose a customer demo user to create a booking request. So it's coming along 02:33:01.688 --> 02:33:09.088 really, really nicely. And the final build step is deployment. The app is not done until the front 02:33:09.088 --> 02:33:15.388 and is live connected to the intended convex backend and smoke tested through the real product 02:33:15.388 --> 02:33:20.788 workflow. So let's go ahead and grab this prompt and let's go ahead and paste it. So deploy the 02:33:20.788 --> 02:33:27.628 existing FlexHelp app with Vercel and smoke test the connected convex backend. Okay, we're going to 02:33:27.628 --> 02:33:32.228 jump into plan mode so that it can prepare everything, plan everything out. One thing that 02:33:32.228 --> 02:33:36.468 I want to tell it that I didn't tell it, and I'm going to do that right now, is I want to make sure 02:33:36.468 --> 02:33:43.388 it uses the Vercel package. Choose the Vercel plugin. And I'm going to press Command-Enter 02:33:43.388 --> 02:33:49.808 so that it steers the conversation because we want the model to ensure that it catches that, 02:33:49.888 --> 02:33:54.608 right? That we want to use the Vercel plugin. Which convex environment should the deployed 02:33:54.608 --> 02:33:59.468 Vercel app use for the smoke test? We want to use production. And where should the front end 02:33:59.468 --> 02:34:05.028 be deployed? New personal project. Exactly. This is a brand new project. We already have a bunch 02:34:05.028 --> 02:34:09.748 of projects, right? So if we go over here, we have this project. Actually, we should have used the 02:34:09.748 --> 02:34:13.388 existing project. We already have this project, but I think it's going to create a new project. 02:34:13.748 --> 02:34:18.808 Let's see if we can sell it. I'm going to copy that. See if we can use the existing project. 02:34:18.908 --> 02:34:23.828 No need to create a new project. And let me check. So this is actually plan mode. So we're okay. 02:34:23.828 --> 02:34:29.228 Okay. Implement this. And here it's going to create a production. So if we go over here, 02:34:29.408 --> 02:34:33.888 remember we're using this. We also have a production deployment setup. So it's going 02:34:33.888 --> 02:34:38.328 to be using the production deployment. So we should see data and tables and functions and all 02:34:38.328 --> 02:34:43.228 that good stuff as part of this deployment. Production convex is now seated and responding 02:34:43.228 --> 02:34:47.948 with services and demo users. So if we go over here, we have everything now. Look at this. 02:34:48.168 --> 02:34:52.748 Sessions, services, we have the data. All right, so it looks like it has deployed it, 02:34:52.968 --> 02:34:58.068 and now it's doing a couple of smoke tests to make sure that everything works in production, 02:34:58.068 --> 02:35:04.628 because now it's in production and it's also using the production convex deployment, right? 02:35:04.688 --> 02:35:09.488 So we need to test things again because, you know, it's using new environments now. 02:35:09.708 --> 02:35:15.108 All right, and it is done. Deployed Flex Help. This is the URL. This is the Resolve Project 02:35:15.108 --> 02:35:22.108 deployment ID. Everything is live now, okay? And you can access it as well at this URL, okay? So 02:35:22.108 --> 02:35:28.508 we have customer home and I am signed in as one of these demo users, customer or helper, right? 02:35:28.548 --> 02:35:34.088 I can go into helper dashboard and let's say I go and I sign in as a customer and I go into 02:35:34.088 --> 02:35:39.028 customer home, but I can't click here, right? This is helper access, right? Remember the roles, 02:35:39.028 --> 02:35:45.248 right? It's being handled here. And so now as a customer, I want to book professional seasonal 02:35:45.248 --> 02:35:51.508 garden cleanup. I'm going to book this request to book. I'm going to fill all of this out, 10 a.m., 02:35:51.508 --> 02:35:57.188 two hours, it's fixed, address, send booking. Okay, so we've booking requests submitted, 02:35:57.308 --> 02:36:02.528 your request was saved, view my bookings. So we have all of these pending. And so now I'm going 02:36:02.528 --> 02:36:08.188 to log in as Marcus. And Marcus is going to go into helper dashboard. And now he sees the booking. 02:36:08.188 --> 02:36:13.548 And I'm going to say accept are complete. It's completed. And now if I come back as Anders again, 02:36:13.748 --> 02:36:21.428 and I go into customers home, booking request for maybe summary right here, customer booking status. 02:36:21.508 --> 02:36:26.008 Okay, there we go. Completed. And here we see completed. This one is completed. Actually, 02:36:26.188 --> 02:36:30.268 this one from Marcus, it has been completed. And then there are some more requests here. 02:36:30.368 --> 02:36:35.228 So the flow is working. The flow is working perfectly. Of course, there are so many other 02:36:35.228 --> 02:36:41.728 things that we can do. We can use real OAuth. We can change the page. We can update things. 02:36:41.868 --> 02:36:49.168 But right now, the core of the app works perfectly. And just as a little bonus, when you reach this 02:36:49.168 --> 02:36:54.488 stage. There's more things that you can do, but one thing that, you know, right away that you can 02:36:54.488 --> 02:37:01.828 ask Codex to do would be something like suggest top five high impact, low effort features, 02:37:02.108 --> 02:37:07.148 functionalities. And I'm going to switch into plan mode. And we want to see if there's some 02:37:07.148 --> 02:37:13.448 high impact features that we can add that do not require a lot of effort. And here they are, 02:37:13.448 --> 02:37:19.848 top five high impact, low effort next features I'd prioritize. Functional marketplace search, 02:37:20.048 --> 02:37:25.208 booking detail view, customer cancel pending request, et cetera, et cetera. And if you don't 02:37:25.208 --> 02:37:33.088 want to implement these right now, what I'd like to do is save this list as dots to do MD as a 02:37:33.088 --> 02:37:42.068 markdown file and prioritize each item on a scale of one to five, one being urgent. And so that way 02:37:42.068 --> 02:37:47.368 I have a constantly evolving list of things that I can build in the future. 02:37:47.548 --> 02:37:53.248 So I do not need to ask Codex all the time, constantly, you know, to suggest new features. 02:37:53.508 --> 02:37:58.028 And I'm going to say submit, and that's going to go create this docs directory as well. 02:37:58.468 --> 02:38:04.148 And this to do MD, which is the file that I usually keep to store new features. 02:38:04.428 --> 02:38:06.528 And now we can open this file and take a look. 02:38:06.588 --> 02:38:08.828 So this is priority one, two, three, four, five. 02:38:08.828 --> 02:38:15.988 So now we have an app that is live, that is on the internet, that we have built, that works. 02:38:16.128 --> 02:38:19.948 This workflow, this main workflow works as expected. 02:38:20.068 --> 02:38:24.328 But of course, there's so many things that you can do to improve this app. 02:38:24.548 --> 02:38:30.328 And in some of the later videos, I'm going to be showing you some more advanced Codex techniques 02:38:30.328 --> 02:38:35.428 that you can use to make your apps even better and more robust. 02:38:35.428 --> 02:38:40.468 because I've been using Codex for a while now, and I have some advanced tips and tricks that 02:38:40.468 --> 02:38:45.368 I'd like to share you in some of the future videos. And so I really hope that you enjoyed 02:38:45.368 --> 02:38:52.648 this mega Codex tutorial. Now, if you want to go ahead and build this app or modify this app or 02:38:52.648 --> 02:38:58.508 whatnot, I'm going to be leaving all my prompts, every single prompt that I use to build this app 02:38:58.508 --> 02:39:04.328 inside of our amazing Patreon community. And you can check it out and hopefully join. There are 02:39:04.328 --> 02:39:09.908 lots of great people there. And of course, support this channel and support my work. And so 02:39:09.908 --> 02:39:15.008 like this video, leave a comment, and check out our amazing Patreon community.