1007: 8 Tech Choices to Lock in Before Agentmaxxing  🔗 **Source:** [1007: 8 Tech Choices to Lock in Before Agentmaxxing](https://share.snipd.com/episode/5d8c3abd-9445-4a86-a1dd-0604a97f4d68) ## Highlights - **Lock Your Database Schema Early** - Do spend a couple hours upfront to decide database shape before letting AI modify it. - Scott Tolinski writes schemas in Markdown or TypeScript types to avoid AI creating extraneous duplicate tables and flags. Transcript: Scott Tolinski 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. Wes Bos 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 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 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. ([Time 0:00:00](https://share.snipd.com/snip/4fbfc6a5-3adc-4fc7-b9fb-899183db4b40)) - **Consistency Beats Specific Tools** - Consistency matters more than the specific tool choice when working with agents. - Wes Bos emphasizes that swapping frameworks is doable, but inconsistent patterns across many styles are hard to reconcile later. Transcript: Wes Bos You're not going to absolutely make a mess. 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. ([Time 0:01:15](https://share.snipd.com/snip/13a9fa1e-00f0-4b0d-b76c-79b3cdbae479)) - **AI Created Duplicate User Tables** - Beware AI-generated schemas that add duplicated user tables and automated hooks. - Scott Tolinski recounts AI creating two nearly identical user tables and a needless update hook between them. Transcript: Scott 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 me. And what it did for, I don't know 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. Wes Bos 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 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 then feed that into something that will scaffold out the rest of the schema database those types of things type script types aren't a bad idea i pretty much go really lo-fi with it Scott Tolinski 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? ([Time 0:03:48](https://share.snipd.com/snip/1240bed4-9091-4fbb-a67e-37f954ec29b0)) - **Define TypeScript Types First** - Do lock in TypeScript types for your data and API responses before coding. - Wes Bos prefers writing TypeScript types early then using tools to scaffold schemas and generate code from those types. Transcript: Wes Bos Taking even further, the second one we had was 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 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. 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 and look at, do I want a value bot? Do I want Zod? What's the other one that we have? Something that complies to standard... 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 the library That you do choose for validation will comply with standard schema. And that's going to make it a lot easier when go to use some random library that also needs validation that they can sort of talk to each other. You're not re-implementing and getting this drift. ([Time 0:05:42](https://share.snipd.com/snip/8c91f9cd-906e-43ac-b3b4-fda57eee57f1)) - **Pick A Validation Strategy** - Choose a validation library and stick with it to prevent schema drift. - Consider Zod or libraries that support standard schema so different tools can interoperate without reimplementation. Transcript: Wes Bos I don't think we have to say much more than that. Validation implementation. 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. 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 and look at, do I want a value bot? Do I want Zod? What's the other one that we have? Something that complies to standard... 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 the library That you do choose for validation will comply with standard schema. And that's going to make it a lot easier when go to use some random library that also needs validation that they can sort of talk to each other. You're not re-implementing and getting this drift. I ([Time 0:06:06](https://share.snipd.com/snip/85b87f76-0a0d-4100-a3e0-d6983ebcec4a)) - **Plan Routing And Auth Upfront** - Map your routing and auth flow in a simple Markdown outline before building. - Scott Tolinski lists public vs private routes, login UI choices, and which routes need protection to scope work correctly. Transcript: Scott Tolinski Another thing that I think you should lock in is your general routing structure. And I mean, like, 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. But what I do is I kind of do 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 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 there would be 40 routes from the start. ([Time 0:07:18](https://share.snipd.com/snip/86fd441b-c34d-41e4-bb78-63350ee80e70)) - **Add Auth And Ownership Early** - Implement auth and access control early, ideally as one of the first features. - Wes Bos warns adding auth later causes painful migrations since user ownership ties into many tables. Transcript: Wes Bos 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. Scott Tolinski And if you want to see all of the errors in your application, you'll want to check out Sentry at sentry.io forward slash 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 it. So head on over to century.io forward slash syntax. Again, we've been using this tool for a long time and it totally rules. All right. I'm not thinking about the off 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? What exists there? Wes Bos Yeah. But when you're coding out a feature, are you implementing auth and access control from the get-go? Or are you just writing your routes in such a way where you'll eventually add it in? So when you're building out, 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? Scott Tolinski I do it one of the very first things. Wes Bos Right away. Scott Tolinski Yeah. Wes Bos I find myself being like, ah, I'll do it later. And then maybe regretting that. Scott 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 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. Because I don't want to do migrations, adding ownership to all that stuff. ([Time 0:08:38](https://share.snipd.com/snip/f16d6ada-5650-466f-a80d-d3b7c633dd68)) - **Decide CSS Methodology And Base Styles** - Lock in a CSS methodology and base styles so AI follows consistent patterns. - Wes Bos recommends using stylelint or rules in AI skills to enforce naming, classes, or utility approaches like Tailwind. Transcript: Wes 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 going to 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 gives you UI components. You're going to need like a date picker. Like we just did, go and listen to or go watch our episode where we all made our own date picker. But you probably need less and less these days with modern CSS, but you certainly will need to reach for one of these things. And if you don't really have an I, 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. 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. 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, you can totally move from one to another, but the mess that it will make if you don't have something plugged in is what we're trying to avoid here. Scott Tolinski Oh, the messes. Oh, the messes. It will make so many messes. It will 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 in 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. ([Time 0:10:52](https://share.snipd.com/snip/38d883e3-3a7a-428b-9837-45846d3b765f)) - **Pick A UI Component Framework** - Choose a UI component framework early to avoid ad-hoc component implementations. - Wes Bos suggests options like Base UI, Cloudflare's Kumo, or utility-first tools depending on whether you use Tailwind or traditional CSS. Transcript: Wes Bos How do I want to write my styles? And also having like your base styles in place as well. Otherwise, it's just going to 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 gives you UI components. You're going to need like a date picker. Like we just did, go and listen to or go watch our episode where we all made our own date picker. But you probably need less and less these days with modern CSS, but you certainly will need to reach for one of these things. And if you don't really have an I, 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. 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. 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. ([Time 0:10:56](https://share.snipd.com/snip/99f4471b-8aa3-4d85-a2cd-cffc97c3240b)) - **Standardize Client Server Communication** - Decide how client and server will communicate (API, RPC, RSC, etc.) before coding. - Scott Tolinski warns AI will create mixed approaches unless you specify whether to use API endpoints, RPC, or React server components. Transcript: Wes Bos 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 shouldn't be using like RPC or should Be using React server modes, whatever it is, and getting that stuff in place. A couple examples of a base one in there in place will go a long way. Scott 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, but it's not easy to translate B, C, D, E, F to A as well. ([Time 0:13:31](https://share.snipd.com/snip/48273fcf-6ffb-4f2f-ab8f-f08e076922b1)) - **Create A Clear Folder Structure** - Create and document a clear folder structure so agents place files predictably. - Scott Tolinski recommends specifying route-based or project-based folders to avoid AI dumping components arbitrarily. Transcript: Scott Tolinski 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 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 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 Wes Bos 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 thousand at once and make some wicked, awful application. Scott 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 a changes. Adjustments are possible. Adjustments can happen. ([Time 0:15:03](https://share.snipd.com/snip/3d8ab3fb-1cd7-46ef-8823-2f0c095cd183))