8 Tech Choices to Lock In Before Agentmaxxing

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 Tolinsky. I'm a developer from Denver. One thing is always is West Boss. 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 is slow down for 5 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 um CSS methodologies, component frameworks, routing structure, off the 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 a specific validation framework and make sure that you 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 spelt 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 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 uh who knows what. I I think something analogous here would be and this is going way back to Marie Condo. 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 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 I 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 uh put things in the right spot as well. Um validation can come into there in two. 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 OM 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. 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 green field 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 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 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. Yeah. And it's so important to think about what your data looks like. I don't really write mine in just markdown. I probably would 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 lowfi 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 uh 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 uh 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, uh 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. 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 zod? What's the other one that we have? Something that complies to standard arc type. 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. 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 uh 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. Oftent times in a bulleted list in markdown. 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 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. Uh, 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, uh 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 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, right? Yeah. So, when you're building something, then you're thinking of like off from the get- go. I often find myself in the opposite where I'm just like, I don't feel like fussing with Oth right now. And if you want to see all of the errors in your application, you'll want to check out Sentry at centry.io/sax. 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 centry.io/sax. io/s 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 special 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 uh is there going to be a login page or a login modal? Like I think about those types of things when I think about O 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 uh user routes? Like what exists there? Yeah. But like when you're when you're coding out a feature, are you you're implementing like O 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 off 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 anyways? Uh 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 O 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. 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 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 of which way you go you're at some point you're going to need something that that gives you UI components. Um, 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 uh 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 have really have an eye, you say maybe I'm going to grab CEN, 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. that'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. 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 uh 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 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. And if you're not doing CSS like this, then you're wrong. You can put in linting systems like styl 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 uh for good results in my mind. 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 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? Um, 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 RBC or should be using React server components whatever it is 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 uh 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 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 CDE E F to A as well. It's way more difficult if you have 800 different ways of doing things. Uh, another thing I think is really important here that goes along with the keeping your house in order and with that Marie Condo 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 what is the folder structure for this and how does that work? And like if you don't know uh you can certainly look at other projects or simply just ask the AI what is a good structure that should be used here and like 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. Uh if you have your uh like you said, consistency is key. And uh 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 codebase. Uh, 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 or at least the AI knows where stuff is going. 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. Hey.