シャドーイング練習: 8 Tech Choices to Lock In Before Agentmaxxing - YouTubeで英語スピーキングを学ぶ
C1
Before you let 10 agents simultaneously rip through your code base,
321 文
文が短すぎたり長すぎる場合は、Editをタップして調整してください。
1
Before you let 10 agents simultaneously rip through your code base,
2
you need to get your house in order.
3
Today on Syntax, we're talking about the eight things that you need to lock in before agent maxing.
4
And now this isn't just about AI and agencies are going to be useful in any project.
5
The things and choices that you need to make
6
and understand why you're making them before you get to actually coding or before you put the machine on the code.
7
My name is Scott Talinsky.
8
I'm a developer from Denver.
9
As with me, as always, is Wes Boss.
10
What's up, Wes?
11
Yes.
12
This is so important because I think it's made worse with agents
13
because it's so easy just to start ripping and making a mess.
14
But this is a good choice for absolutely any project is slow down for five minutes,
15
make some good decisions as to what a good base of
16
your project is going to be we're going to talk about like schemas
17
and validation and css methodologies component frameworks routing structure off these types of things because
18
if you can put a good base in place first then
19
the rest of your agent maxing is going to be a
20
lot better you're not going to absolutely make a mess and
21
and this is not about like make sure you decide on like a a specific validation framework
22
and make sure that you do x y and z
23
because moving laterally from these things is actually not a big deal it's very easy to do with ai
24
if you decide you know what i'm moving from from react to svelte like
25
that surprisingly is not that big of a deal anymore
26
but things like extremely messy database a schema that is absolutely all over the place you know tables that have been added,
27
flags that are unnecessary, old functionality that hasn't been cleaned up.
28
Those are the types of things that are going to make an absolute mess of your project.
29
And it's very hard to come back from that type of thing.
30
Whereas if you just spent,
31
this is not a big deal.
32
If you spend a couple hours at the very start of your project,
33
you're going to be in much better shape.
34
Yeah.
35
But Wes, I want to get started now.
36
I want to tell the agents to make all the decisions And then who knows what?
37
I think something analogous here would be,
38
and this is going way back to Marie Kondo.
39
You know, part of her whole thing was that things should have one place to exist and they should exist there.
40
That way, when you clean,
41
you always know where to put things.
42
And that's always stuck with me because if things have a home,
43
they have a place, they have a structure,
44
they have a system, then it's way easier
45
if you bring someone else into your household for them to be able to put things where they go
46
because there's a spot for it an agent will just like
47
an agent is the equivalent of somebody coming in to clean your house
48
and they find something on the counter
49
and they just like put it over here okay
50
and then I'm put this over here
51
and then they then there's stacks everywhere where they're at
52
because there's no system in place but
53
if you have a system in place sounds like my life yeah yeah if you have a system in place,
54
it's way easier for them.
55
And it's way easier for your co workers,
56
your actual human beings to put things in the right spot as well.
57
Validation can come into there and too.
58
So let's get started on the first one that we have here.
59
So the first one that we have here is your database schema.
60
And we're not talking about the tech here.
61
We're not talking about which ORM you're using or anything like that.
62
I would even go as far as saying when you are doing this
63
and you are planning the shape of your data and how it should exist,
64
I personally like to pseudocode that by hand where I'm essentially just writing markdown.
65
Here's this table.
66
Here's what I expect to be in this table.
67
Here's this table.
68
Here's what I expect to be in it.
69
And I will write that by hand because AI loves to create extraneous tables,
70
stuff it doesn't need.
71
I had a Greenfield project the other day,
72
Wes, and I had AI generating the schema for me.
73
And what it did for,
74
I don't know what, what reason it created essentially two user tables that are essentially very similar and then cross-referencing them.
75
It's not like a user and a profile.
76
It was like a user and a user.
77
And then it put in a database hook that when one user updated,
78
it would update the other table.
79
I don't know why.
80
It loves to create different cases of,
81
you know, like, oh, this is,
82
you want to do something that's slightly different.
83
Now let me scaffold out an entire thing where it's like,
84
no, that could probably be like,
85
you could have two different types,
86
you know, that, that row could have possibly two different things in it.
87
It loves to add flags to things.
88
It loves to not clean up after it.
89
And it just becomes an absolute mess.
90
And it's so important to think about what your data looks like.
91
I don't really write mine in just markdown.
92
I probably will go for writing TypeScript types right off the bat as to how they look,
93
how they're related to each other,
94
and then feed that into something that will scaffold out the rest of the schema database,
95
those types of things.
96
TypeScript types aren't a bad idea.
97
I pretty much go really low fi with it and low barrier to entry,
98
just getting my ideas out there.
99
And then again, you could tell AI,
100
like, what am I missing here?
101
But instead of just saying AI,
102
go write it all for me.
103
You can say, Hey, is there anything I haven't considered here or whatever?
104
You can go back
105
and forth with it rather than having it add a bunch
106
of extraneous stuff to get an idea of what you might
107
have not thought of in regards to creating these these data
108
shapes taking even further the second one we had was just
109
like like types for all of your typescript types not to say
110
that you have to manually write all of these things
111
but just sort of getting them all in order as to what it will look like a big part of
112
that is going to be what your actual data looks like
113
but another part of
114
that might just be what your api endpoints are returning what the data looks like in the client all
115
that type of stuff just getting it locked in i don't think we have to say much more than that
116
So validation implementation.
117
This one might dip a little bit more into like what library are you going to be using?
118
Because the actual validation step is often involved in so much of it, right?
119
It's going to be involved before you save the data.
120
It's going to be involved client side.
121
You're going to be doing it on the server.
122
And very good validation will help your agent write the code that is what you actually want.
123
So I would take a second look at do I want value bot?
124
Do I want Zod?
125
What's the other one that we have?
126
Something that complies to standards archetype,
127
something that complies to standard schema.
128
If you go back and listen to the show we did on standard schema,
129
it's not really something you as the end user needs to know about what standard schema is.
130
But knowing that one of your the library that you do choose for validation will will comply with standard schema.
131
And that's going to make it a lot easier
132
when you go to use some random library that also needs validation
133
that they can sort of talk to each other you're not re-implementing
134
and getting this drift i think validation can be a bit lower on on the totem pole here
135
but definitely something that you should have locked in another thing
136
that i think you should lock in is your general routing structure
137
and i mean like when when you're thinking about your generalized routing structure,
138
I don't necessarily mean the exact folders that you'll be creating in your next JS app.
139
I'm more or less writing an outline,
140
oftentimes in a bulleted list in Markdown.
141
See, me, Wes, it seems like your plans lean more towards TypeScript or code,
142
and my plans lean pretty hard on Markdown.
143
But what I do is I kind of do an ordered list
144
or an unordered list of here are the general routes that I should be having,
145
because you can kind of really get a scope for work.
146
You can get a scope for how many spots there are that things are going to go.
147
You can have an idea of what routes need to be protected,
148
what routes need to be private,
149
which ones need to be public,
150
and what actually exists in there.
151
I'm kind of an optimist in so many ways.
152
So when I think about,
153
Ooh, I'm going to create this project.
154
And then the next thing you know,
155
it's like, how the hell did I get 40 routes in this thing?
156
It's like, well, if I would have thought about it for two seconds,
157
I would have realized there would be 40 routes from the start.
158
Right.
159
Yeah.
160
So when you're building something,
161
then you're thinking of like auth from the get go.
162
I often find myself in the opposite where I'm just like,
163
I don't feel like fussing with auth right now.
164
And if you want to see all of the errors in your application,
165
you'll want to check out Sentry at Sentry.io forward slash syntax.
166
You don't want a production application out there that,
167
well, you have no visibility into in case something is blowing up and you might not even know it.
168
So head on over to Sentry.io forward slash syntax.
169
Again, we've been using this tool for a long time and it totally rules.
170
All right.
171
I'm not thinking about the off tech.
172
I'm thinking about public private.
173
If especially if there's going to be users, do I need accounts?
174
If I need accounts, what can the users do?
175
Is there a landing page?
176
Is there this or is there that?
177
Are they is there going to be a login page or a login modal?
178
Like I think about those types of things when I think about auth rather than the tech behind it.
179
But I do think about mostly in the routing structure.
180
What is private protected?
181
Whatever is this?
182
Are there going to be admin routes?
183
Are there going to be user routes?
184
Like what exists there?
185
Yeah.
186
But like when you're coding out a feature,
187
are you implementing like auth and access control from the get-go?
188
Or are you just writing your routes in such a way where you'll eventually add it in?
189
So when you're building out,
190
like let's say you've got all the stuff we're talking about in place and you go to write your first feature,
191
is one of those first features or one of the first functionality,
192
is that auth and access control already implemented?
193
Or do you leave that until a later point?
194
I do it one of the very first things.
195
Right away.
196
Yeah.
197
I find myself being like,
198
ah, I'll do it later.
199
And then maybe regretting that.
200
Yeah.
201
Well, if it's an app that has users,
202
which let's face it, whose apps actually have users anyway.
203
If it's an app that has users,
204
that user data is almost tied into every single table in your database, right?
205
There's ownership over most data in your database.
206
And in that regard, the auth has to be in place and the data has to be in place before I start.
207
Because I don't want to do migrations,
208
adding ownership to all that stuff.
209
That sounds like a nightmare.
210
Next two we'll talk about together,
211
and that is the CSS methodology.
212
How do I want to write my styles?
213
And also having like your base styles in place as well.
214
Otherwise, it's just going to,
215
it starts to look like a vibe-coded app that everybody else has.
216
And the other one is like the UI component framework.
217
I think regardless of which way you go,
218
at some point you're going to need something that gives you UI components.
219
You're going to need like a date picker,
220
like we just did, go and listen to or go watch our episode where we all made our own date picker.
221
But you probably need less and less these days with modern CSS,
222
but you certainly will need to reach for one of these things.
223
And if you don't really have an I,
224
you say, maybe I'm going to grab chat CN,
225
maybe I'm going to grab base UI.
226
What's the one?
227
Cloudflare has kind of a nice one.
228
Kumo is the Cloudflare one.
229
That one looks pretty good.
230
It's built on base UI.
231
That's another nice one that you can go ahead and grab.
232
A lot of this is going to depend on are you doing Tailwind?
233
Are you doing traditional CSS?
234
You know, all of the different methodologies,
235
getting that stuff locked in early on.
236
Again, you can totally move from one to another,
237
but the mess that it will make if you don't have something plugged in is what we're trying to avoid here.
238
Oh, the messes.
239
Oh, the messes.
240
It will make so many messes.
241
It'll put CSS and all kinds.
242
It will use different types of naming structures.
243
It will make some things classes and other things components.
244
Oh, yes.
245
You need rules.
246
You need structure.
247
You need methodology.
248
And you need to have a good understanding.
249
Like, obviously, many of the things that we're talking about are decisions that need to be made.
250
And if you're working with AI coding,
251
These decisions need to be fed to your AI so
252
that it knows and understands that these decisions exist in your agents and your rules files and your skills,
253
wherever you're putting these things,
254
your AI needs to understand,
255
hey, in this project, we do CSS like this.
256
And if you're not doing CSS like this, then you're wrong.
257
You can put in linting systems like style lint or anything like
258
that in the CSS capacity to help your agents follow these rules.
259
But whatever those rules are,
260
and that component system you are using,
261
you need to make sure that that decision is adhered to for good results in my mind.
262
Something that is consistent.
263
It doesn't matter what it is.
264
Like you said, like you can move.
265
If it is consistent, it makes migrating to something else at a later point so much easier.
266
Next one I have here is the client server communication or comms.
267
Basically, how does the client,
268
which is often your browser or your app,
269
communicate with your end server?
270
Are you doing that over API endpoints?
271
Are you doing that over RPC?
272
Are you doing that over like function calling, React server components?
273
That's another thing that I often get a couple hours into a project and I go,
274
damn it, like I didn't even realize it was using API endpoints,
275
whereas it should be using like RPC or should be using React cervical modes,
276
whatever it is, and getting that stuff in place.
277
A couple examples of a base one in there in place will go a long way.
278
Yeah, I think, again, this is one of those things that if you don't have this decision in place,
279
AI specifically will do this in all kinds of ways.
280
You could even say, hey,
281
we're using like this client library,
282
and AI will still make an API route to do some calls there.
283
So having those decisions firm up how exactly you're doing this is important to have locked in before you start.
284
Because again, the big message through any of this is not
285
that it's impossible to change or to swap or to do any of that stuff.
286
It's that it's much harder to do that if things are in eight different styles.
287
It's easy to translate A to B,
288
but it's not easy to translate B,
289
C, D, E, F to A as well.
290
It's way more difficult if you have 800 different ways of doing things.
291
Another thing I think is really important here that goes along with the keeping your house in order
292
and with that Marie Kondo reference I was talking about earlier is just in general folder structure.
293
Where are you putting your stuff?
294
what is the folder name that you're putting your components in and what does that look like?
295
Because otherwise, AI will dump all of your components into one single folder or many folders,
296
or they'll put them wherever the hell it wants.
297
So having an actual structure and explanation about where things go,
298
is it project-based folders?
299
Is it route-based folders?
300
What is the folder structure for this and how does that work?
301
And if you don't know,
302
you can certainly look at other projects or simply just ask the AI,
303
what is a good structure that should be used here?
304
And I think the main thing here,
305
and we're wrapping this up now,
306
is that the consistency is key for these types of things.
307
Lock them in early.
308
And then once you've got these choices,
309
you can rip, you can agent max,
310
run them a thousand at once and make some wicked, awful application.
311
Yeah, you get better results if you have your,
312
like you said, consistency is key and also don't be afraid to switch
313
if things aren't working
314
or you need to make a changes adjustments are possible adjustments can happen don't lock in your lock-in
315
but spend the time before you let this stuff right through your code base spend the actual time making sure
316
that there are places for things to go and
317
that things have a home and that you know what stuff
318
or at least the ai knows where stuff is going all
319
right that's all we got for you today thanks for tuning
320
in let us know down below what you think you should be adding to this list
321
and we'll catch you in the next one peace
アプリをダウンロード
話したすべての文をAIが採点
TRENDING
人気動画
このレッスンについて
このレッスンでは、ソフトウェア開発のプロジェクトにおいて事前に決めておくべき重要な選択や概念について学びます。特に、エージェントが同時に複数のタスクを実行する前に、整理整頓されたコードベースを持つことの重要性や、プロジェクトを成功に導くための基盤作りについて理解を深めます。このレッスンを通じて、YouTubeで英語学習やIELTSスピーキング対策に役立つ英語スピーキング練習ができます。
重要な語彙とフレーズ
- エージェント - ソフトウェアの機能を実行するプログラムやスクリプト
- コードベース - プログラムのソースコードの全体
- プロジェクトの基盤 - プロジェクトの設計や基本構造
- スキーマ - データベースの設計を定義する構造
- バリデーション - データの正確性を確認するプロセス
- CSSメソッド論 - スタイルシートの設計方法に関するガイドライン
- ルーティング構造 - ウェブアプリケーションでのURLパスの管理方法
- シャドースピーキング - リスニングの後に音声を追従する練習法
練習のコツ
このレッスンのスピードとトーンに合わせたシャドースピーキングのアプローチをお勧めします。まず、動画を何度も視聴し、話されているフレーズや言葉を耳でしっかりと聞き取ることに集中してください。その後、セクションごとに一時停止し、話し手の発音やリズムに合わせて声に出して繰り返しましょう。このシャドースピークの練習により、英語スピーキング練習が自然に行え、自信を持って話せるようになります。また、最初はゆっくりとしたスピードで練習し、慣れてきたら徐々にスピードを上げていくことが大切です。
シャドーイングとは？英語上達に効果的な理由
シャドーイング（Shadowing）は、もともとプロの通訳者養成プログラムで開発された言語学習法で、多言語習得者として知られるDr. Alexander Arguelles によって広く普及されました。方法はシンプルですが非常に効果的：ネイティブスピーカーの英語を聞きながら、1〜2秒の遅延で声に出してすぐに繰り返す——まるで「影（shadow）」のように話者を追いかけます。文法ドリルや受動的なリスニングと異なり、シャドーイングは脳と口の筋肉が同時にリアルタイムで英語を処理・再現することを強制します。研究により、発音精度、抑揚、リズム、連音、リスニング力、そして会話の流暢さが大幅に向上することが確認されています。IELTSスピーキング対策や自然な英語コミュニケーションを目指す方に特におすすめです。