1
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

2
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,

3
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,

4
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

5
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,

6
00:00:35,160 --> 00:00:42,760
design, implement, debug, and ultimately deploy a production-ready app from scratch. By the end,

7
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

8
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

9
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

10
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

11
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

12
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

13
00:01:20,920 --> 00:01:24,980
that kind of gives you a general overview,

14
00:01:25,200 --> 00:01:29,280
general idea of what this app looks like, okay?

15
00:01:29,300 --> 00:01:30,560
And you can kind of scroll down,

16
00:01:30,660 --> 00:01:32,060
you can learn more about it,

17
00:01:32,160 --> 00:01:35,760
or we can jump into my Codex instance here

18
00:01:35,760 --> 00:01:37,140
and I can give you a quick overview.

19
00:01:37,300 --> 00:01:38,600
So on the left-hand side,

20
00:01:39,020 --> 00:01:41,120
we have things like starting a new chat,

21
00:01:41,460 --> 00:01:43,880
search, various plugins, automations.

22
00:01:43,880 --> 00:01:49,320
Just below that, we have our main organization, right?

23
00:01:49,320 --> 00:01:51,840
And this is where you can organize your projects.

24
00:01:52,220 --> 00:01:52,380
Okay.

25
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.

26
00:02:06,420 --> 00:02:10,720
They're actually linked to folders on your disk.

27
00:02:11,000 --> 00:02:11,320
Okay.

28
00:02:11,420 --> 00:02:16,280
And so everything that you see here represents actual folders.

29
00:02:16,280 --> 00:02:19,980
Now, inside of these folders, we have some items here.

30
00:02:20,080 --> 00:02:23,840
Now, these are not files, and they do not represent anything on the disk.

31
00:02:24,220 --> 00:02:26,700
These are actually conversations, right?

32
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?

33
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,

34
00:02:38,100 --> 00:02:42,940
clicking here or pressing Command and telling it what you want to happen.

35
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?

36
00:02:48,300 --> 00:02:52,580
So if we scroll back up, this was my initial prompt here.

37
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

38
00:02:58,420 --> 00:02:59,360
style, et cetera.

39
00:02:59,500 --> 00:03:01,980
And then I have this interaction here, right?

40
00:03:02,020 --> 00:03:02,940
It does something.

41
00:03:03,560 --> 00:03:06,480
I ask it to do something else, et cetera, et cetera.

42
00:03:06,820 --> 00:03:11,700
Now, just below that is where you're going to be entering your prompt, okay?

43
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.

44
00:03:17,620 --> 00:03:19,640
But this is the main text box for the model.

45
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.

46
00:03:27,200 --> 00:03:30,620
And a lot of people are not really using it.

47
00:03:30,800 --> 00:03:34,380
And you need to understand to leverage this whole app experience.

48
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

49
00:03:41,940 --> 00:03:47,780
this specific conversation, right? So we have branch details, we have some artifacts, right?

50
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

51
00:03:54,080 --> 00:03:59,340
conversation, we might have different artifacts, right? And you can think of an artifact as a

52
00:03:59,340 --> 00:04:03,020
side effect of your conversation.

53
00:04:03,440 --> 00:04:06,740
So if you've created the readme file, you're going to see it here.

54
00:04:06,800 --> 00:04:09,320
If you did a web search, you're going to see it here.

55
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

56
00:04:14,680 --> 00:04:15,280
hand pane.

57
00:04:15,520 --> 00:04:17,960
And here you can see all kinds of interesting things.

58
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.

59
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.

60
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.

61
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.

62
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.

63
00:04:53,940 --> 00:04:55,900
First, let's talk about Codex.

64
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,

65
00:05:03,100 --> 00:05:06,640
but it is connected to your actual working environment.

66
00:05:06,980 --> 00:05:13,500
So instead of only answering questions, it can inspect files, edit code, run commands,

67
00:05:14,020 --> 00:05:19,420
use the browser, test the app, and help move a project forward.

68
00:05:19,620 --> 00:05:21,160
The difference matters a lot.

69
00:05:21,160 --> 00:05:28,560
ChatGPT is great when I want an explanation, a rewrite, a brainstorm, or a quick answer.

70
00:05:28,840 --> 00:05:33,220
Codex is what I use when I want work to happen inside a real project.

71
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.

72
00:05:42,240 --> 00:05:47,020
That is why I keep ChatGPT mostly for pure informational questions,

73
00:05:47,020 --> 00:05:54,600
and I keep codecs for work threads so my project context stays focused and clean.

74
00:05:54,880 --> 00:05:56,980
There are two main ways to use codecs.

75
00:05:57,280 --> 00:06:02,300
The first is through the CLI, which is best when you already live in the terminal

76
00:06:02,300 --> 00:06:10,280
and want to run quick repo tasks, scripts, lightweight edits, or developer-style iterations.

77
00:06:10,720 --> 00:06:16,220
The second is the Mac app, which is usually better for visual app building work.

78
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.

79
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.

80
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.

81
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.

82
00:07:08,940 --> 00:07:12,920
The project pane is where you open or switch between projects.

83
00:07:13,540 --> 00:07:17,980
The thread area is where the conversation and task history live.

84
00:07:18,720 --> 00:07:25,080
The file change view shows what Codex wants to edit before those changes are accepted.

85
00:07:25,080 --> 00:07:31,180
The terminal output shows commands, builds, errors, and verification steps.

86
00:07:31,480 --> 00:07:35,620
The browser preview is where you can inspect the running app visually.

87
00:07:36,420 --> 00:07:41,160
Together, these pieces make Codex feel less like a chatbot

88
00:07:41,160 --> 00:07:44,080
and more like a working development environment.

89
00:07:44,720 --> 00:07:46,520
Permission flow is also important.

90
00:07:47,220 --> 00:07:52,080
Codex should never feel like a black box that silently changes everything.

91
00:07:52,080 --> 00:07:57,660
everything. As soon as it finishes running commands, editing files, or taking an action

92
00:07:57,660 --> 00:08:03,760
that matters, you can always inspect what it's doing, approve the right actions, and

93
00:08:03,760 --> 00:08:05,820
keep control over the project.

94
00:08:08,412 --> 00:08:12,412
The next thing to understand is that Codex is not just one fixed experience.

95
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.

96
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,

97
00:08:27,732 --> 00:08:34,932
because most app building tasks benefit from better reasoning. Here's a rough guide to picking

98
00:08:34,932 --> 00:08:42,532
the correct model for your specific task. So for architecture, backend design, multi-step

99
00:08:42,532 --> 00:08:49,592
implementation, difficult debugging, or final review passes, I want a stronger model, such as

100
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,

101
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

102
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,

103
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

104
00:09:22,852 --> 00:09:29,912
choice. But if I'm asking Codex to design the convex schema, think through permissions,

105
00:09:30,532 --> 00:09:37,252
restructure several files, or debug a problem that spans front-end and back-end code,

106
00:09:37,252 --> 00:09:41,352
That is where I want the strongest model available.

107
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.

108
00:09:53,032 --> 00:09:56,512
The next important decision is the reasoning mode.

109
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.

110
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.

111
00:10:13,172 --> 00:10:18,992
Low thinking is useful for quick, obvious tasks where the risk is small.

112
00:10:19,512 --> 00:10:26,292
Medium is good for normal app building work, first pass UI implementation,

113
00:10:27,152 --> 00:10:31,212
straightforward debugging, and routine feature work.

114
00:10:31,212 --> 00:10:34,592
High is what I use when the decision is more expensive.

115
00:10:34,592 --> 00:10:43,092
architecture, convex, data model design, authentication, permissions, hard bugs,

116
00:10:43,772 --> 00:10:50,872
multi-file changes, and the final review. My default for serious app building work

117
00:10:50,872 --> 00:10:58,552
is usually a strong model with high thinking because that gives me the best balance between

118
00:10:58,552 --> 00:11:06,012
speed and quality. But the practical lesson is simple. Match the model and thinking mode

119
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

120
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

121
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

122
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,

123
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

124
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

125
00:11:48,792 --> 00:11:54,872
you always want to be starting new conversations anytime you're working on something new that

126
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

127
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

128
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

129
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,

130
00:12:24,872 --> 00:12:30,932
Fast is one and a half times faster, but it also uses more of your usage.

131
00:12:31,352 --> 00:12:35,572
Okay, so depending on which plan you're at, you may want to stay on standard.

132
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.

133
00:12:40,892 --> 00:12:42,732
Next, we have intelligence, right?

134
00:12:42,812 --> 00:12:44,312
Now, this is very, very important.

135
00:12:44,912 --> 00:12:47,532
By default, I keep this on high.

136
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

137
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?

138
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

139
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

140
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,

141
00:13:19,992 --> 00:13:25,532
think through something longer, right? You know how people say, let me sleep on it,

142
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,

143
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

144
00:13:39,352 --> 00:13:45,452
going to think through all the possibilities. Whereas the first answer might be wrong and

145
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,

146
00:13:50,852 --> 00:13:55,392
right? If you set something too low and you're working through something fairly complex,

147
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,

148
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,

149
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.

150
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

151
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,

152
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

153
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.

154
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

155
00:14:46,172 --> 00:14:52,232
with it, you'll be able to better judge which thinking mode to select.

156
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,

157
00:14:59,652 --> 00:15:03,252
because this is one of the first practical questions people have with Codex.

158
00:15:03,252 --> 00:15:07,552
For most people learning codex, the important question is not what is the most expensive

159
00:15:07,552 --> 00:15:08,552
plan.

160
00:15:08,552 --> 00:15:12,252
The question is what do I actually need for the kind of work I'm doing.

161
00:15:12,252 --> 00:15:16,692
If you're learning, testing prompts, and building smaller projects, you can usually

162
00:15:16,692 --> 00:15:21,172
start with the normal ChatGPT plan access available to you.

163
00:15:21,172 --> 00:15:26,492
If you're doing heavier app builds, longer agent runs, team workflows, or professional

164
00:15:26,492 --> 00:15:32,412
coding work, then plan limits, credits, and business options start to matter more.

165
00:15:32,412 --> 00:15:36,352
Now, here I am on OpenAI's Codex pricing page.

166
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?

167
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.

168
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.

169
00:15:55,412 --> 00:16:00,052
We have the plus plan, which is fairly popular, $20 a month.

170
00:16:00,052 --> 00:16:05,592
And here you can finally start to actually do something meaningful, right?

171
00:16:05,712 --> 00:16:07,052
Something like, you know, building...

172
00:16:07,412 --> 00:16:09,492
Something like, you know, building a part of an app or building some scripts.

173
00:16:09,752 --> 00:16:14,612
And they say this can power a few focused coding sessions each week.

174
00:16:14,812 --> 00:16:16,572
Next, we have the Pro plan, right?

175
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.

176
00:16:23,112 --> 00:16:24,872
And this is $100 a month.

177
00:16:24,932 --> 00:16:28,172
I'm actually using the ProPlan 20X.

178
00:16:28,432 --> 00:16:30,592
Okay, so I'm paying 200 bucks a month.

179
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.

180
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

181
00:16:43,552 --> 00:16:46,432
of tasks and still not reach limits.

182
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?

183
00:16:54,292 --> 00:16:56,372
But I never really get to the limit.

184
00:16:56,452 --> 00:16:59,552
You need to decide which plan is right for you.

185
00:16:59,632 --> 00:17:03,372
Now, from what I understand, Plus Plan is very, very popular.

186
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.

187
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.

188
00:17:16,332 --> 00:17:19,492
And so the next logical step is to try out the plus plan.

189
00:17:19,572 --> 00:17:21,772
The plus plan is where a lot of people start.

190
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.

191
00:17:27,872 --> 00:17:31,392
How much can this plan actually cover the amount of work you're doing?

192
00:17:31,412 --> 00:17:36,272
Because the fact of the matter is there are people that work on very heavy projects.

193
00:17:36,592 --> 00:17:39,312
And, you know, they work on big repos, right?

194
00:17:39,372 --> 00:17:40,752
Lots and lots of code base.

195
00:17:41,032 --> 00:17:43,632
They run out of their plan very, very quickly.

196
00:17:43,632 --> 00:17:48,292
But if you're working on the smaller projects, you're not using the fast mode.

197
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

198
00:17:52,312 --> 00:17:55,352
because I'm using the fast mode from time to time.

199
00:17:55,352 --> 00:17:57,852
And that, you know, increases the usage as well.

200
00:17:57,952 --> 00:18:01,852
So if you're on standard and you're using maybe medium often, right?

201
00:18:01,892 --> 00:18:06,332
You're not really using high that much and you're almost never using extra high.

202
00:18:06,552 --> 00:18:09,792
You can get a lot of mileage out of this plus plan.

203
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,

204
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

205
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,

206
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,

207
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

208
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,

209
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

210
00:18:50,412 --> 00:18:57,012
tasks, go lightweight coding tasks, plus a few focused coding sessions each week. Okay. And this

211
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

212
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.

213
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

214
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

215
00:19:19,492 --> 00:19:25,192
that the friction matters. Okay, when heavier or business plans make sense, what to verify live

216
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

217
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,

218
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

219
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

220
00:19:49,172 --> 00:19:54,152
talk about some of the things Codex does that can greatly increase your productivity. These are

221
00:19:54,152 --> 00:20:02,292
features I use all the time across different projects. Skills, plugins, automations, and MCP,

222
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

223
00:20:09,872 --> 00:20:19,072
to do a workflow, plugins package capabilities, automations let work happen later, and MCP tools

224
00:20:19,072 --> 00:20:26,152
and connectors give Codex controlled access to outside systems. Once those pieces make sense,

225
00:20:26,152 --> 00:20:31,152
Codex feels less like a code editor and more like a project agent.

226
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.

227
00:20:37,152 --> 00:20:42,152
Skills are reusable instructions for how Codex should do a workflow.

228
00:20:42,152 --> 00:20:45,152
They're not external tools by themselves.

229
00:20:45,152 --> 00:20:52,152
They're more like local playbooks that tell Codex the style, process, output format,

230
00:20:52,152 --> 00:20:56,912
format and validation steps for a specific kind of work.

231
00:20:56,912 --> 00:21:04,492
For example, this course uses skills for explainers, notion editing, video timelines, and other

232
00:21:04,492 --> 00:21:07,212
repeatable production tasks.

233
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

234
00:21:13,192 --> 00:21:18,632
knows the house style, the workflow, and the mistakes to avoid.

235
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

236
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

237
00:21:30,712 --> 00:21:38,072
in the right format, following the right process, and producing something consistent with the rest

238
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

239
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.

240
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?

241
00:21:54,732 --> 00:21:56,072
I can do many, many things.

242
00:21:56,712 --> 00:22:00,072
And as you can see for skills, I have lots and lots of skills.

243
00:22:00,192 --> 00:22:02,352
I have tons and tons of skills over there.

244
00:22:02,592 --> 00:22:07,632
And skills allow me to package a repeatable process.

245
00:22:08,172 --> 00:22:11,072
You can think of it as a function that does something.

246
00:22:11,152 --> 00:22:13,972
It gets some input and it produces an output.

247
00:22:13,972 --> 00:22:18,232
And the goal is to produce consistent output as you've done before.

248
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?

249
00:22:23,132 --> 00:22:25,972
And I asked the model to do something for me.

250
00:22:25,972 --> 00:22:28,772
So here I have, I want to build a very simple web app

251
00:22:28,772 --> 00:22:31,972
that arranges items as a Trello Kanban board style.

252
00:22:31,972 --> 00:22:33,752
Okay. And it comes up with this.

253
00:22:33,752 --> 00:22:36,692
Now, right here, I can package that as a skill.

254
00:22:36,692 --> 00:22:39,052
Now, what do I want to package as a skill?

255
00:22:39,052 --> 00:22:42,532
Well, I want to package, for instance, maybe creating the architecture.

256
00:22:42,892 --> 00:22:48,032
So I can say something like package the architecture step

257
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

258
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

259
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

260
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

261
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

262
00:23:22,352 --> 00:23:28,752
should the sample arch stack package this as a general architecture planning skill or specifically

263
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

264
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

265
00:23:41,152 --> 00:23:48,692
skill named samplearchstack under wherever it's storing those skills, the skill will guide codecs

266
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

267
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

268
00:23:59,892 --> 00:24:07,112
and then agents forward slash openai.yaml. Validation passed, et cetera, et cetera. And now

269
00:24:07,112 --> 00:24:07,412
would I

270
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

271
00:24:13,172 --> 00:24:20,232
project management app. And it should use this skill to create an architecture stack

272
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,

273
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

274
00:24:29,552 --> 00:24:34,772
came back with a plan. Brand new local only project management app architecture, right?

275
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

276
00:24:39,672 --> 00:24:46,752
this architecture, right? App shape, data state model, component architecture, test plan, et cetera,

277
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

278
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

279
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.

280
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

281
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,

282
00:25:15,892 --> 00:25:22,372
I also want to explain a few terms that can sound similar at first, plugins, automations,

283
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

284
00:25:29,532 --> 00:25:37,332
package capabilities or workflows that make Codex better at a specific kind of work. For example,

285
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

286
00:25:44,872 --> 00:25:51,712
deploys on project settings, a Hyperframes plugin can help create explainers, and browser

287
00:25:51,712 --> 00:25:57,332
or document tools can help Codex inspect apps or work with files.

288
00:25:58,012 --> 00:26:00,792
The simple way to think about plugins is this.

289
00:26:01,272 --> 00:26:06,712
They give Codex a more specialized tool set for a specific job.

290
00:26:07,512 --> 00:26:13,832
Codex still needs the right context and the right instruction, but the plugin gives it

291
00:26:13,832 --> 00:26:21,812
a cleaner way to operate inside that workflow. Automations are different. A plugin gives Codex

292
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

293
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

294
00:26:38,792 --> 00:26:46,892
later and continue the work. This is useful because not every task needs to happen immediately.

295
00:26:47,312 --> 00:26:54,232
Sometimes you may want Codex to check something again tomorrow, remind you to review an outline,

296
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

297
00:27:02,092 --> 00:27:09,472
continue. Automations turn Codex from a one-time assistant into something that can help manage

298
00:27:09,472 --> 00:27:16,332
longer running work. The important distinction is simple. Plugins are about what Codex can do,

299
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,

300
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,

301
00:27:27,552 --> 00:27:30,812
you can see all the plugins that you have here, okay?

302
00:27:30,972 --> 00:27:34,212
And so it tells you that make Codex work your way.

303
00:27:34,472 --> 00:27:35,612
And if you scroll down,

304
00:27:35,692 --> 00:27:37,572
you can see all the different plugins, right?

305
00:27:37,592 --> 00:27:38,812
So you can click on the plugin

306
00:27:38,812 --> 00:27:40,932
and you can learn more about it, right?

307
00:27:40,972 --> 00:27:42,532
So for instance, this spreadsheets

308
00:27:42,532 --> 00:27:46,132
allows you to create and edit spreadsheet files, right?

309
00:27:46,492 --> 00:27:49,072
You can use this plugin to create a spreadsheet

310
00:27:49,072 --> 00:27:52,092
to analyze this company's financial, et cetera, et cetera,

311
00:27:52,212 --> 00:27:52,472
right?

312
00:27:53,012 --> 00:27:56,252
Create, edit, inspect, render, verify, and export

313
00:27:56,252 --> 00:28:03,392
Excel, SX, CSV, and TSV spreadsheets locally. Use spreadsheets when the durable output or target is

314
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

315
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

316
00:28:19,012 --> 00:28:24,572
to external systems, right? It's kind of this higher level structure, okay? Whereas the skill

317
00:28:24,572 --> 00:28:27,652
is a very, very specific thing.

318
00:28:28,072 --> 00:28:29,792
It's a specific piece of instruction,

319
00:28:29,932 --> 00:28:31,492
essentially a specific prompt.

320
00:28:31,712 --> 00:28:35,652
A plugin is this umbrella that contains a skill, right?

321
00:28:35,692 --> 00:28:36,612
So you can have that.

322
00:28:36,692 --> 00:28:39,412
One plugin that I use all the time is Notion.

323
00:28:39,512 --> 00:28:40,812
So if we click over here,

324
00:28:40,912 --> 00:28:43,212
you can see that this actually includes

325
00:28:43,212 --> 00:28:44,992
a lot more interesting things, right?

326
00:28:45,612 --> 00:28:48,732
Notion workflows for specs, research, meetings,

327
00:28:49,272 --> 00:28:50,992
and knowledge capture, right?

328
00:28:50,992 --> 00:28:52,812
So you can specify this,

329
00:28:53,212 --> 00:28:54,512
and then you can give it a prompt.

330
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.

331
00:29:00,012 --> 00:29:00,932
These are skills.

332
00:29:01,172 --> 00:29:02,152
This is an app.

333
00:29:02,632 --> 00:29:06,632
Okay, so this allows it to connect to an external system, right?

334
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.

335
00:29:12,252 --> 00:29:14,592
And this right here, these are skills, right?

336
00:29:14,632 --> 00:29:18,432
I can open that, and that's going to open this skill right here, right?

337
00:29:18,532 --> 00:29:21,492
This is how the skill is actually stored.

338
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.

339
00:29:26,632 --> 00:29:29,212
Now, this is a plugin that I use all the time, right?

340
00:29:29,312 --> 00:29:37,072
I use Notion for my planning, for, you know, writing stuff, scheduling, stuff like that.

341
00:29:37,112 --> 00:29:40,372
It's the brain of my workflow, essentially.

342
00:29:40,712 --> 00:29:43,872
And then I installed this pre-built Notion plugin.

343
00:29:44,612 --> 00:29:51,392
And the first time I ran it, it authenticated against my Notion workspace, right?

344
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

345
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

346
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

347
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.

348
00:30:19,312 --> 00:30:23,092
Another really cool one is, for instance, Google Calendar is another one.

349
00:30:23,092 --> 00:30:27,592
Instead of connecting to Notion, or in addition to connecting to Notion,

350
00:30:27,892 --> 00:30:29,752
you can also connect to Google Calendar.

351
00:30:29,752 --> 00:30:31,732
I personally do not use Google Calendar.

352
00:30:31,732 --> 00:30:34,852
I use Notion, so I do not have this skill set up.

353
00:30:35,232 --> 00:30:39,332
Another really useful skill that you're definitely going to be using

354
00:30:39,332 --> 00:30:41,432
if you're building apps is Vercel.

355
00:30:41,432 --> 00:30:47,412
Vercel or maybe something like Netlify for deploying your apps.

356
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

357
00:30:55,172 --> 00:31:00,692
how to deploy, how to check deployment, how to do everything without me needing to actually

358
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

359
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

360
00:31:13,012 --> 00:31:19,412
can say you know vercel ordered this repo for vercel deployment risk or vercel which vercel

361
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

362
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

363
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

364
00:31:38,292 --> 00:31:45,412
skills are not just for deploying, because we also have payments, we have best practices,

365
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,

366
00:31:53,412 --> 00:31:58,612
to different features of our cell. We're not just talking about deploying your app,

367
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

368
00:32:04,292 --> 00:32:07,412
not need all of these other skills, but why not?

369
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

370
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

371
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.

372
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

373
00:32:31,892 --> 00:32:38,592
system and letting Codex manage it for you. Now, automations work very, very differently.

374
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

375
00:32:44,972 --> 00:32:47,252
by setting up scheduled chats.

376
00:32:47,552 --> 00:32:49,052
Okay, and you can learn more here.

377
00:32:49,252 --> 00:32:51,112
Now, if you click on any of these automations,

378
00:32:51,232 --> 00:32:54,052
you can see exactly how they're going to be working.

379
00:32:54,152 --> 00:32:55,352
So if I click on something like

380
00:32:55,352 --> 00:32:58,972
summarize yesterday's Git activity for standup,

381
00:32:59,452 --> 00:33:02,272
you can see that it wants to create an automation for me.

382
00:33:02,392 --> 00:33:04,912
Okay, and what exactly is it trying to do?

383
00:33:04,912 --> 00:33:08,532
Well, it's essentially trying to create a conversation

384
00:33:08,532 --> 00:33:10,812
that will be repeatable.

385
00:33:11,092 --> 00:33:12,912
Okay, so it creates this automation.

386
00:33:13,092 --> 00:33:14,332
This is the name of the automation.

387
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

388
00:33:21,092 --> 00:33:26,172
Git activity for standup, grounding rules, et cetera, et cetera. We can select a work tree.

389
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

390
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.

391
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,

392
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,

393
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

394
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

395
00:34:03,732 --> 00:34:09,552
that will run every weekday at 9 a.m. running this prompt.

396
00:34:09,692 --> 00:34:11,552
And remember, this is a special prompt.

397
00:34:11,732 --> 00:34:14,352
Here, you're asking it to consult Git activity.

398
00:34:14,812 --> 00:34:21,652
And so the idea is you may have Git connected via a plugin or something else,

399
00:34:22,072 --> 00:34:24,752
and it's going to connect to your Git environment

400
00:34:24,752 --> 00:34:26,972
and then figure something out for you.

401
00:34:26,992 --> 00:34:30,052
And that's going to run every weekday at 9 a.m., right?

402
00:34:30,052 --> 00:34:38,232
So instead of you needing to jump into Codex first thing weekday morning and execute this

403
00:34:38,232 --> 00:34:42,112
prompt manually, you can create an automation to do just that.

404
00:34:42,192 --> 00:34:44,512
If you scroll down, you can see some other automations here.

405
00:34:44,732 --> 00:34:47,852
You have incidents, you have code quality, right?

406
00:34:47,932 --> 00:34:52,212
Maybe you want to run a code quality check every 24 hours.

407
00:34:52,352 --> 00:34:55,692
Well, you can click here daily at 9 a.m., right?

408
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.

409
00:35:04,672 --> 00:35:12,892
That's another very, very useful automation. Repo maintenance. You have here growth and

410
00:35:12,892 --> 00:35:20,332
exploration. Click here. From recent PRs and reviews suggest next skills to deepen. This is

411
00:35:20,332 --> 00:35:25,852
great, right? So automations, they could be used for pretty much anything, right? And they are,

412
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

413
00:35:29,512 --> 00:35:35,332
development or project management or anything like that. You can be a writer, right? You want

414
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

415
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

416
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

417
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

418
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

419
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

420
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

421
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

422
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

423
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

424
00:36:38,632 --> 00:36:40,732
that do all kinds of interesting things.

425
00:36:40,832 --> 00:36:44,572
For instance, I have here a Stitch MCP server configured.

426
00:36:45,012 --> 00:36:47,472
I have here a Superbase MCP server.

427
00:36:48,032 --> 00:36:51,272
I also have, you know, Flutter Flow Designer, Flowbase,

428
00:36:51,372 --> 00:36:54,612
a bunch of apps that support MCP.

429
00:36:55,012 --> 00:36:56,752
And when you connect to them,

430
00:36:56,992 --> 00:36:59,732
Codex is acting like an MCP client.

431
00:36:59,732 --> 00:37:03,092
So you have that same client-server paradigm.

432
00:37:03,452 --> 00:37:05,672
Now, why would you want to use an MCP server

433
00:37:05,672 --> 00:37:08,692
to connect to something like Superbase or something else?

434
00:37:09,092 --> 00:37:11,052
Well, the reason is very simple.

435
00:37:11,612 --> 00:37:15,172
You want Codex to do all the administration,

436
00:37:15,432 --> 00:37:17,152
all the work for you, right?

437
00:37:17,232 --> 00:37:20,612
So if you're building an app using something like Superbase,

438
00:37:20,672 --> 00:37:23,552
and we're gonna touch upon that a little bit later

439
00:37:23,552 --> 00:37:27,412
in the video, you can set up Superbase yourself.

440
00:37:27,572 --> 00:37:28,752
You can configure all of that.

441
00:37:28,812 --> 00:37:31,312
That takes time, but it's very, very doable.

442
00:37:31,312 --> 00:37:38,152
or you can simply configure a Superbase MCP server in your Codex instance.

443
00:37:38,772 --> 00:37:47,032
And that will allow Codex to use that MCP server to essentially manage this remote server,

444
00:37:47,312 --> 00:37:49,732
this tool, this app for you.

445
00:37:50,152 --> 00:37:52,832
And as you're going to see a little bit later in this tutorial,

446
00:37:53,072 --> 00:37:57,512
this is very, very helpful to us because it saves a lot of time

447
00:37:57,672 --> 00:38:01,172
and it enables things that we couldn't really do before.

448
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

449
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

450
00:38:15,872 --> 00:38:21,452
it can connect to other remote systems and essentially consult that data with the data we

451
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.

452
00:38:28,192 --> 00:38:30,752
And this is extremely helpful to us, okay?

453
00:38:31,192 --> 00:38:33,952
And so there's a couple of ways that you can add a server.

454
00:38:34,092 --> 00:38:36,592
You can click here and you can fill all of this manually.

455
00:38:37,152 --> 00:38:42,632
Or you can simply tell Codex, set up and activate a Superbase MCP server.

456
00:38:42,692 --> 00:38:44,212
And it's going to figure out how to do that.

457
00:38:44,252 --> 00:38:45,272
It's going to search for it.

458
00:38:45,312 --> 00:38:46,612
It's going to figure out the specs.

459
00:38:47,072 --> 00:38:48,572
And it's going to set it up for you.

460
00:38:48,592 --> 00:38:50,472
And the same thing for all of these other ones.

461
00:38:50,732 --> 00:38:54,892
Now, after setting up the MCP server, you can simply tell Codex to use it.

462
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.

463
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.

464
00:39:14,555 --> 00:39:20,335
server. Now that we have laid the foundation and before we start building the real app,

465
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

466
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.

467
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

468
00:39:41,375 --> 00:39:48,355
difference between using Codex as a random code generator and using Codex as a controlled build

469
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

470
00:39:55,915 --> 00:40:02,875
problem without giving the agent a clean process. That can work for small tasks,

471
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

472
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

473
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.

474
00:40:25,195 --> 00:40:31,115
The better the prompt is, the easier it is for Codex to understand the current state,

475
00:40:31,115 --> 00:40:37,035
choose the right amount of work, and verify the result. The basic structure is simple.

476
00:40:37,035 --> 00:40:45,435
Explain the goal, give the relevant context, define what should change, define what should not change,

477
00:40:45,435 --> 00:40:51,115
and tell Codex how to verify the work. If the task is risky or unclear,

478
00:40:51,115 --> 00:40:58,155
ask Codex to inspect first and make a plan before editing. For instance, instead of saying

479
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

480
00:41:05,995 --> 00:41:13,035
structure, propose the smallest first version, list the files you expect to touch, and explain

481
00:41:13,035 --> 00:41:20,715
how you will verify. That gives Codex a much cleaner job. For implementation prompts, I want

482
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

483
00:41:28,315 --> 00:41:35,435
force the wrong solution. I usually describe the outcome I want, the constraints I care about,

484
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

485
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

486
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

487
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

488
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

489
00:42:11,535 --> 00:42:18,055
by asking follow-up questions. This is especially useful when the request is under specified.

490
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.

491
00:42:24,495 --> 00:42:26,295
What fields does the form need?

492
00:42:26,755 --> 00:42:29,095
What status should the booking start with?

493
00:42:29,515 --> 00:42:32,195
Where should the booking appear for the helper?

494
00:42:32,795 --> 00:42:35,295
What should happen after submission?

495
00:42:35,655 --> 00:42:42,375
Plan mode gives Codex a chance to surface those questions before it edits the app.

496
00:42:42,495 --> 00:42:45,195
I also use plan mode as a quality filter.

497
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.

498
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.

499
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,

500
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.

501
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.

502
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.

503
00:43:29,775 --> 00:43:34,295
Then it should plan the work in a way that is small enough to review,

504
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

505
00:43:41,255 --> 00:43:42,615
and write code.

506
00:43:42,615 --> 00:43:47,975
Once the code is written, it should verify the code with the browser, terminal, using

507
00:43:47,975 --> 00:43:50,255
tests or the build output.

508
00:43:50,255 --> 00:43:56,595
And finally, it should report what changed and what still needs attention.

509
00:43:56,595 --> 00:43:58,635
Verification is the part I want to emphasize.

510
00:43:58,635 --> 00:44:03,435
A task is not finished just because Codex wrote code.

511
00:44:03,435 --> 00:44:06,255
For UI work, I want to see the browser.

512
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.

513
00:44:12,595 --> 00:44:18,315
For deployment work, I want the live URL and a real smoke test.

514
00:44:18,315 --> 00:44:23,775
That habit keeps the workflow grounded in evidence instead of trusting that the code

515
00:44:23,775 --> 00:44:25,675
is probably fine.

516
00:44:25,675 --> 00:44:30,915
Additionally, you always want to break big tasks into smaller ones.

517
00:44:30,915 --> 00:44:36,155
Instead of asking Codex to build the whole marketplace as one prompt, you want to ask

518
00:44:36,155 --> 00:44:43,575
it to plan the app, build the first UI shell, wire one initial database-backed version,

519
00:44:43,575 --> 00:44:48,155
add the booking flow, add the helper dashboard, and so on.

520
00:44:48,155 --> 00:44:53,675
Each step has a clear target and a clear way to check whether it worked.

521
00:44:53,675 --> 00:44:58,915
A good Codex task should usually fit into one reviewable outcome.

522
00:44:58,915 --> 00:45:02,975
Create the first static marketplace homepage is reviewable.

523
00:45:02,975 --> 00:45:07,975
Wire service listings from Convex is reviewable.

524
00:45:07,975 --> 00:45:13,295
Add booking creation and verify the booking row appears is reviewable.

525
00:45:13,295 --> 00:45:19,475
Build the whole app is not reviewable because there are too many decisions happening at

526
00:45:19,475 --> 00:45:20,475
once.

527
00:45:20,475 --> 00:45:23,775
So the workflow is not just a technical process.

528
00:45:23,775 --> 00:45:26,995
It is also a way to stay in control.

529
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

530
00:45:33,435 --> 00:45:40,215
understand the change, approve the direction, and catch problems before they spread.

531
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

532
00:45:45,355 --> 00:45:46,855
here you have plan mode.

533
00:45:46,855 --> 00:45:49,415
Or you can click here and toggle this.

534
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.

535
00:45:54,015 --> 00:45:57,675
And then whenever I'm in plan mode, I can start brainstorming.

536
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

537
00:46:03,315 --> 00:46:04,315
mode.

538
00:46:04,315 --> 00:46:09,255
And it also gives Codex to come back to you with follow-up, clarifying questions.

539
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

540
00:46:15,615 --> 00:46:18,835
exactly what it's doing.

541
00:46:18,835 --> 00:46:23,495
The last thing that we want is for Codex to assume something.

542
00:46:23,495 --> 00:46:25,495
We never wanted to assume anything.

543
00:46:25,495 --> 00:46:28,915
We always want to make sure that we are on the same page.

544
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.

545
00:46:33,655 --> 00:46:37,935
I want to build some kind of an intricate architecture.

546
00:46:37,935 --> 00:46:41,615
And I want to make sure that we built out an architecture.

547
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

548
00:46:47,155 --> 00:46:49,895
sure that Codex is on the same page.

549
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.

550
00:47:02,595 --> 00:47:05,435
Ensure it is fast and robust.

551
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.

552
00:47:13,275 --> 00:47:14,555
I don't even know what I want.

553
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,

554
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.

555
00:47:24,815 --> 00:47:31,515
And so as expected, Codex came back with a question, which cross-platform strategy should

556
00:47:31,515 --> 00:47:37,275
the architecture optimize for? And there are two questions, okay? Do we want shared core native

557
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

558
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

559
00:47:50,395 --> 00:47:57,035
wrappers, right? Because I asked for a cross-platform product, but there's many ways of

560
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,

561
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

562
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.

563
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

564
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

565
00:48:28,375 --> 00:48:34,255
cloud only simpler shared back and with live updates but weaker offline behavior now here

566
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

567
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,

568
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

569
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.

570
00:48:57,915 --> 00:49:05,275
I was asking two choices. How should data work? My recommendation, shared code and native shells

571
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

572
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

573
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

574
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

575
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

576
00:49:33,595 --> 00:49:37,075
because I understood what it was asking me.

577
00:49:37,175 --> 00:49:37,755
Got it.

578
00:49:37,815 --> 00:49:38,955
Your choices are,

579
00:49:39,075 --> 00:49:41,035
that means the architecture should prioritize

580
00:49:41,035 --> 00:49:43,435
a shared TypeScript app,

581
00:49:43,555 --> 00:49:45,795
a brain used by this, this, this, this.

582
00:49:45,935 --> 00:49:46,475
And that's good.

583
00:49:46,535 --> 00:49:48,255
And now I can exit the plan mode

584
00:49:48,255 --> 00:49:49,955
and I can say, go ahead and do it.

585
00:49:50,115 --> 00:49:51,555
Go and implement this.

586
00:49:51,755 --> 00:49:53,735
Something like this or something more specific.

587
00:49:53,955 --> 00:49:56,975
And so plan mode is something that I use all the time.

588
00:49:57,215 --> 00:50:00,055
And you should definitely make it an integral part

589
00:50:00,055 --> 00:50:02,375
of your workflow as well.

590
00:50:03,595 --> 00:50:08,715
Now I want to talk to you about some advanced Codex workflow techniques.

591
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

592
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

593
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

594
00:50:25,175 --> 00:50:30,395
has been compacted, or when I want to move from planning into implementation with a cleaner

595
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,

596
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,

597
00:50:43,775 --> 00:50:49,675
the next codex thread can pick up the work without rereading the entire conversation or repeating

598
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

599
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

600
00:51:03,135 --> 00:51:10,755
answers, the convo starts to degrade. Now, Codex tells you that it automatically compacts its

601
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

602
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

603
00:51:24,395 --> 00:51:30,455
questions and it keeps answering, quality of the responses will degrade. And moreover, you know,

604
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

605
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

606
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

607
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

608
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

609
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.

610
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

611
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

612
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

613
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

614
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

615
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

616
00:52:36,855 --> 00:52:41,975
conversation usually gives you a different solution. That solution might actually work.

617
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.

618
00:52:49,275 --> 00:52:53,435
One of the simplest ways would be by typing something like this.

619
00:52:53,515 --> 00:52:59,835
Okay, this is a very, very simple prompt that still delivers a fairly high quality handoff.

620
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.

621
00:53:06,775 --> 00:53:11,795
Okay, so let's go ahead and send this and see what answer we get.

622
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

623
00:53:17,835 --> 00:53:22,755
app. So it's essentially summarizing everything that has happened in the convo, right? This is

624
00:53:22,755 --> 00:53:27,875
the context. This is the product direction. This is the architecture preference. Please produce a

625
00:53:27,875 --> 00:53:33,315
detailed architecture plan covering all this important, right? Also some constraints. And so

626
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

627
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,

628
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

629
00:53:49,375 --> 00:53:55,475
to create a conversation and the model can simply continue where the other conversation ended. That

630
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

631
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

632
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

633
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

634
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.

635
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

636
00:54:33,175 --> 00:54:38,395
handoff right here. Now, this handoff would definitely work, but this handoff would work

637
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,

638
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

639
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.

640
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

641
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

642
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

643
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

644
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

645
00:55:25,204 --> 00:55:31,124
know why they changed, whether each change belongs to the task, and whether anything looks unrelated

646
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

647
00:55:38,104 --> 00:55:45,004
creating edits without recording what the edit is all about. And in software development, you want

648
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

649
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

650
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

651
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

652
00:56:13,504 --> 00:56:18,624
for the change. Now, in this convo, we have another problem. The current working directory

653
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

654
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

655
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.

656
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

657
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

658
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

659
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

660
00:57:03,004 --> 00:57:09,484
repo in this directory and made an initial commit, initial architecture plan here. Okay. The workspace

661
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

662
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

663
00:57:20,044 --> 00:57:25,404
each additional change will be automatically tracked. So for instance, I can say something like

664
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

665
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

666
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

667
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

668
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

669
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,

670
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,

671
00:58:11,964 --> 00:58:17,784
code generated files that can always be regenerated. But for your actual code, you always

672
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,

673
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?

674
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

675
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

676
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

677
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

678
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

679
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.

680
00:59:06,104 --> 00:59:08,664
Okay, it has been modified and uncommitted, right?

681
00:59:09,124 --> 00:59:11,544
You see this M, which means this has been modified.

682
00:59:11,724 --> 00:59:15,024
So we're going to do commit index.html.

683
00:59:15,304 --> 00:59:18,764
And it will also generate a default message.

684
00:59:18,964 --> 00:59:20,164
Here it has committed it.

685
00:59:20,324 --> 00:59:22,604
We can click here and we can select review.

686
00:59:22,964 --> 00:59:26,584
And you can select the type of change you want to see.

687
00:59:26,664 --> 00:59:30,524
You can see on stage, stage, branch, or last turn.

688
00:59:30,764 --> 00:59:34,504
And when you click on last turn, you can see what was changed.

689
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,

690
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.

691
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

692
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

693
00:59:58,004 --> 01:00:03,924
project, anything beyond something super simple, you want to create a repo, and you want to

694
01:00:03,924 --> 01:00:12,724
implement source control into your workflow. One advanced trick that becomes more useful

695
01:00:12,724 --> 01:00:19,064
as projects get bigger is working with Git worktrees. A worktree is a separate working copy

696
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

697
01:00:25,064 --> 01:00:31,904
version of the app stable while trying a risky feature, UI direction, or refactor somewhere else.

698
01:00:31,904 --> 01:00:34,104
This matters a lot with agentic coding.

699
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

700
01:00:39,684 --> 01:00:45,024
while another codex thread keeps building, a worktree gives you that separation.

701
01:00:45,384 --> 01:00:49,964
Now, what's nice about worktrees is that they give you parallelism.

702
01:00:50,204 --> 01:00:54,964
So if you are working on multiple features in your app, maybe you're using subagents

703
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

704
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

705
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

706
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.

707
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.

708
01:01:30,944 --> 01:01:33,884
And if there's a conflict, it's going to resolve that conflict.

709
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.

710
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.

711
01:01:49,244 --> 01:01:52,484
Now, this is a feature I use all the time in big projects.

712
01:01:52,724 --> 01:01:55,104
Now, let's say I'm working on this app over here.

713
01:01:55,204 --> 01:01:59,764
You can ask Codex to work in main without creating any work trees.

714
01:01:59,964 --> 01:02:04,664
Or I can ask it to create a new work tree while it makes changes.

715
01:02:04,904 --> 01:02:07,084
So let's continue what we were doing.

716
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.

717
01:02:11,764 --> 01:02:17,584
So I'm going to go ahead and tell it, make index.html output hello planet.

718
01:02:17,584 --> 01:02:21,504
But this time, we want to make sure that it works in a different work tree.

719
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

720
01:02:27,764 --> 01:02:29,064
after you're done.

721
01:02:29,344 --> 01:02:31,464
Okay, so we're going to go ahead and run this.

722
01:02:31,684 --> 01:02:35,344
And now it's not going to modify the file on our main branch.

723
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

724
01:02:40,884 --> 01:02:41,064
in.

725
01:02:41,204 --> 01:02:44,064
And so as you can see here, there's more stuff happening.

726
01:02:44,064 --> 01:02:47,384
I'll make this in a separate Git work tree, commit there,

727
01:02:47,604 --> 01:02:49,824
fast forward merge changes to main,

728
01:02:49,924 --> 01:02:52,164
and then remove the work tree and delete the branch.

729
01:02:52,464 --> 01:02:55,544
And that's exactly what it did, except it did it very, very...

730
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,

731
01:03:04,264 --> 01:03:09,444
made the change, merged everything back, and deleted the worktree. And so that was a very,

732
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

733
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

734
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

735
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,

736
01:03:34,504 --> 01:03:35,744
and do all this when you're done.

737
01:03:35,904 --> 01:03:38,924
We can continue working and then merge our changes.

738
01:03:39,204 --> 01:03:41,124
So for instance, I can say something like

739
01:03:41,124 --> 01:03:43,164
to say hello USA.

740
01:03:43,604 --> 01:03:44,564
I can simply do that.

741
01:03:44,684 --> 01:03:46,844
I don't need to tell it to work in a separate work tree

742
01:03:46,844 --> 01:03:49,144
because we are isolated here.

743
01:03:49,244 --> 01:03:50,404
Okay, so here's the file.

744
01:03:50,524 --> 01:03:51,344
We can open it.

745
01:03:51,464 --> 01:03:52,584
Hello USA here.

746
01:03:52,684 --> 01:03:53,404
And so at this point,

747
01:03:53,404 --> 01:03:55,884
we have merged the work tree change into main

748
01:03:55,884 --> 01:03:58,304
and cleaned up the temporary work tree, right?

749
01:03:58,404 --> 01:03:59,984
Index now displays hello USA

750
01:03:59,984 --> 01:04:02,844
and we no longer have this temporary work tree.

751
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.

752
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,

753
01:04:13,104 --> 01:04:15,264
but we've did everything we needed to do.

754
01:04:15,404 --> 01:04:16,844
We've updated the files.

755
01:04:16,944 --> 01:04:18,624
We've merged back into main.

756
01:04:18,944 --> 01:04:22,724
And so now we can start a brand new convo to work on a different feature.

757
01:04:22,824 --> 01:04:26,024
And so this is really nice for feature isolation.

758
01:04:26,284 --> 01:04:29,604
Create a new work tree, work there, merge back into main,

759
01:04:29,604 --> 01:04:33,524
and then simply click here to archive this conversation.

760
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

761
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.

762
01:04:47,924 --> 01:04:53,524
One agent explores the codebase, another works on a clearly bounded part of the UI,

763
01:04:53,524 --> 01:04:59,044
another checks tests or reviews the results. The key is ownership. If you use sub-agents,

764
01:04:59,044 --> 01:05:04,404
You want each one to have a specific job, clear file area, and a clear output.

765
01:05:04,564 --> 01:05:09,084
That keeps the work parallel without turning it into a merge mess.

766
01:05:09,404 --> 01:05:14,484
Sub-agents are best when the tasks are independent enough to run side by side,

767
01:05:14,724 --> 01:05:17,844
but still simple enough to integrate at the end.

768
01:05:17,924 --> 01:05:23,644
Now, sub-agents is another really cool feature that will help speed up your workflows.

769
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.

770
01:05:32,624 --> 01:05:32,804
All right.

771
01:05:32,844 --> 01:05:35,984
So here I have a very, very simple Kanban app.

772
01:05:36,224 --> 01:05:38,344
If I click over here, I have this.

773
01:05:38,524 --> 01:05:39,704
I can drag and drop.

774
01:05:39,824 --> 01:05:42,004
I can create new tasks, et cetera, et cetera.

775
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,

776
01:05:49,384 --> 01:05:53,504
I want to use subagents to help me kind of make sense of it.

777
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

778
01:05:58,604 --> 01:06:04,084
here, plan how to split this feature across subagents, right? Do not edit files yet, recommend.

779
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

780
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

781
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

782
01:06:21,684 --> 01:06:26,724
is for the main thread to own architecture, shared data contracts. Subagents can work on

783
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.

784
01:06:34,624 --> 01:06:39,564
Okay, so we have main thread responsibilities, and then we have subagent delegation,

785
01:06:39,764 --> 01:06:45,744
integration settings, integration data model, webhook event dispatcher. So I'm going to copy

786
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

787
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

788
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

789
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

790
01:07:06,984 --> 01:07:11,804
a new conversation. You're a subagent one, integration. You're a subagent two, integration

791
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

792
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

793
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

794
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,

795
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?

796
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

797
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

798
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.

799
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

800
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

801
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

802
01:08:06,484 --> 01:08:12,044
to do. They finished their isolated task and their services are no longer needed. And again,

803
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,

804
01:08:17,604 --> 01:08:24,464
because they help speed up the work by isolating different areas, different responsibility clusters

805
01:08:24,464 --> 01:08:28,224
to different agents. And that's a huge productivity boost.

806
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

807
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

808
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,

809
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

810
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

811
01:09:02,644 --> 01:09:09,484
should always run a specific check, use a specific design system, avoid certain files, create work

812
01:09:09,484 --> 01:09:16,084
trees for risky experiments, or split large tasks into sub-agents, those instructions belong in

813
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

814
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

815
01:09:30,544 --> 01:09:35,484
project purpose, the main folders, work tree, subagents, stuff like that. So we're going to

816
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

817
01:09:41,904 --> 01:09:48,464
tailored to the current project, right? Project purpose, main folders, verification steps after

818
01:09:48,464 --> 01:09:55,064
changes. Serve the app locally, coding and design patterns to preserve. When codecs should use a

819
01:09:55,064 --> 01:10:00,944
work tree. Use a separate work tree when these happen. When codecs should use subagents. Use

820
01:10:00,944 --> 01:10:06,644
subagents when work can be split into clearly separate ownership areas such as these. What

821
01:10:06,644 --> 01:10:11,884
codecs should avoid changing without asking? All of this. Now, the beautiful thing about this

822
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

823
01:10:20,504 --> 01:10:26,744
or create separate work trees, it will be automatic. It's like saving you from typing

824
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,

825
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.

826
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.

827
01:10:44,584 --> 01:10:47,444
So I'm going to say save it as agents.

828
01:10:47,664 --> 01:10:50,344
So now it's saved it as agents.md.

829
01:10:50,464 --> 01:10:54,224
You can click here and you can see the whole file right here.

830
01:10:54,384 --> 01:10:55,544
And this file will...

831
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,

832
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

833
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

834
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,

835
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.

836
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,

837
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.

838
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

839
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

840
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.

841
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.

842
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.

843
01:12:26,544 --> 01:12:30,984
Another question, should the new backend become the source of truth for Kanban tasks?

844
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

845
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

846
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

847
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,

848
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

849
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

850
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,

851
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

852
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

853
01:13:23,624 --> 01:13:30,184
because it basically codifies repeatable tasks. So you never have to re-prompt the same thing

854
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

855
01:13:38,264 --> 01:13:43,144
establish early. Codex can help inspect configuration, but we should be careful with

856
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

857
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

858
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

859
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

860
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

861
01:14:13,804 --> 01:14:19,644
deployment environment too. So the right workflow is to ask codecs to identify what variables are

862
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.

863
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

864
01:14:32,644 --> 01:14:38,344
services might be something like OpenAI, or another service could be OpenRouter. Well,

865
01:14:38,724 --> 01:14:44,004
every time we connect to external services, we need to connect them using an API key,

866
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

867
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

868
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

869
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

870
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

871
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

872
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

873
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.

874
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

875
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

876
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,

877
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

878
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

879
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

880
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,

881
01:16:12,184 --> 01:16:16,624
and it says here, inspect this project for environment variables and deployment config. Do

882
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

883
01:16:21,164 --> 01:16:26,664
it's telling us that environment inspection, required environment variables, required only

884
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

885
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

886
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

887
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

888
01:16:48,864 --> 01:16:55,024
something like your OpenAI API key or your OpenRouter API key or something of that sort

889
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

890
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

891
01:17:06,924 --> 01:17:12,824
server-side. It is used here, needed locally. Hosted service config, Vercel or another node

892
01:17:12,824 --> 01:17:18,404
capable host configured as a private server environment variables, port, etc, etc. Okay,

893
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,

894
01:17:24,004 --> 01:17:29,144
replace it with only this, only configure the real key in the deployment provider's private

895
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

896
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,

897
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

898
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

899
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

900
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

901
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

902
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

903
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

904
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

905
01:18:31,784 --> 01:18:35,584
And that way we have the local key stored for local testing.

906
01:18:35,784 --> 01:18:37,484
It's never going to be committed into Git.

907
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

908
01:18:44,204 --> 01:18:45,484
is going to be running our app.

909
01:18:45,544 --> 01:18:47,044
It needs access to that key as well.

910
01:18:47,104 --> 01:18:48,004
It needs to be secret.

911
01:18:48,224 --> 01:18:51,184
Okay, implemented the local Vercel key setup.

912
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

913
01:18:56,284 --> 01:18:58,724
kind of key management as part of our workflow.

914
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

915
01:19:03,684 --> 01:19:10,714
the key correctly for production stuff regardless of what kind of host you are using

916
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

917
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

918
01:19:25,074 --> 01:19:31,194
using existing libraries, existing frameworks, stuff like that. And those are called dependencies.

919
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

920
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

921
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

922
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

923
01:19:54,554 --> 01:20:00,034
prompt. Right. And this is what it came back with. Dependency project inspection. Framework and

924
01:20:00,034 --> 01:20:05,434
package manager. Framework non-detected. This appears to be a plain static JavaScript app

925
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

926
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

927
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,

928
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,

929
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

930
01:20:32,434 --> 01:20:37,954
there's no package manager, because there's no package.json. Current documented run command,

931
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.

932
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

933
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

934
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?

935
01:21:03,874 --> 01:21:09,774
Yes, for the current OpenAI API stack and local serving, the project already calls OpenAI via

936
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

937
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

938
01:21:24,094 --> 01:21:31,014
to change if preceding, right? API behavior, openA calls, frontend, et cetera, et cetera.

939
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

940
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

941
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

942
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

943
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

944
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

945
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

946
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

947
01:22:16,094 --> 01:22:22,514
dependencies, less chance for something to go wrong, less bloat, etc., etc. So definitely add

948
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

949
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

950
01:22:38,114 --> 01:22:45,414
start with something intentionally small. The first app is called HabitCard, and it is a tiny

951
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

952
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

953
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,

954
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

955
01:23:16,254 --> 01:23:24,254
backend complexity. HabitCard gives us the core app building pieces without much product complexity.

956
01:23:24,254 --> 01:23:33,274
a form, a list, a daily check-in state, simple feedback, and later local storage persistence.

957
01:23:33,614 --> 01:23:40,074
It does not need authentication, payments, APIs, or a real database at first.

958
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.

959
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.

960
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.

961
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.

962
01:24:11,734 --> 01:24:16,754
And here we can start a brand new conversation for the app that we are building.

963
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.

964
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.

965
01:24:32,774 --> 01:24:38,554
And we can actually use Codex to create that visual architecture for us.

966
01:24:38,654 --> 01:24:43,274
Now, I have here a prepared prompt that creates this visual architecture.

967
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.

968
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.

969
01:24:57,274 --> 01:25:01,314
Okay, and then we can say something like use image gen for the following.

970
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.

971
01:25:05,994 --> 01:25:09,894
Okay, and it came back with a habit card architecture diagram.

972
01:25:09,894 --> 01:25:15,314
And here it says create one raster infographic using this.

973
01:25:15,414 --> 01:25:16,614
So everything looks good.

974
01:25:16,734 --> 01:25:19,454
There's some diagram content, visual direction.

975
01:25:19,594 --> 01:25:20,854
It's a wide composition.

976
01:25:20,854 --> 01:25:21,454
Looks good.

977
01:25:21,974 --> 01:25:24,094
We're going to say, yes, implement this.

978
01:25:24,434 --> 01:25:24,634
Okay.

979
01:25:24,734 --> 01:25:26,194
And that is our habit card.

980
01:25:26,294 --> 01:25:27,974
That is our visual interface.

981
01:25:27,974 --> 01:25:32,234
And right away, I can see what this app is all about, right?

982
01:25:32,254 --> 01:25:33,314
We have add habit.

983
01:25:33,594 --> 01:25:35,034
We have habit list.

984
01:25:35,394 --> 01:25:36,794
We have today check-in.

985
01:25:37,074 --> 01:25:39,214
And we have a streak count.

986
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

987
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

988
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

989
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

990
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

991
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

992
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

993
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

994
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

995
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

996
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.

997
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

998
01:26:57,694 --> 01:27:05,554
a complex, ambiguous coding question or giving it an ambiguous coding instruction.

999
01:27:05,914 --> 01:27:10,714
And here is our NTC architecture. And unlike the visual architecture that we...

1000
01:27:10,834 --> 01:27:16,774
generated previously, here we're actually seeing the entities that will later become the actual

1001
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,

1002
01:27:23,534 --> 01:27:26,634
and then local storage as the backend.

1003
01:27:26,774 --> 01:27:28,914
So no backend, everything is stored locally

1004
01:27:28,914 --> 01:27:29,934
with local storage.

1005
01:27:30,374 --> 01:27:32,534
And this is also very, very useful

1006
01:27:32,534 --> 01:27:36,254
because unlike the visual diagram here,

1007
01:27:36,254 --> 01:27:38,874
I wanna see the actual schema.

1008
01:27:38,874 --> 01:27:42,074
I wanna see what kind of elements

1009
01:27:42,074 --> 01:27:45,074
or what kind of tables we might need

1010
01:27:45,074 --> 01:27:48,534
to translate this app schema into.

1011
01:27:49,074 --> 01:27:51,254
And as you can see, this is fairly simple.

1012
01:27:51,734 --> 01:27:53,214
Habit, habit check-in.

1013
01:27:53,534 --> 01:27:59,834
streak summary, we have these three main functions here, these three main features that were

1014
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,

1015
01:28:05,974 --> 01:28:11,774
created at date, completed count. Now at this point, we have both the visual architecture as

1016
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

1017
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,

1018
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

1019
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

1020
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

1021
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

1022
01:28:48,654 --> 01:28:55,794
The important part is that Codex should recommend the simplest path before it edits any files.

1023
01:28:55,994 --> 01:28:59,474
And as you might have guessed, we are going to be doing this in plan mode.

1024
01:28:59,574 --> 01:28:59,914
All right.

1025
01:28:59,954 --> 01:29:01,854
And here's the prompt that we're going to be using.

1026
01:29:01,854 --> 01:29:03,634
Do not edit files yet.

1027
01:29:03,794 --> 01:29:08,694
Inspect the current project and recommend the simplest stack for HabitCard, right?

1028
01:29:09,234 --> 01:29:11,634
And we ask him what it should come back with.

1029
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

1030
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

1031
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

1032
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

1033
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

1034
01:29:43,314 --> 01:29:50,474
React TypeScript, right? It wants to use Tailwind CSS for fast, simple styling. This is testing

1035
01:29:50,474 --> 01:29:57,594
library, no React router. It's a simple single screen app, no global state library, okay?

1036
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.

1037
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

1038
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

1039
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

1040
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?

1041
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

1042
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

1043
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

1044
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

1045
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

1046
01:30:59,614 --> 01:31:07,694
and it shows us things like artifacts, background terminal, and basically things that were created

1047
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

1048
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,

1049
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

1050
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

1051
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

1052
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

1053
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

1054
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

1055
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

1056
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.

1057
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

1058
01:32:11,174 --> 01:32:17,854
persistence step with local storage. Habits and today's check-ins can persist after refresh,

1059
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

1060
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.

1061
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.

1062
01:32:36,874 --> 01:32:41,374
Now it's actually telling us that inspection shows that habit card already implements the

1063
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.

1064
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,

1065
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

1066
01:32:58,294 --> 01:33:05,574
persistence works through this storage using these keys and a lot of other details here. Okay,

1067
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

1068
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

1069
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

1070
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

1071
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

1072
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

1073
01:33:41,754 --> 01:33:47,734
place, but it's very, very limiting compared to something like Superbase or something of that

1074
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,

1075
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

1076
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.

1077
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

1078
01:34:12,694 --> 01:34:15,734
and it's not using a unified backend

1079
01:34:15,734 --> 01:34:19,794
so that no matter which browser I use,

1080
01:34:20,234 --> 01:34:23,174
it will still store the data and keep track of everything.

1081
01:34:23,314 --> 01:34:24,514
That is not happening.

1082
01:34:24,774 --> 01:34:28,274
Now, once the app works locally, it's time to deploy it.

1083
01:34:28,434 --> 01:34:30,194
Even though HabitCard is simple,

1084
01:34:30,634 --> 01:34:34,354
this is the first moment where Codex helps move something

1085
01:34:34,354 --> 01:34:37,954
from local code to a real-life URL.

1086
01:34:37,954 --> 01:34:41,194
And so Codex can do the whole deployment process.

1087
01:34:41,194 --> 01:34:47,334
It can run the local checks, prepare the projects, connect or create the Vercel project,

1088
01:34:47,834 --> 01:34:52,814
deploy the frontend, and then verify that the live page actually loads.

1089
01:34:53,094 --> 01:34:56,974
And additionally, you want that first deployment to feel very concrete.

1090
01:34:57,274 --> 01:34:59,794
We're not just writing code and hoping it works.

1091
01:35:00,334 --> 01:35:04,334
We're taking a small app, shipping it, opening the deployed URL,

1092
01:35:04,794 --> 01:35:09,374
and checking the result like we would with a real project.

1093
01:35:09,374 --> 01:35:15,534
And here is my Vercel deployment prompt. Prepare HabitCard for deployment on Vercel

1094
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

1095
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

1096
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

1097
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

1098
01:35:41,674 --> 01:35:43,714
use it automatically with no issues.

1099
01:35:44,652 --> 01:35:46,392
I'm going to go ahead and execute this.

1100
01:35:46,392 --> 01:35:50,452
All right, so it went ahead and created a Vercel deployment plan.

1101
01:35:50,452 --> 01:35:56,552
HabitCard is already suitable for a front-end only Vercel deployment.

1102
01:35:56,552 --> 01:35:57,992
And this is what it's going to do.

1103
01:35:57,992 --> 01:36:00,672
And here is the deployment implementation.

1104
01:36:00,672 --> 01:36:01,952
Keep the app front-end only.

1105
01:36:01,952 --> 01:36:08,272
Do not add convex, which is a backend, APIs, auth database, server functions, or external

1106
01:36:08,272 --> 01:36:09,272
services.

1107
01:36:09,272 --> 01:36:10,692
None of that.

1108
01:36:10,692 --> 01:36:16,252
And local storage persistence is expected to be local to each browser and deployment

1109
01:36:16,252 --> 01:36:17,252
origin.

1110
01:36:17,252 --> 01:36:19,932
Data will not sync across devices or URLs.

1111
01:36:19,932 --> 01:36:23,112
Okay, let's go ahead and implement this plan.

1112
01:36:23,112 --> 01:36:28,992
three minutes later, it tells us that deployed HabitCard to resell and verified it live. Okay,

1113
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

1114
01:36:36,232 --> 01:36:42,672
on the web, right? Accessible to everybody. And this, again, uses local storage. Okay,

1115
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

1116
01:36:47,832 --> 01:36:54,392
instance because it's all stored locally. And so at this point, we designed, architected, built,

1117
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

1118
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

1119
01:37:09,272 --> 01:37:17,272
same, but with more complex apps, slowly adding things like authentication, backend, and other

1120
01:37:17,272 --> 01:37:22,212
important components that you need for a real production app.

1121
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

1122
01:37:30,712 --> 01:37:33,932
lunch or snack ideas and vote on the winner.

1123
01:37:34,032 --> 01:37:38,872
It's a bit more complex with more features, but still fairly simple overall.

1124
01:37:38,932 --> 01:37:46,932
SnackVote has a submit option form, a snack option list, vote buttons, a live leaderboard

1125
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

1126
01:37:53,192 --> 01:37:58,552
marketplace app we'll build right after this. Instead of jumping straight into complex entities

1127
01:37:58,552 --> 01:38:05,432
such as customers, bookings, and permissions, we can first learn the backend pattern on a much

1128
01:38:05,432 --> 01:38:12,792
smaller app. SnackVote only needs snack options and votes. Someone can submit an option, other

1129
01:38:12,792 --> 01:38:18,872
people can vote, and the leaderboard updates as the vote counts change. That gives us enough

1130
01:38:18,872 --> 01:38:25,352
structure to understand live backend data without making the product itself hard to follow.

1131
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

1132
01:38:31,752 --> 01:38:38,232
be simple enough to understand immediately. Create or join a voting room, submit a Snack

1133
01:38:38,232 --> 01:38:46,452
option, vote once, watch the leaderboard update, and see a deadline-driven winner state. Now here

1134
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.

1135
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

1136
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

1137
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

1138
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

1139
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

1140
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

1141
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

1142
01:39:31,852 --> 01:39:38,732
have your voting buttons, you have a live leaderboard, and you have a closed winner state

1143
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

1144
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

1145
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

1146
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

1147
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.

1148
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

1149
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

1150
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

1151
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

1152
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

1153
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

1154
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

1155
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,

1156
01:41:05,692 --> 01:41:08,952
because there are lots of ways that we can build out this app.

1157
01:41:09,092 --> 01:41:12,892
And we want Codex to tell us the best options for this specific app.

1158
01:41:13,152 --> 01:41:14,812
Here's the prompt that we're going to be using.

1159
01:41:14,812 --> 01:41:17,152
And I'm going to switch into plan mode here.

1160
01:41:17,352 --> 01:41:20,312
And it's telling us, do not edit files yet.

1161
01:41:20,312 --> 01:41:26,172
inspect the current project and recommend the simplest stack for Snackville. And here's the

1162
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,

1163
01:41:31,332 --> 01:41:38,032
TypeScript, Tailwind. And here it says back and later convex with TypeScript server functions and

1164
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

1165
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

1166
01:41:50,792 --> 01:41:58,392
features and also connecting a backend for the first time in this tutorial. Now here, instead

1167
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

1168
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

1169
01:42:11,752 --> 01:42:18,532
a database or persistence. Inspect the current project first, then build the smallest useful

1170
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

1171
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

1172
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

1173
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

1174
01:42:42,932 --> 01:42:49,392
conversation, we already fleshed out, you know, things like the architecture, the stack, and all

1175
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

1176
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.

1177
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

1178
01:43:06,532 --> 01:43:14,332
vote app here, created all of this, what works, verification completed, still needs attention

1179
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

1180
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

1181
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

1182
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

1183
01:43:38,972 --> 01:43:44,212
with some votes here. Leaderboard, right? So this is where...

1184
01:43:44,752 --> 01:43:46,352
Winner state, current winner,

1185
01:43:46,552 --> 01:43:48,512
leader, spicy ramen bowls.

1186
01:43:49,092 --> 01:43:51,312
And so if I vote on falafel wraps,

1187
01:43:52,332 --> 01:43:53,392
six, right?

1188
01:43:53,492 --> 01:43:54,412
So now it's six.

1189
01:43:54,512 --> 01:43:55,472
I can keep voting.

1190
01:43:55,992 --> 01:43:58,112
And that's a problem right away.

1191
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

1192
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,

1193
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

1194
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,

1195
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

1196
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

1197
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

1198
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

1199
01:44:47,632 --> 01:44:53,972
interface and start behaving like a real database-backed product. And the path is very, very

1200
01:44:53,972 --> 01:45:01,412
simple codex, creates the convex schema, adds a query, adds mutations, connects it to the UI,

1201
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

1202
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,

1203
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

1204
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

1205
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

1206
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

1207
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

1208
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

1209
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.

1210
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

1211
01:46:01,012 --> 01:46:06,752
going to automatically create a brand new project for its data, for its functions, for everything.

1212
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.

1213
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

1214
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

1215
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

1216
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

1217
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

1218
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?

1219
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,

1220
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,

1221
01:47:04,732 --> 01:47:11,252
which is a package manager, could fetch Convex temporarily, but the project does not have it

1222
01:47:11,252 --> 01:47:18,052
installed. I'm installing Convex into the project now as a dev dependency. Convex is installed

1223
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

1224
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.

1225
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

1226
01:47:35,752 --> 01:47:42,112
prompt, upgrade SnackVote. So SnackOptions and votes are stored in Convex instead of local in

1227
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

1228
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

1229
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

1230
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

1231
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

1232
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

1233
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

1234
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,

1235
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

1236
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

1237
01:48:38,952 --> 01:48:46,712
it has created a fresh cloud project and synced the backend function successfully. And now you

1238
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

1239
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

1240
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

1241
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

1242
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

1243
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

1244
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

1245
01:49:27,492 --> 01:49:32,312
here. You can actually see it happening. The snack was submitted through the browser and appeared

1246
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.

1247
01:49:38,832 --> 01:49:44,872
All right. Now it's telling us implemented the Convex-backed snack vote upgrade, changed all

1248
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

1249
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,

1250
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

1251
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

1252
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

1253
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

1254
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

1255
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

1256
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,

1257
01:50:44,172 --> 01:50:53,092
you need functions. And so the snack options table or document has three functions. No files,

1258
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

1259
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.

1260
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.

1261
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

1262
01:51:19,372 --> 01:51:27,152
lunch or team snacks. Each room should own its own snack options, votes, leaderboard,

1263
01:51:27,572 --> 01:51:33,852
and winner's state. This keeps the app more interesting while teaching a clean backend

1264
01:51:33,852 --> 01:51:41,652
concept, scoped data. We still do not need accounts, permissions, invites, or admin tools.

1265
01:51:41,652 --> 01:51:44,112
And here's the prompt that we're going to be using.

1266
01:51:44,352 --> 01:51:49,732
Upgrade snack vote so voting happens inside simple rooms.

1267
01:51:49,932 --> 01:51:52,532
And I'm going to run this in a plan mode.

1268
01:51:52,532 --> 01:51:55,212
All right, so it came back with a plan for us.

1269
01:51:55,292 --> 01:51:58,232
This is the room-based snack vote upgrade.

1270
01:51:58,232 --> 01:52:03,312
Upgrade the current ConvexBack app from one global snack board to simple rooms.

1271
01:52:03,592 --> 01:52:04,812
Going to expand that.

1272
01:52:05,052 --> 01:52:06,292
Yes, implement that.

1273
01:52:06,412 --> 01:52:10,112
So as it's running, I am seeing an error message here.

1274
01:52:10,712 --> 01:52:14,192
Did you forget to run npx convex dev?

1275
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.

1276
01:52:20,352 --> 01:52:21,152
It is done.

1277
01:52:21,372 --> 01:52:24,012
So it has implemented room-based snack.

1278
01:52:24,012 --> 01:52:25,532
Whoa, this is what it changed.

1279
01:52:25,532 --> 01:52:32,432
files, things, verification, limits. Okay, very important. Limits is actually very, very useful.

1280
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.

1281
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.

1282
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

1283
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

1284
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

1285
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

1286
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,

1287
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.

1288
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

1289
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.

1290
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

1291
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,

1292
01:53:47,412 --> 01:53:52,612
Oh no, I created lunch ideas. These ones were created by Codex, these three rooms.

1293
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,

1294
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,

1295
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.

1296
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

1297
01:54:17,832 --> 01:54:18,312
tested.

1298
01:54:18,612 --> 01:54:23,452
We'll add one simple rule that makes the voting feel like a real product.

1299
01:54:24,092 --> 01:54:30,272
After all, a person should not be able to spam the same room with repeated votes.

1300
01:54:30,612 --> 01:54:33,372
And that is because we still do not have real authentication.

1301
01:54:33,852 --> 01:54:39,572
And so for this tutorial, a local or session-based voter identity is enough.

1302
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

1303
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,

1304
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.

1305
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

1306
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

1307
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

1308
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,

1309
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

1310
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

1311
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

1312
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

1313
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

1314
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

1315
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.

1316
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.

1317
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

1318
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.

1319
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

1320
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

1321
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.

1322
01:56:56,252 --> 01:57:02,832
So I can switch votes, but I cannot pad with multiple votes an item.

1323
01:57:03,172 --> 01:57:05,752
And so if I go back here, now there are two options, right?

1324
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.

1325
01:57:12,152 --> 01:57:14,612
So this works really, really nice.

1326
01:57:14,952 --> 01:57:21,232
And finally, we'll add a deadline so each room has a moment when voting closes.

1327
01:57:21,892 --> 01:57:24,732
Before the deadline, people can submit and vote.

1328
01:57:24,732 --> 01:57:31,772
After the deadline, voting locks and the app shows the winner or a simple tie state.

1329
01:57:31,952 --> 01:57:37,292
This adds time-based product state without becoming a scheduling system.

1330
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.

1331
01:57:49,332 --> 01:57:51,572
And here's the prompt that we're going to be using.

1332
01:57:51,572 --> 01:57:53,772
I'm going to switch into plan mode.

1333
01:57:54,112 --> 01:57:54,752
Run this.

1334
01:57:54,912 --> 01:57:56,812
Oh, it needs a product decision.

1335
01:57:57,012 --> 01:58:02,152
Okay, how should users set a room deadline in this small tutorial version?

1336
01:58:02,732 --> 01:58:03,792
Quick durations.

1337
01:58:04,372 --> 01:58:07,932
Okay, add simple buttons like 1 minute, 5 minute, 15 minute.

1338
01:58:08,152 --> 01:58:09,932
When creating opening a room.

1339
01:58:10,292 --> 01:58:12,832
Daytime input or fixed default.

1340
01:58:13,012 --> 01:58:14,352
Let's do quick durations.

1341
01:58:14,712 --> 01:58:15,512
That sounds good.

1342
01:58:15,612 --> 01:58:16,852
Let's implement this.

1343
01:58:17,052 --> 01:58:18,272
And it is complete.

1344
01:58:18,432 --> 01:58:20,612
Implemented simple voting deadlines.

1345
01:58:20,612 --> 01:58:22,092
This is what was changed.

1346
01:58:22,612 --> 01:58:24,672
Added quick deadline choices.

1347
01:58:24,852 --> 01:58:28,312
No deadline, one minute, five minutes, 15 minutes.

1348
01:58:28,472 --> 01:58:29,412
All of this.

1349
01:58:29,652 --> 01:58:32,132
And let's go ahead and see how this works.

1350
01:58:32,432 --> 01:58:32,812
All right.

1351
01:58:32,872 --> 01:58:33,912
So here we are.

1352
01:58:34,092 --> 01:58:37,112
And let's go ahead and create the room, Friday lunch.

1353
01:58:37,412 --> 01:58:39,252
And let's say it's five minutes.

1354
01:58:39,452 --> 01:58:40,632
Select five minutes.

1355
01:58:41,072 --> 01:58:41,692
Open the room.

1356
01:58:41,892 --> 01:58:43,392
This still says no deadline.

1357
01:58:43,532 --> 01:58:44,532
Let's try another room.

1358
01:58:44,612 --> 01:58:46,712
Let's say Sunday brunch.

1359
01:58:46,972 --> 01:58:48,332
I can select no deadline.

1360
01:58:48,532 --> 01:58:49,752
I can do 15 minutes.

1361
01:58:49,752 --> 01:58:51,072
Let's try 15 minutes.

1362
01:58:51,532 --> 01:58:52,932
See, it says no deadline.

1363
01:58:53,092 --> 01:58:54,072
Okay, that's a bug.

1364
01:58:54,272 --> 01:58:55,532
That's definitely a bug.

1365
01:58:55,652 --> 01:58:57,632
So let's see if it's able to fix it.

1366
01:58:57,672 --> 01:59:03,132
That's the first bug that has happened to us, as far as I remember.

1367
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,

1368
01:59:10,832 --> 01:59:12,832
but it ended up creating...

1369
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

1370
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

1371
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

1372
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

1373
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

1374
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

1375
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,

1376
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,

1377
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

1378
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,

1379
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.

1380
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

1381
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

1382
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

1383
02:00:43,368 --> 02:00:48,708
deadline and opening an existing no deadline room still leaves the room with no deadline.

1384
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

1385
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,

1386
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.

1387
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.

1388
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.

1389
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.

1390
02:01:28,248 --> 02:01:36,448
Now, once SnackVote has rooms, session-based voting, and a deadline, we are ready to deploy

1391
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

1392
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

1393
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

1394
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

1395
02:02:04,028 --> 02:02:10,988
remains whether the Vercel app should use the existing Convex dev deployment or it should

1396
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

1397
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

1398
02:02:21,468 --> 02:02:27,548
all your deployments, your different deployments. So we are currently on the development deployment,

1399
02:02:27,548 --> 02:02:33,228
on the development cloud. We can also have a production deployment, preview deployments,

1400
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

1401
02:02:39,168 --> 02:02:43,688
the production convex, and that's what we're going to select, because this makes sense.

1402
02:02:43,868 --> 02:02:51,188
Production deployment uses the production convex. Development deployment uses the development

1403
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

1404
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,

1405
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

1406
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

1407
02:03:17,688 --> 02:03:24,048
convex production, okay? So this is the live URL, what we're seeing here, deployment URL,

1408
02:03:24,048 --> 02:03:25,688
and the convex backend.

1409
02:03:26,128 --> 02:03:27,548
And if we go into convex,

1410
02:03:28,328 --> 02:03:30,308
you can see that it's currently pointing

1411
02:03:30,308 --> 02:03:32,328
to the production URL here.

1412
02:03:32,388 --> 02:03:34,068
And we have everything here in production.

1413
02:03:34,328 --> 02:03:36,468
So we have the dev instance

1414
02:03:36,468 --> 02:03:39,508
pointing to the dev deployment in convex

1415
02:03:39,508 --> 02:03:42,508
and the production instance in Vercel

1416
02:03:42,508 --> 02:03:46,088
pointing to the production instance here in convex.

1417
02:03:46,368 --> 02:03:48,148
So we have all the same functions.

1418
02:03:48,148 --> 02:03:49,868
We have all the same data.

1419
02:03:49,968 --> 02:03:50,928
Everything is there.

1420
02:03:51,128 --> 02:03:52,808
The data might be a little different,

1421
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,

1422
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,

1423
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

1424
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.

1425
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.

1426
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.

1427
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.

1428
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.

1429
02:05:09,548 --> 02:05:13,808
Now, for this last app in the course, we're going to be building FlexHelp.

1430
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.

1431
02:05:20,488 --> 02:05:26,528
A two-sided marketplace where helpers offer fixer services and customers book them.

1432
02:05:26,748 --> 02:05:30,388
The important thing is that we will still build it in controlled steps.

1433
02:05:30,588 --> 02:05:34,028
We're not going to ask Codex to build the whole marketplace at once.

1434
02:05:34,168 --> 02:05:38,808
We are going to architect it, design it, build the UI, then add feature by feature.

1435
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.

1436
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

1437
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

1438
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

1439
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

1440
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

1441
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

1442
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

1443
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

1444
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

1445
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

1446
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.

1447
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,

1448
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.

1449
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

1450
02:07:03,408 --> 02:07:08,608
request. The helper side, we have the helper dashboard and the status updates. And on the

1451
02:07:08,608 --> 02:07:13,368
shared marketplace screens, we have explore the marketplace, buy bookings, and...

1452
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

1453
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

1454
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,

1455
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

1456
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

1457
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.

1458
02:07:52,168 --> 02:07:57,588
We have the booking here, booking status, service, category, review, and all of that

1459
02:07:57,588 --> 02:07:59,908
backed with convex data.

1460
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.

1461
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.

1462
02:08:10,268 --> 02:08:14,648
And I see that booking is super important because everybody needs to have access to

1463
02:08:14,648 --> 02:08:19,048
booking, both customers and helpers, booking status, service, category.

1464
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

1465
02:08:25,728 --> 02:08:32,628
a super complex or like a super complicated app that has a ton of different entities,

1466
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

1467
02:08:38,688 --> 02:08:44,328
various entities. And so that will increase the complexity as the development continues.

1468
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

1469
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

1470
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

1471
02:09:05,448 --> 02:09:11,508
first. And this is super important because we want to start with the blueprint before

1472
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

1473
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

1474
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.

1475
02:09:27,648 --> 02:09:32,848
This is what it's suggesting. The workspace is currently empty. The simplest course-friendly

1476
02:09:32,848 --> 02:09:41,208
stack is React, TypeScript, Convex for backend data, auth, Tailwind for UI, and Resell for hosting.

1477
02:09:41,208 --> 02:09:44,488
And this is exactly what we've been doing so far.

1478
02:09:44,728 --> 02:09:47,148
And here it's listing some primary routes.

1479
02:09:47,428 --> 02:09:51,548
Services, bookings, customer bookings, helper, helper services.

1480
02:09:51,948 --> 02:09:54,668
Here we have the data flow, the auth recommendations,

1481
02:09:55,008 --> 02:09:56,948
UI and component approach,

1482
02:09:57,228 --> 02:10:01,388
verse cell deployment path, stage build plan, everything.

1483
02:10:01,648 --> 02:10:06,648
So I'm going to exit out because this was only a read-only plan mode.

1484
02:10:06,808 --> 02:10:08,888
I don't want it to do anything just yet

1485
02:10:08,888 --> 02:10:11,588
because that's what we're going to be doing in the next step.

1486
02:10:11,688 --> 02:10:15,568
Now, from the visual architecture, the entity map, and the stack recommendation,

1487
02:10:15,928 --> 02:10:21,008
we have a pretty good idea of how the Flex Help app is evolving.

1488
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

1489
02:10:25,648 --> 02:10:29,168
at turning that plan into a static product UI.

1490
02:10:29,628 --> 02:10:32,468
Now, this first version does not need any backend data.

1491
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.

1492
02:10:39,688 --> 02:10:41,328
And this is the prompt that I'm going to be using.

1493
02:10:41,488 --> 02:10:47,428
Build the first static FlexHelp UI design from the existing architecture and stack direction.

1494
02:10:47,748 --> 02:10:49,308
We're going to stay in the plan mode.

1495
02:10:49,568 --> 02:10:51,008
I'm going to go ahead and execute that.

1496
02:10:51,248 --> 02:10:52,868
And let's see how well it does.

1497
02:10:53,168 --> 02:10:55,188
And here's the plan that it came up with.

1498
02:10:55,268 --> 02:11:00,848
Okay, the goal is a polished visual prototype that matches the FlexHelp architecture.

1499
02:11:00,848 --> 02:11:03,808
Okay, and here it lists some details about the architecture.

1500
02:11:04,248 --> 02:11:07,248
And let's go ahead and run this prompt.

1501
02:11:07,408 --> 02:11:08,988
So it finished working.

1502
02:11:09,448 --> 02:11:12,068
And let's go ahead and see what we have here.

1503
02:11:12,188 --> 02:11:13,848
Okay, so this is our app.

1504
02:11:14,008 --> 02:11:15,888
And this is kind of how it looks like.

1505
02:11:16,028 --> 02:11:17,588
Okay, book practical help.

1506
02:11:17,748 --> 02:11:20,128
And we have some active requests.

1507
02:11:20,368 --> 02:11:22,668
We have booking entry, helper dashboard.

1508
02:11:23,228 --> 02:11:24,108
We have this.

1509
02:11:24,428 --> 02:11:24,968
Look at this.

1510
02:11:25,088 --> 02:11:25,988
It even works.

1511
02:11:26,328 --> 02:11:30,828
Service detail, a small plumbing repair, helper dashboard.

1512
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

1513
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

1514
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,

1515
02:11:51,968 --> 02:11:57,988
for solving all kinds of problems, but for actually designing stuff, it's not the most

1516
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

1517
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,

1518
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

1519
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,

1520
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

1521
02:12:28,528 --> 02:12:34,828
Flow Designer. It's a very, very lightweight tool, and it works really great with Codex.

1522
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

1523
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,

1524
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

1525
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.

1526
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

1527
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

1528
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

1529
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

1530
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

1531
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

1532
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

1533
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

1534
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

1535
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.

1536
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,

1537
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

1538
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

1539
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

1540
02:14:23,548 --> 02:14:29,708
Waterflow Designer concept for FlexHelp. FlexHelp is a two-sided marketplace, and we are telling it

1541
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,

1542
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

1543
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

1544
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,

1545
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,

1546
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

1547
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,

1548
02:15:10,528 --> 02:15:12,408
So I don't know which one you guys like.

1549
02:15:12,628 --> 02:15:13,368
This is a classic.

1550
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

1551
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

1552
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

1553
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.

1554
02:15:36,188 --> 02:15:41,648
We even have a map, helper dashboard, helper request management, and a user profile.

1555
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.

1556
02:15:50,608 --> 02:15:51,708
And so let's take a look.

1557
02:15:51,788 --> 02:15:55,348
So this is called Flex Help Marketplace, the name of the project here.

1558
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.

1559
02:15:58,728 --> 02:16:00,868
We're going to close out this section here.

1560
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.

1561
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.

1562
02:16:13,708 --> 02:16:15,968
And I have a prompt here to do just that.

1563
02:16:16,088 --> 02:16:16,968
So here's the prompt.

1564
02:16:17,048 --> 02:16:21,748
Update the FlexSelf Static UI to match the approved Flutter Flow Designer reference.

1565
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.

1566
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.

1567
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.

1568
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.

1569
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

1570
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.

1571
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

1572
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

1573
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.

1574
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

1575
02:17:29,548 --> 02:17:35,728
static UI to visually follow the approved Flutter Flow Designer reference. So here it has

1576
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

1577
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

1578
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.

1579
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

1580
02:18:04,728 --> 02:18:10,768
should have all of these pages. User profile helper, request management helper dashboard,

1581
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

1582
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

1583
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

1584
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

1585
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,

1586
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

1587
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,

1588
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

1589
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

1590
02:19:10,468 --> 02:19:16,008
probably remove any other placeholder icons. But right now it looks fairly clean. Static preview,

1591
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

1592
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

1593
02:19:29,108 --> 02:19:33,168
and replace these placeholders with the actual design.

1594
02:19:33,448 --> 02:19:34,708
All right, so let's fix it.

1595
02:19:34,768 --> 02:19:35,868
Now it looks a lot better.

1596
02:19:35,968 --> 02:19:38,268
We still see some other static preview.

1597
02:19:38,368 --> 02:19:38,908
That's okay.

1598
02:19:39,068 --> 02:19:43,148
Let's see if they go away once we have real data being fed.

1599
02:19:43,288 --> 02:19:45,228
So once we're happy with the UI,

1600
02:19:45,528 --> 02:19:48,128
we can start designing the backend.

1601
02:19:48,128 --> 02:19:50,588
Data model should match the screens

1602
02:19:50,588 --> 02:19:52,068
that we actually have here.

1603
02:19:52,508 --> 02:19:53,648
And so for FlexHelp,

1604
02:19:53,868 --> 02:19:56,848
the first schema should support service browsing,

1605
02:19:57,028 --> 02:19:58,908
helper profiles, booking creation,

1606
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

1607
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

1608
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

1609
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

1610
02:20:25,508 --> 02:20:32,268
marketplace UI to convex for the first database-backed read path. The repo currently has

1611
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.

1612
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

1613
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

1614
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

1615
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

1616
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

1617
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

1618
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

1619
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

1620
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.

1621
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

1622
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,

1623
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

1624
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?

1625
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,

1626
02:22:01,628 --> 02:22:06,568
Marcus, right? And I go back here, now it's automatically Marcus E here. It automatically

1627
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

1628
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,

1629
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

1630
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.

1631
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,

1632
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.

1633
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

1634
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

1635
02:22:50,448 --> 02:22:55,508
implement this plan. All right. So it has implemented the customer booking creation path.

1636
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

1637
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

1638
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

1639
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

1640
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,

1641
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

1642
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

1643
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

1644
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

1645
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

1646
02:23:58,808 --> 02:24:04,508
together. Now, once customers can create bookings, helpers need a place to see and manage them.

1647
02:24:04,968 --> 02:24:10,788
The helper dashboard should show incoming requests and make it obvious what action the helper can

1648
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.

1649
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.

1650
02:24:23,068 --> 02:24:27,268
Those status changes are what turn the app into a workflow.

1651
02:24:27,608 --> 02:24:31,088
This is also a good place to show the power of live data.

1652
02:24:31,348 --> 02:24:36,428
When a status changes, the UI should update and the convex row should change.

1653
02:24:36,588 --> 02:24:39,868
That gives us a real end-to-end marketplace loop.

1654
02:24:40,068 --> 02:24:44,288
Customer request, helper action, back-end stay, and UI update.

1655
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

1656
02:24:49,048 --> 02:24:54,948
viewing booking requests and updating booking status. Okay, I'm going to switch into plan mode,

1657
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

1658
02:25:00,548 --> 02:25:06,008
handle the existing requested booking status? Keep requested. This is recommended. Preserve

1659
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

1660
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

1661
02:25:16,928 --> 02:25:22,928
go with the easiest option. And then how should the helper request visibility work before auth

1662
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

1663
02:25:29,328 --> 02:25:34,828
bookings for their convex helper profile only. Simplest UI and backend, but less realistic. So

1664
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

1665
02:25:40,228 --> 02:25:45,148
first helper-facing workflow on top of existing convex booking creation path. We're going to

1666
02:25:45,148 --> 02:25:50,828
submit this. Here's our progress. All right, so we just implemented the helper booking status

1667
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,

1668
02:25:55,828 --> 02:26:02,228
accepted, in progress, completed. It viewed it under helper James, created booking this. So it

1669
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

1670
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

1671
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

1672
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

1673
02:26:24,688 --> 02:26:29,508
anything. Here we have recent activity, right? Completed, completed, canceled. And this is the

1674
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

1675
02:26:36,108 --> 02:26:41,308
canceled, we have completed. Even a simple marketplace has different responsibilities.

1676
02:26:41,548 --> 02:26:47,008
Customers create booking requests and view their own bookings. Helpers manage requests that belong

1677
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

1678
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

1679
02:26:59,408 --> 02:27:05,728
functions need to enforce ownership and permissions because the UI can always be bypassed.

1680
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

1681
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

1682
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

1683
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

1684
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,

1685
02:27:34,208 --> 02:27:41,768
should this step plan for demo sessions add convex back demo users and or convex

1686
02:27:41,768 --> 02:27:47,288
or add real convex or sign and sign up more production shape but larger and

1687
02:27:47,288 --> 02:27:51,548
currently beta or this clerk use third-party auth provider let's go with

1688
02:27:51,548 --> 02:27:56,828
convex or how should customer helper roles be represented for version one

1689
02:27:56,828 --> 02:28:02,768
role plus profile so what is this each demo user has customer helper both and

1690
02:28:02,768 --> 02:28:08,188
and helpers linked to one helper profile for requests. Separate accounts. Customer and helper

1691
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,

1692
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

1693
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,

1694
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.

1695
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,

1696
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

1697
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,

1698
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

1699
02:28:59,588 --> 02:29:05,148
flow now confirms a customer created booking appears for the linked helper and can be moved

1700
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

1701
02:29:10,668 --> 02:29:17,428
boundary layer over here. Okay. So marketplace browsing stays public. Booking creation requires

1702
02:29:17,428 --> 02:29:24,348
a customer or both demo user. Customer booking status only shows bookings owned by the signed

1703
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

1704
02:29:31,128 --> 02:29:37,828
profile ID. And so remaining limitation, this is still tutorial demo auth, not production

1705
02:29:37,828 --> 02:29:43,828
authentication. Real convex auth or clerk can replace demo session issuance later while keeping

1706
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

1707
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

1708
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

1709
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

1710
02:30:07,208 --> 02:30:14,968
various operations. Here we have sessions, we have various services, we also have functions that also

1711
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,

1712
02:30:21,748 --> 02:30:29,028
list for customer, etc. And these functions, they are meant to work with specific roles,

1713
02:30:29,168 --> 02:30:34,988
so that authentication is baked in into these functions. Now, when something breaks, the wrong

1714
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

1715
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

1716
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,

1717
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,

1718
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

1719
02:31:09,028 --> 02:31:13,368
sort of issue regarding debugging, polish, verification, stuff.

1720
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

1721
02:31:18,248 --> 02:31:24,348
existing FlexHelp product workflow. Inspect the current app first, then identify the smallest set

1722
02:31:24,348 --> 02:31:31,108
of fixes and polish improvements needed to make the current workflow feel credible. Let's jump

1723
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,

1724
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.

1725
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

1726
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

1727
02:31:56,348 --> 02:32:02,768
it came up with. Tighten the existing customer, helper, convex, and demo OAuth workflows without

1728
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

1729
02:32:08,928 --> 02:32:15,108
assumptions. No new marketplace features will be added, no payments, nothing. Okay, that stays.

1730
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.

1731
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

1732
02:32:26,908 --> 02:32:32,668
interesting things. It fixed some placeholders. It did some testing. It switched to different

1733
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

1734
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,

1735
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

1736
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.

1737
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

1738
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

1739
02:33:09,088 --> 02:33:15,388
and is live connected to the intended convex backend and smoke tested through the real product

1740
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

1741
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

1742
02:33:27,628 --> 02:33:32,228
jump into plan mode so that it can prepare everything, plan everything out. One thing that

1743
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

1744
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

1745
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,

1746
02:33:49,888 --> 02:33:54,608
right? That we want to use the Vercel plugin. Which convex environment should the deployed

1747
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

1748
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

1749
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

1750
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.

1751
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.

1752
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.

1753
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,

1754
02:34:29,408 --> 02:34:33,888
remember we're using this. We also have a production deployment setup. So it's going

1755
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

1756
02:34:38,328 --> 02:34:43,228
that good stuff as part of this deployment. Production convex is now seated and responding

1757
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.

1758
02:34:48,168 --> 02:34:52,748
Sessions, services, we have the data. All right, so it looks like it has deployed it,

1759
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,

1760
02:34:58,068 --> 02:35:04,628
because now it's in production and it's also using the production convex deployment, right?

1761
02:35:04,688 --> 02:35:09,488
So we need to test things again because, you know, it's using new environments now.

1762
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

1763
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

1764
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?

1765
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

1766
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,

1767
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

1768
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.,

1769
02:35:51,508 --> 02:35:57,188
two hours, it's fixed, address, send booking. Okay, so we've booking requests submitted,

1770
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

1771
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.

1772
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,

1773
02:36:13,748 --> 02:36:21,428
and I go into customers home, booking request for maybe summary right here, customer booking status.

1774
02:36:21,508 --> 02:36:26,008
Okay, there we go. Completed. And here we see completed. This one is completed. Actually,

1775
02:36:26,188 --> 02:36:30,268
this one from Marcus, it has been completed. And then there are some more requests here.

1776
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

1777
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.

1778
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

1779
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

1780
02:36:54,488 --> 02:37:01,828
ask Codex to do would be something like suggest top five high impact, low effort features,

1781
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

1782
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,

1783
02:37:13,448 --> 02:37:19,848
top five high impact, low effort next features I'd prioritize. Functional marketplace search,

1784
02:37:20,048 --> 02:37:25,208
booking detail view, customer cancel pending request, et cetera, et cetera. And if you don't

1785
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

1786
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

1787
02:37:42,068 --> 02:37:47,368
I have a constantly evolving list of things that I can build in the future.

1788
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.

1789
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.

1790
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.

1791
02:38:04,428 --> 02:38:06,528
And now we can open this file and take a look.

1792
02:38:06,588 --> 02:38:08,828
So this is priority one, two, three, four, five.

1793
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.

1794
02:38:16,128 --> 02:38:19,948
This workflow, this main workflow works as expected.

1795
02:38:20,068 --> 02:38:24,328
But of course, there's so many things that you can do to improve this app.

1796
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

1797
02:38:30,328 --> 02:38:35,428
that you can use to make your apps even better and more robust.

1798
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

1799
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

1800
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

1801
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

1802
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

1803
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

1804
02:39:09,908 --> 02:39:15,008
like this video, leave a comment, and check out our amazing Patreon community.