쉐도잉 연습: 8 Tech Choices to Lock In Before Agentmaxxing - YouTube로 영어 말하기 배우기

Before you let 10 agents simultaneously rip through your code base,

⏸ 일시 정지

재생 속도:

321 문장

문장이 너무 짧거나 길면 Edit를 눌러 조정하세요.

Before you let 10 agents simultaneously rip through your code base,

you need to get your house in order.

Today on Syntax, we're talking about the eight things that you need to lock in before agent maxing.

And now this isn't just about AI and agencies are going to be useful in any project.

The things and choices that you need to make

and understand why you're making them before you get to actually coding or before you put the machine on the code.

My name is Scott Talinsky.

I'm a developer from Denver.

As with me, as always, is Wes Boss.

What's up, Wes?

Yes.

This is so important because I think it's made worse with agents

because it's so easy just to start ripping and making a mess.

But this is a good choice for absolutely any project is slow down for five minutes,

make some good decisions as to what a good base of

your project is going to be we're going to talk about like schemas

and validation and css methodologies component frameworks routing structure off these types of things because

if you can put a good base in place first then

the rest of your agent maxing is going to be a

lot better you're not going to absolutely make a mess and

and this is not about like make sure you decide on like a a specific validation framework

and make sure that you do x y and z

because moving laterally from these things is actually not a big deal it's very easy to do with ai

if you decide you know what i'm moving from from react to svelte like

that surprisingly is not that big of a deal anymore

but things like extremely messy database a schema that is absolutely all over the place you know tables that have been added,

flags that are unnecessary, old functionality that hasn't been cleaned up.

Those are the types of things that are going to make an absolute mess of your project.

And it's very hard to come back from that type of thing.

Whereas if you just spent,

this is not a big deal.

If you spend a couple hours at the very start of your project,

you're going to be in much better shape.

Yeah.

But Wes, I want to get started now.

I want to tell the agents to make all the decisions And then who knows what?

I think something analogous here would be,

and this is going way back to Marie Kondo.

You know, part of her whole thing was that things should have one place to exist and they should exist there.

That way, when you clean,

you always know where to put things.

And that's always stuck with me because if things have a home,

they have a place, they have a structure,

they have a system, then it's way easier

if you bring someone else into your household for them to be able to put things where they go

because there's a spot for it an agent will just like

an agent is the equivalent of somebody coming in to clean your house

and they find something on the counter

and they just like put it over here okay

and then I'm put this over here

and then they then there's stacks everywhere where they're at

because there's no system in place but

if you have a system in place sounds like my life yeah yeah if you have a system in place,

it's way easier for them.

And it's way easier for your co workers,

your actual human beings to put things in the right spot as well.

Validation can come into there and too.

So let's get started on the first one that we have here.

So the first one that we have here is your database schema.

And we're not talking about the tech here.

We're not talking about which ORM you're using or anything like that.

I would even go as far as saying when you are doing this

and you are planning the shape of your data and how it should exist,

I personally like to pseudocode that by hand where I'm essentially just writing markdown.

Here's this table.

Here's what I expect to be in this table.

Here's this table.

Here's what I expect to be in it.

And I will write that by hand because AI loves to create extraneous tables,

stuff it doesn't need.

I had a Greenfield project the other day,

Wes, and I had AI generating the schema for me.

And what it did for,

I don't know what, what reason it created essentially two user tables that are essentially very similar and then cross-referencing them.

It's not like a user and a profile.

It was like a user and a user.

And then it put in a database hook that when one user updated,

it would update the other table.

I don't know why.

It loves to create different cases of,

you know, like, oh, this is,

you want to do something that's slightly different.

Now let me scaffold out an entire thing where it's like,

no, that could probably be like,

you could have two different types,

you know, that, that row could have possibly two different things in it.

It loves to add flags to things.

It loves to not clean up after it.

And it just becomes an absolute mess.

And it's so important to think about what your data looks like.

I don't really write mine in just markdown.

I probably will go for writing TypeScript types right off the bat as to how they look,

how they're related to each other,

and then feed that into something that will scaffold out the rest of the schema database,

those types of things.

TypeScript types aren't a bad idea.

I pretty much go really low fi with it and low barrier to entry,

just getting my ideas out there.

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

TRENDING

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

☕ 커피 한 잔 사주기

ShadowingEnglish는 여러분의 지원 덕분에 100% 무료로 운영됩니다. 서버 및 AI 유지 비용이 많이 듭니다. 여러분의 커피 한 잔이 큰 힘이 됩니다! ��

PayPal로 기부하기

ShadowingEnglish.com – 영어 쉐도잉 연습

쉐도잉(Shadowing)으로 원어민처럼 영어를 말하세요. YouTube 영상을 한 문장씩 듣고 따라 말하며, 진짜 발음과 유창성을 키우세요. IELTS 학습자들이 선택한 방법.

쉐도잉 연습: 8 Tech Choices to Lock In Before Agentmaxxing - YouTube로 영어 말하기 배우기

인기 동영상

상황 및 배경

일상 커뮤니케이션을 위한 주요 5가지 표현

단계별 쉐도잉 가이드

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉 연습: 8 Tech Choices to Lock In Before Agentmaxxing - YouTube로 영어 말하기 배우기

앱 다운로드

상황 및 배경

일상 커뮤니케이션을 위한 주요 5가지 표현

단계별 쉐도잉 가이드

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법