1007: 8 Tech Choices to Lock In Before Agentmaxxing

Wes and Scott talk about the foundational decisions that make AI-assisted coding actually work—database schemas, validation, routing, CSS structure, and more. They explore why consistency matters more than specific tools, and how a little upfront planning can keep agents from turning your codebase into chaos. Show Notes 00:00 Welcome to Syntax! 03:19 Planning your database schema before AI touches it 06:08 Picking a validation strategy that won’t drift 07:18 Mapping your routing structure and auth flow 08:48 Brought to you by Sentry.io 10:52 Locking in your CSS methodology and UI framework 13:31 Choosing how your client and server communicate 15:03 Creating a folder structure agents can follow 16:16 Don’t be afraid to switch up your AI setup later Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Before you let 10 agents simultaneously rip through your codebase, 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 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 Tolinski. I'm a developer from Denver. As always, it's Wes Boss. What's up, Wes?

• 0:37Wes Bos?

  Yes, this is so important because like, 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 like 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, all 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.

• 1:17Wes Bos?

  And this is not about like, make sure you decide on like 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 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.

• 2:02Wes Bos?

  If you spend a couple hours at the very start of your project, you're going to be in much better shape.

• 2:08Scott Tolinski?

  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

• 2:52Scott Tolinski?

  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.

• 3:02Wes Bos?

  Doom piles. Sounds like my life. Yeah.

• 3:05Scott Tolinski?

  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 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 pseudo code that by hand where I'm essentially just writing markdown.

• 3:48Scott Tolinski?

  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 it and it, what it did for, I don't know what, what reason, it created essentially two user tables that were 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.

• 4:25Wes Bos?

  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.

• 4:49Scott Tolinski?

  Yeah.

• 4:49Wes Bos?

  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.

• 5:12Scott Tolinski?

  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.

• 5:42Wes Bos?

  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 client side.

• 6:26Wes Bos?

  You're going to be doing it on the server. And very good validation will help your agent write the code that is what you actually want. So I would take a second look at, do I want value bot? Do I want ZOD? 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 as 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 going to 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 re-implementing and getting this drift.

• 7:11Scott Tolinski?

  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, 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 Markdown. See, me, Wes, it seems like your plans lean more towards typescript or code. And my plans lean pretty hard on Markdown.

• 7:50Scott Tolinski?

  But what I do is I kind of do a, an ordered list or an ordered 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 going to 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'm kind of an optimist in so many ways. So when I think about, oh, I'm going to 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

• 8:34Scott Tolinski?

  there would be 40 routes from the start, right?

• 8:36Wes Bos?

  Yeah. So when you're building something, then 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.

• 8:48Scott Tolinski?

  And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.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 sentry.io/syntax. Again, we've been using this tool for a long time and it totally rules. All right.

• 9:13Scott Tolinski?

  I'm not thinking about the auth tech. I'm thinking about public, private. If especially, if there's going to 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 going to 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 there going to be admin routes? Are there going to be user routes? Like, what exists there?

• 9:46Wes Bos?

  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?

• 10:16Scott Tolinski?

  I do it one of the very first things.

• 10:18Wes Bos?

  Right away.

• 10:19Scott Tolinski?

  Yeah.

• 10:20Wes Bos?

  I, I find myself. Being like, ah, I'll do it later. And then maybe you're regretting that.

• 10:26Scott Tolinski?

  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 start. Cause I don't want to do migrations, adding ownership to all that stuff. That sounds like a nightmare.

• 10:52Wes Bos?

  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 which way you go, you're at some point, you're going to need something that that gives you UI components. You're going to 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.

• 11:37Wes Bos?

  And if you don't really have an eye, you say, maybe I'm going to grab chat CN, maybe I'm going to grab base UI. What's the one? Cloudflare has a kind of a nice one. Kumho 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. A lot 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 what we're trying to avoid here.

• 12:14Scott Tolinski?

  Oh, the messes. It will make so many messes. It'll put CSS and all kinds, 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 need to have a good understanding. Like obviously, many of the things that we're talking about are decisions that need to be made. 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. And your agents and your rules files and your skills, wherever you're putting these things, your AI needs to understand, hey, in this project, we do CSS like this.

• 12:57Scott Tolinski?

  And if you're not doing CSS like this, then you're wrong. You can put in linting systems like StyleLint 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.

• 13:20Wes Bos?

  Something that is consistent. It doesn't matter what it is. 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 I 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 end server? Are you doing that over API endpoints? Are you doing that over RPC? Are you doing that over like function calling React server 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 RPC or should be using React server components, whatever it is.

• 14:05Wes Bos?

  And getting that stuff in place, a couple examples of a base one in there in place will go a long way.

• 14:12Scott Tolinski?

  Yeah, 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 and AI will still make an API route to do some calls there. So having those decisions firm up how exactly you're doing this is important to have locked in before you start. 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,

• 14:55Scott Tolinski?

  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 and that goes along with the keeping your house in order and with that Marie Kondo reference I was talking about earlier is 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...

• 15:40Scott Tolinski?

  What is the folder structure for this? And how does that work?

• 15:43Wes Bos?

  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 I think 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 1,000 at once and make some wicked awful application.

• 16:10Scott Tolinski?

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

• 16:43Wes Bos?

  All right, 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.