Transcription
There's one app I use almost every waking hour, and it is also the one subscription I never expected to justify at this level: Codex. I paid for the very highest tier pro plan and justify the cost by having it brainstorm new app ideas, build simple and complex apps, fix bugs, and add new features as the apps evolve. It's like having a junior developer on your team, always open to brainstorming new app or feature ideas, and then building them at a moment's notice. I've been using Codex ever since it came out, and over time, it has become a central part of how I build, test, debug, and think through software. In fact, I've used it to write close to half a million lines of code, if counting just the major app projects, including several that I have released as real products. Not to mention the countless scripts or tiny apps I had it construct.
And so, in this beginner Codex tutorial, I want to share with you my experience when it comes to building powerful and easy-to-use apps with Codex. We'll be covering the following: what Codex is, how to use it without getting lost, where it fits, and the key areas you need to understand to start building real apps with AI. And also, I'm going to be showing you how to build a simple app so that you see the entire flow from the beginning to end.
Now, before we start building, it really helps to understand what Codex is and how to use it properly. So, Codex is OpenAI's coding agent that can read your projects, plan changes, edit files, run commands, test the result, and help you build or debug software from natural language instructions. And so, if you head over to openai.com/codex, you're going to be on this webpage here that tells you a little bit about how it works and shows you some screenshots. So, this is a coding agent that helps you build and ship with AI, powered by ChatGPT, okay? And so you can kind of scroll down, you can see this is the best way to build with agents, built to drive real engineering work, and I use this tool all the time. I use it pretty much every waking moment to build all kinds of apps, do all kinds of things, to brainstorm, etc., etc. So, if there was ever a tool that, you know, I've used so much, I've dedicated so much of my time to, this is the tool right here.
Now, there are two main ways to use Codex. You can either use the command line interface, or you can download this tool for macOS. Now, initially, when I got started with Codex, they didn't really have this macOS tool, so I was using the CLI, the command line interface, tool exclusively. But when they initially released this tool, I was kind of lukewarm to it. I wasn't really sure if I wanted to use it. But over time, I really opened up to it, and now I pretty much use this macOS tool exclusively. And so, once you download this tool and open it up on your computer, you're going to be looking at a screen that looks something like this.
So, a quick overview of what you see and what you can do in this macOS tool here. So, on the left-hand side, you have things like new chat, you can search, you have plugins, you also have some automations. And just below it, you have your projects. So, here I have some of my projects here. And so, it makes it super easy to organize things, right? You can simply click on a project, and you will immediately have your conversations for that project. And so, as you can see on the main content pane here, it's asking me, "What should we work on in Y2?" Now, Y2 is a specific project, okay? So, here's Y2. And so, if I type anything here, it's going to be dealing with those files and that directories, right? So, these projects are nothing more and nothing less than directories on your machine, right? So, that is a way, it's a natural way to organize your repositories, your repos, your projects. And so, if you want to, you can add in your project, and this is something that we're going to be doing a little bit later in the video. And once you create a project or you choose an existing project, you can start prompting to it, right?
Now, before we write any prompts, let's talk a little bit about this main interface here, right? So, right right here. So, this first line here tells us which project that we're going to be working with. So, it's telling me that, "What should we work on in Y2?" Y2 is one of my projects. It's actually a directory right here that has to do with a specific type of projects that I'm working on, having to do with this channel, actually. And so, if I type anything here, that's going to start a new convo having to do with this context here. Now, right here in this main text input here, this is where you're going to be prompting, and we're going to come back to that in just a little bit. Just below that, you have other things, right? So, if you click here, you can add photos and files. And a quick tip, you can simply drag stuff from your screen. So, I pretty much have never used this here, okay? I simply drag things right to this text box here, and it's going to figure out how to use it.
Below it, we have the plan mode. Now, plan mode is one of the best features of Codex, and this is something that I use all the time, and we're going to come back to it once we start talking about planning and building apps. And so, if you click here, that's going to go into plan mode. And a quick tip, and this is something that I use all the time, you can simply click on Shift+Tab, and that's going to select plan mode right here, okay?
So, coming back here, the next setting is speed, right? So, we have here the standard speed, right? This is the default speed with normal credit usage. And we also have the fast speed. So, this is 1 and 1/2 times faster, but the credits are going to be used up two times as fast. So, depending on your plan, depending on how much you're paying for Codex, this can be something that you may be using all the time, or this can be a luxury, right? So, this really depends on your plan, how you're using Codex, and all that.
Now, moving right along, here we have the permissions. So, here we have the default permissions, and we have the full access. Now, I personally use it with full access all the time. And up until now, nothing bad has happened, nothing bad has even been close to happening. And so, I'm pretty confident at this point that I want to use full access, right? When you use full access, you can simply skip all the confirmations, because if you switch this to default, it's going to confirm lots and lots of things. I have found from experience that full access is just a lot faster and a lot more robust, and I haven't really experienced much issues. And so, I definitely urge you to experiment, right? With default permissions, full access, maybe give it a directory that it only has access to, and just try full access. I personally have not had any issues, so I keep using full access pretty much full time.
Moving right along, here we have the model. Now, this is where it gets interesting, right? So, we have here access to all kinds of different models, right? We have the latest one, GPT-4, we have GPT-3.5 Turbo, GPT-3.5, GPT-4 Mini, and on and on and on. And a little bit later in the video, I'm going to talk a little bit about the different models and how you should be using them. But suffice to say, on my plan, I pretty much use GPT-4 all the time. But if you're using a different plan, using some of these other models can be a smart move because they use less tokens, they're, you know, a little bit less sophisticated than some of the newer models, and they're also not as token hungry. And so, that could be an option as well, and I'm going to be covering all of that a little bit later.
Next, we have the reasoning effort, right? So, if you click here, you can see that we have low, medium, high, and extra high. And now, this is another area that's very, very subjective to you. You know, some people say you should be using this, some people say you should be only using this. I have found from my use that high is one of the better ones. Now, obviously, this will depend on what kind of problems you're looking to solve. Now, when you think about reasoning, you should think of it as, you know, different levels that the model is going to reason before it gives you an answer. And so, if you're looking to do something very, very simple, right? Something like, "Hey, you know, download this file or, you know, count the lines in this file." Something very, very simple, then you don't really need high reasoning. You can do something low, and that's going to be fine, right? If you're looking to do something very agentic, right? Something like, you know, "Do this, you know, find this, you know." Something very straightforward where it's just a quick task that the model doesn't really need to reason a lot, then low or medium are going to be, you know, your go-to reasoning modes. I typically use high pretty much like 80% of the time when I'm working on code, okay? Because it's a nice balance of being correct and the time it takes to get there. Because if you start using something like extra high, and a lot of people swear by it, right? A lot of people really swear by extra high, the model is going to take a while before getting to an answer. And so, I urge you to definitely experiment. Start with medium, try out high, and see which balance works well for you.
Here we have the plan mode, which is very, very important, we're going to be covering that. Next, we have a dictation mode, okay? And this is something that I've been experimenting with. It's very, very similar to ChatGPT dictation, right? Where you can just talk to your phone or, you know, just dictate to your desktop app, but I'm not really using it all that much. I have found out that when it comes to coding, software development, and agentic stuff, I like typing things, okay? So, this is another subjective area that you need to kind of experiment with.
Now, here you can click and you can define the narrator in case you want to actually view the code. Now, when I initially started working with this app, I, you know, viewed the changes that it made, but as I went along, I started, you know, looking at the actual files less and less. I would still look if I needed to double-check that it's doing something correctly.
Now, this right here is the toggle file tree. You can click here and that's going to display all the files that exist in this directory here. Remember, it's all about directories. And if you close that, and here we have the side panel. And this is where you can see the progress, you can see the artifacts, and you can see the source files. So, this is useful for getting the overall context of a conversation. So, if you're doing something in a specific So, if you're trying to do specific tasks, right? You're working on a specific area, and you have conversations happening, this is going to be very, very useful because you can see exactly what the model is doing.
Now, the pipeline, that pretty much encapsulates all software development processes, looks something like this, right? We have the product brief, we have the plan mode in Codex. We start to build. After we build, we review, we test, we refine, and then we launch, okay? Another variation of this is that after refinement, you want to come back to build, review, test, maybe refine again, come back to build, and once you come back again to refine, if you're happy where you are, you can just launch, okay? And this is very, very important to internalize from the beginning because LLMs are very, very powerful, but you still need to follow a certain order, right? You need to follow a certain workflow, a certain pipeline. If you do not, you're not going to be getting the biggest benefit of using an LLM. You will still get some output, you will still have some results, but you're not going to be getting the biggest bang for your buck, essentially, right? And so, you want to internalize this because this is going to save you a lot of time, a lot of effort, and even a lot of money in some cases, and will mean the difference between building amazing, robust software that has, you know, that's very, very easy to use compared to some AI slop that nobody wants to use. So, this is very, very important.
Now, the app that we're going to be building in this tutorial is not going to be very complex, but it has enough real product logic to make the Codex workflow meaningful, okay? And this will allow us to eventually graduate to more complex and more feature-rich, production-ready apps. So, in this tutorial, we're going to be building a mobile-style trip day planner, okay? And the user flow is going to be very, very straightforward. So, a user enters a city, they enter a budget, a time, and a travel style, and the app will return a day plan from seeded local data.
Now, before you actually start building, you need to decide your app stack. And this will come down to various options and various choices, and really depends on what kind of app that you want to build. Now, in this tutorial, we're going to be building a mobile-style app. And here is where you have a couple of choices. For instance, you can decide to use something like Flutter, right? Which is what FlutterFlow is based on. So, Flutter is great for App Store apps. It's especially great if you want one codebase and high UI control. Another great framework that you can use is React Native plus Expo. And this is very, very similar to Flutter. It also allows you to build robust App Store apps as well. And so, in this tutorial, we're going to keep it super, super simple. We're just going to be using React. And that is because it's best for fast iteration, browser preview, and visible Codex feedback loops. And so, this will allow us to build an app that we can actually interact with by creating new features, fixing bugs, and seeing the whole process as it happens.
Now, at this point, you may be itching to start building your app by telling Codex something like, "Build me this app." But I'm here to tell you to wait, okay? Because the next step is super, super important. And this is where you're going to be giving Codex a clear product shape instead of a vague request. And this is where I also highly recommend that you use the plan mode. I use the plan mode almost exclusively unless I have a very specific and simple, unambiguous feature that I need implemented. Now, what makes plan mode super powerful is that it gives Codex a chance to ask any clarifying questions if it's not sure about something. And it also forces Codex to stay in the read-only mode, which is great to ensure that it doesn't do something that you don't want it to do.
And so, at this point, we're going to jump into our Codex app and create a new project. And so, I'm going to click here to add a new project. And here I have created a brand new directory where we're going to be storing this project, okay? So, I'm going to click on open right here. And now we have this new project here and all the chats for this project listed below. So, at this point, we don't have any chats at all, but we have here a screen that's asking us, "What should we work on in the demo app?" And right away, I know that anything that I type here is going to be in this context, right? It's going to be dealing with the files, with the directory here. Now, obviously, we don't have any files to begin with, but it is good practice to double-check that, you know, you're looking at the screen and it tells you the name of the app before you input anything. And now we are ready to input our first prompt. And so, I have this prompt ready, right? "I want to build a mobile-style trip day planner app for this beginner Codex tutorial. Before writing code, help me turn the idea into a clear V1 product spec, okay?" And it tells me this. And you want to ensure that you're actually in the plan mode, so you can click here and select plan mode, or you can do Shift+Tab to enable it, which is what I do. And here, once again, we see that we're dealing with this specific demo app context.
Now, let's go ahead and double-check the prompt to ensure that it is correct, right? The app should let the user enter a city, budget, then return a simple day plan from seeded local trip data. Now, at this point, we're just brainstorming, right? It's not going to go out and build an app for me. It may suggest something, it may come back and tell me this is the right way to do it, this is not the right way to do it. And so, what we want to do is we want to send this request and see what happens, okay? So, we're using GPT-4. I have it set to high, which is something that I pretty much use all the time. It's a good kind of default mode. And now, we need to wait and see what it comes up with. Now, if you are in the plan mode like we are here, it might ask you some clarifying questions first. Or if it understands what you're asking for and there's really no confusion, it's going to spit out a plan here, right? So, I can click on expand a plan, and I can essentially read this plan, okay? Now, these plans are fairly specific. And so, you know, depending on what kind of app that you're, you know, kind of the specs, you have a general idea of the kind of app that you want to build, right? You definitely want to scan or read this plan in greater detail because the goal here is not to start building right away. The goal is to ensure that your plan is on point, okay? And so, here's the product brief: build a mobile core user flow, user taps this, required screens, we have the planner screen, we have the plan results, right? Two screens. Must-have version one (V1) features: a seeded local trip data, etc., etc. Form fields, right? And we are being fairly vague right now, and that's on purpose, okay? Because we're going to be refining as we go along. And so, it even tells us what's out of scope: real travel APIs. This is actually cool. We're not going to be using APIs. It's a very, very simple demo, okay? And if you scroll down, you can see recommended implementation plan. You can kind of scroll that.
Now, at this point, we're not going to implement this plan. We're just going to leave it as is because we're going to move to the next step. And so, what I'm going to do here is I'm going to give it another prompt, right? "Using the approved product spec, build the first version." And now, we are being a little bit more specific here, right? Because we're giving it placeholder seeded trip data if needed, right? And this is needed. Create a seeded local trip data for eight to 10 cities with two to three sample plans per city. Each plan should include city, budget, time, travel, etc., etc. And so, that becomes our kind of more refined plan. And after it finishes kind of synthesizing things, we're going to go ahead and actually build the app, okay? So, I'm going to go ahead and run that. And let's see what it comes up with. And it's telling me I'm still in plan mode, so I'll turn this into an implementation-ready build plan rather than changing files yet. So, we're going to expand that and now we're, you know, we're a little bit more specific. You see it even has implementation details: use simple files, and this is something we didn't see before, right? Because we're being a little bit more specific. Use TypeScript size. This is good. I like TypeScript. Create local seed data for eight to 10 cities. Okay, this is important. Quick tip here. What I like to do most of the time is I like to read the summary. And as you start to build more and more complex apps, you're not going to have a summary. You're going to have something else. I believe it was like implementation details or something like that. It gives you bullet points. And another thing I like to do, I always read assumptions. So, even if I skim through the middle part, just by reading the first part and the last piece, it gives me kind of the gist of what it's trying to do because later on you're going to be building complex apps and it's going to give you this long screen and you are, you know, you're pretty sure that it's going to do what you want it to do. And so, what I like to do is I like to scan assumptions and scan the first part. So, with assumptions: as the workspace is intentionally empty, the first build should prioritize the result. Behavior should be simple. So, yeah, this is fairly general, right? Because, you know, later on as you start building more complex apps, you're going to have assumptions that are very, very specific and that way you can just scan through them and you will know exactly if you're on the right track. And many times you will catch certain assumptions that are incorrect where you're going to say, you're going to stop. You're going to just dismiss it by pressing Escape and say, "No, what I meant was this," and it's going to regenerate another plan for you. This happens, you know, all the time, actually.
So, we're going to hit submit and it's going to go ahead and create this sample app for us. All right, so that took 2 minutes and 57 seconds. So, effectively 3 minutes, and it implemented the first visible build. So, it created a new React TypeScript app here, main planner, seeded trip data, mobile-style app shell, and resulting styling, simple global CSS. And we have it all running. So, the dev server, and it even started the dev server, right? So, we can click here and we can open it up. And now we have this app running here side by side in this panel here, right? Because we have the browser as well. And this is our trip day planner. And this is an actual app, right? This is a mobile-style app that we have built, right? So, we have the seeded cities. We're not using any external data or anything like that. No APIs, no databases. And so, you can select, let's say New York, medium, choose a time, let's say half a day, food, and then you can click on "Create a plan." And it's telling us, "No exact match found. Try different budget style. This beginner version only shows exact matches from seeded data." Okay, so that did not find it. Let's try another one. Full day, relax. And once again, we get an error, right? "No exact match found." So, we're not selecting the different options in a way where it will give us the output that we want. And so, at this point, we have the UI, we have our app, but our app is not working, right? Because it's not finding the exact match. It's trying to do it using exact match. And so, what we're going to do is we're going to give it a follow-up prompt, right? I'm going to pass this and I'm going to say, "Add the core feature: when the user fills out a form, show a recommended day plan from the seeded trip data, right? Keep the implementation simple, store the form, all of this. Do not over-engineer the matching logic. The goal is to get the first working result on screen so we can review and improve it in the next step." And another thing that you can do is you can say something like, "Avoid this," right? So, I'm going to copy that and I can simply Ctrl+V, paste it, and when I do that, it's pasted it here. So, I can say something like, "Ensure that the user sees something, a plan, and does not see this error message: 'No exact match found.'" Okay?
Now, here's where you can go straight, right? You can skip plan mode. I like to have my plan mode. I like to, you know, I like to kind of see what it's doing, right? So, I'm going to press Shift+Tab. I'm going to enable plan mode. Now, here it can ask me some clarifying questions if it's not sure, and that there's a trade-off, you know, doing it this way or doing it this way needs to kind of figure things out, or it can go straight to creating a plan. So, let's see what happens. We're going to do this. Now, it's thinking and now it's trying to figure out where this "exact no exact match found" is coming from, okay? And it figured it out. It understood the logic and now it's saying to us, "Update the current React app so every computed form submission shows a recommended seeded day plan instead of the current..." etc., etc. So, we can expand it and you want to read the summary and then you want to read the assumptions. That is what I like to do. You're obviously free to read everything and it's probably a good idea to kind of skim through everything. And so, no new seeded data. The matching should stay intentionally simple and readable for the tutorial. The app should prioritize showing a useful first result over perfect recommendation quality. And that is kind of what we want. We want to show it something, right? Instead of not showing the instead of like instead of having the user frustrated there trying to figure out the right combination.
So, we're going to submit this and let's see what it does. Okay, so that took 40 seconds and it has implemented the core planner result flow, changed all of this with this fallback order: exact match, city style, city plus style, city style, then first seeded plan. The old "no exact match found" user-facing state is gone, okay? And so now we have this. We can refresh it and let's give it a shot. So, let's say we pick Amsterdam, medium, half a day, travel style, and I create a plan. And now we have a plan. Okay, "A compact route through classic Amsterdam views, quiet lanes, and one museum stop." And actually, just looking through Amsterdam reminded me how cool Amsterdam is when I visited it last summer. And let's try London. Oh, let's try New York. Let's try my favorite city, New York. Medium, half a day, let's do, I don't know, culture. Create plan. "Manhattan essentials, a first visit route through skyline views, park time, and central landmarks. Central Park South, Rockefeller Center, High Line." Very cool. Actually, very, very cool plan.
Now, at this point, we have a working app. We have a working mobile-style app. And so, at this point, you can kind of make some tweaks. You can make UI tweaks or you can make some feature tweaks. So, let's say you want to add a new feature, okay? But you're not really sure. So, you can ask Codex to do it. "Recommend top three features to implement now without increasing our scope too much. Three features easy to implement, huge impact." Okay? And I'm going to do plan mode, as I always like to do, because this here specifically is kind of a plan mode thing, right? You typically want to do plan mode for this. But I almost always do plan mode because I like to go, I like to have it go through the paces, right? I don't like to just have it just go out and code. I like to kind of see how it's thinking. Okay, my top three in order: show best match details, add another, try another plan, add quick demo presets. Okay, so what is this one? This is the first one, the top, the top, the top one, top two, you know, the first one, the second, the third. Add small chips. Okay, so let's go ahead and implement this one. "Implement." And I stay in the plan mode, right? In case it wants to ask me something, okay? But, you know, we're working on a fairly simple app. So, it doesn't really need to ask me anything. Now, as I mentioned earlier, as you get into more and more complex apps, it's going to be asking you a lot of things. So, with the apps that I'm building now, all I get is questions, and that's great because I can clarify things before it starts building. Very, very helpful.
So, I'm going to expand this. Assumptions: no seeded data, best match becomes visible. Match quality plus plan attribute chips, not a deeper scoring system. The existing selection explanation remains in place, right? Enhance the existing result card so the user can quickly see why a recommended plan fits their form inputs. Okay, let's go ahead and do this. We're going to submit that. As it's doing it, you can actually see things update, right? Because it's being hot-reloaded, right? It automatically detects that the files are being changed, right? So, it's as you can see, it's exploring files. It has edited these files here, and you can click on the file to see what changes it made if you want, but it immediately picks things up, right? And so, these are the chips, right? It actually, you know, it tells us what happened, right? So, if I change it to, let's say, low budget and I do that again, "Closest match: New York, budget medium." Right? So, this is a closest match, right? If I go back to medium, it's also a closest match, but if I do full and I switch to highlights, now it's "Best match," okay? So, it's actually telling me, it's giving me a little bit more information. So, let's say I go back to Amsterdam and I do "close." It's showing me "Closest match," and that is because it's medium, it's culture, right? Switch to culture, "Strong match." Now, I still have "full day" and I go into "half day," "Best match." That's actually pretty cool. It's a cool feature, right? Because we don't, we're using just seeded data and we don't have the data for all the different combinations, you know, all the different variations of what the user may submit. And so, it can tell us, "This may not be exactly what you asked for, but that is a strong match," right? So, if I do "evening," "Strong match." If I switch this to "food," "Closest match." If I switch this to "low," still "Closest match," even though it's everything is different. And it's, you know, it's good enough. And you can decide if that's what you want, right? "Best available option for Amsterdam from the seeded plans."
Now, at this point, we have a simple, kind of bare-bones app that at least does something. We have a simple UI, we have a kind of a simple logic, we have seeded data. And so, this right here is not the end. This is just the beginning because from here on, you can expand this app. You can make it more interesting. You can make it eventually a professional app that you can launch in the App Store, or you can turn it into a web app and promote it, etc., etc. Now, some of the things that you may want to implement from this point on are going to be things like persistence, authentication, polish, deployment, and see all the different edge cases. There is lots and lots of things that you can do at this point. And a lot of these extra concepts that I talked about, I'm going to be covering in my future multi-hour Codex tutorial that I plan on doing. I've spent lots and lots of time building so many apps in Codex. And so, I want to show you the best way to build a complex app, a truly complex app. And so, if you want to see that kind of tutorial, leave a comment below, like this video. And so, if I get enough likes, I'm going to be making a truly Codex tutorial that's going to show you how to go from a zero to a hero and build an app of your dreams, of your scope, very, very quickly and easily with Codex. And also, don't forget to check out our amazing Patreon community. If you want to get more content, more resources, and support this channel and support my work. And you can see the link to it in the description below the video.