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 agents. These are gonna 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 Tolinski. I'm a developer from Denver. As always, JS Wes Bos. What's up, Wes? Yes. This is so important because, like, I think it's it's made worse with agents because it's so easy just to start ripping and making a mess.

But this is this is a good choice for absolutely any project JS slow down for five minutes, make some good decisions as to what, like, a good base of your project is going to be. We're gonna talk about, like, schemas and validation and, CSS methodologies, component frameworks, routing structure, auth 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 a absolute mess of your project, and it's very hard to come back from that type of thing. Whereas, if you just ESLint this is not a big deal. If you spend a couple hours at the very start of your project, you're gonna be in much better shape. Yeah. But, Wes, I wanna get started now. I wanna tell the agents to make all the decisions, and then,

who knows what? I 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 had should have one place to ESLint, and they should exist there. That way, when you clean, you always know where 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 an 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 then put this over here, and then they and then there are 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 coworkers, your actual human beings to, put things in the right spot as well.

Validation can come into there in in 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 pseudo code that by hand, where I'm essentially just writing mark down. 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 I had, a greenfield project the other day, Wes, and I had AI generating the schema for me, and it what it did for I don't know what what reason. It created essentially two user tables that Wes 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, you know, like, oh, this is you wanna do something that's slightly different. Now let me scaffold out an entire thing where it's, like, Node, that could probably be, like, you could have two different types, you Node, 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 like what they how they look, how they're related to each other, and 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 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, like, what am I missing here? But instead of just saying AI, go write it all for me, you can say, hey, is there anything I haven't considered here? Or whatever you can, go back and forth with it rather than having it add a bunch of extraneous stuff to get an idea

of what you might have not thought of in regards to creating these these data shapes. Taking even further, the second one we had was just, like like, types, for all of your TypeScript types. Not to say that you have to manually write all of these things, but just sort of getting them all in order as to what it will look like. A big part of that is going to be what your actual data looks like, but another part of that might just be what your API endpoints are returning, what the data looks like in the client, all that type of stuff. Just getting it locked in. I don't think we have to say much more than that. Validation implementation. This one, this one might dip a little bit more into like, what library are you going to be using? Because the actual validation step is often involved in so much of it. Right. It's going to be involved before you save the data. It's going to be involved ESLint side. You're going to be doing it on the server and very good validation will help your agent write the code that that is what you actually want. So I would take a second look at, do I want ValueBot? Do I want Node? What's the other one that we have? Something that complies to standards archetype. Something that complies to standard schema. If you go back and listen to the show we did on standard schema, it's not really something you JS the end user needs to know about what standard schema is, but knowing that one of your the library that you do choose for validation will will comply with standard schema. And that's gonna make it a lot easier

when you go to use some random library that also needs validation that they can sort of talk to each other, and you're not reimplementing and getting this drift. I think validation can be a bit lower on on the totem pole here, but definitely something that you should have locked in. Another thing that I think you should, lock in is your general routing structure.

And, I mean, like, when you when you're thinking about your generalized routing structure, I don't necessarily mean the exact folders that you'll be creating in your Next. Js app. I'm more or less writing an outline oftentimes in a bulleted list in markdowns. See, me, Wes, it seems like your plans lean more towards TypeScript or code, and my plans lean pretty hard on markdowns.

But what I do is I kind of do a a an ordered list or an unordered list of here are the general routes that I should be having, because you can kind of really get a scope for work.

You can get a scope for how many spots there are that things are gonna go. You can have an idea of what routes need to be protected, what routes need to be private, which ones need to be public, and what actually exists in there. I I'm kind of an optimist in so many ways. So when I think about, oh, I'm gonna create this project, and then the next thing you know, it's like, how the hell did I get 40 routes in this thing? It's like, well, if I would have thought about it for two seconds, I would have realized there would be 40 routes from the start. Right? Yeah.

So Wes you're building something, you're thinking of, like, auth from the get go. I often find myself in the opposite where I'm just like, I don't feel like fussing with auth right now. And if you want to see all of the errors in your application,

you'll want to check out Sentry at century.io/syntax.

You don't want a production application out there that, well, you have no visibility into in case something is blowing up, and you might not even know it. So head on over to century.io/syntax.

Again, we've been using this tool for a long time, and it totally rules. Alright.

I'm not thinking about lost tech. I'm thinking about public private.

If special if there's gonna be users, do I need accounts? If I need accounts, what can the users do? Is there a landing page? Is there this or is there that? Are they, is there gonna be a login page or a login modal? Like, I think about those types of things when I think about auth rather than the tech behind it. But I do think about mostly in the routing structure, what is private protected, whatever. Is this are are there gonna be admin routes? Are there gonna be, user routes? Like, what exists there? Yeah. But, like, when you're when you're coding out a feature,

are you you implementing, like, auth and access control from the get go? Or are you just are you just writing your routes in such a way where you'll eventually add it in? So when when you're building out, like, let's say you've got all the stuff we're talking about in place, and you go to write your first feature. Is one of those first features or one of the first functionality, is that auth and access control already implemented, or do you leave that until a later point?

I do it. One of the very first things. Right away.

Yeah. I I find myself

being like, ah, I'll do it later. And then maybe regretting that. Yeah. Well, if it's an app that has users, which let's face it, whose apps actually have users anyway? If it's an app that has users, that that user data is almost tied into every single table in your database. Right? There's ownership over most data in your database. And in that regard, the auth has to be in place and the data has to be in place before I Scott. Because I don't wanna do migrations adding ownership to all that stuff. That sounds like a nightmare. Next two, we'll talk about together, and that is the CSS methodology.

How do I want to write my styles? And also having, like, your base styles in place as well. Otherwise, it's just gonna it starts to look like a, like, you know, a Vibe coded app that everybody else has. And the other one is like the UI component framework.

I think regardless of of which way you go, you're at some point, you're going to need something that that gives you UI components.

You're gonna need, like, a, a date picker.

Like, we just did a go and listen to our or go watch our episode where we all made our own, date picker. But, you probably need less and less these days with with modern CSS, but you certainly will need to reach for one of these things. And if you don't really have an eye, you say, maybe I'm gonna grab Scott CSS, maybe I'm gonna grab base UI. What's the one CloudFlare has a kind of a nice one. Kumo is the CloudFlare one. That one looks pretty good. It's built on base UI. That's another nice one that you can go ahead and grab. Scott of this is going to depend on, are you doing Tailwind? Are you doing traditional CSS? You know, all of the different methodologies, getting that stuff locked in early on. Again, it's you can totally move from one to another, but the mess that it will make if you don't have something

plugged in is is is what we're trying to avoid here. Oh, the messes. The messes. It will make so many messes. It'll put CSS and all kind it will use different types of naming structures. It will, make some things classes and other things components. Oh, yes. You need rules. You need structure. You need methodology, and you you need to have a a good understanding. Like, obviously, many of the things that we're talking about are decisions that need to be made. And And if you're working with AI coding, these decisions need to be fed to your AI so that it knows and understands that these decisions exist in your agents, in your rules, files, in your skills, wherever you're putting these things. Your AI needs to understand, hey. In this project, we do CSS like this. And if you're not doing CSS like this, then you're wrong. You can put in linting systems like style lint or anything like that in the CSS capacity to help your agents follow these rules. But whatever those rules are and that component system you are using, you need to make sure that that decision is adhered to,

for good results in my mind. Something that is consistent. It doesn't matter what it JS. Like you said, like, you can move. If it is consistent, it makes migrating to something else at a later point so much easier. Next one we have here is the client server communication or comms. Basically, how does the client, which is often your browser or your app, communicate with your your end server? Are you doing that over API endpoints? Are you doing that over RPC? Are you doing that over like function calling React Vercel Components? That's another thing that I often get.

A couple hours into a project and I go, damn it. Like I didn't even realize it was using API endpoints, whereas it should be using, like, RBC or should be using React Server Components, whatever it JS. And getting that stuff in place, couple examples of of a base one in there in place will go a long way. Yeah. I I think, again, this is one of those things that if you don't have this decision in place, AI specifically will do this in all kinds of ways. You could even say, hey. We're using,

like, this client library, an AI will still make an API route to do some calls there. So having those decisions firm up how exactly you're you're doing this JS important to have locked in before you Scott. Because, again, the big message through any of this is not that it's impossible to change or to swap or to do any of that stuff. It's that it's much harder to do that if things are in eight different styles.

It's easy to translate a to b, but it's not easy to translate b, c, d, e, f to a as well. It's way more difficult if you have 800 different ways of doing things.

Another thing I think is really important here that goes along with the keeping your house in order and with that Marie Kondo reference I was talking about earlier JS just in general folder structure.

Where are you putting your stuff? What is the folder name that you're putting your components in and what does that look like? Because otherwise, AI will dump all of your components into one single folder or many folders or they'll put them wherever the hell it wants. So having a actual structure and explanation about where things go. Is it project based folders? Is it route based folders? Is it what are what is the folder structure for this, and how does that work? And, like, if you don't know, you can certainly look at other projects or simply just ask the AI what is a good structure that should be used here. And

as like, I I think the the main thing here, and we're wrapping this up now, is that the consistency is key for these types of things. Lock them in early, and then once you've got these choices, you can rip, you can agent Max, run them a thousand at once and make some wicked awful application.

Yeah. You get better results, if you have your, like you said, consistency is key. And, also, don't be afraid to switch if things aren't working or you need to make a changes. Adjustments are possible. Adjustments can happen. Don't lock in your lock in, but spend the time before you let this stuff rip through your code base.

Spend the actual time making

sure that there are places for things to go and that things have a home and that you know what stuff there, or at least the AI knows where stuff is going. Alright. That's all we got for you today. Thanks for tuning in. Let us know down below what you think you should be adding to this list, and we'll catch you in the next one. Peace.