AI for Software Engineers: The Perfect Development Workflow (Palmer Wenzel of Gauntlet AI)

All right. And I believe we should be live as of now. Um, it looks like it did not connect it to the other link, but oh well. We'll go ahead and pin this other one. And um, cool. I think we are officially live. Some folks may or may not start popping in. Um. Oh, cool. We'll hide that. Awesome.

Well, uh I'm sure it'll take a minute for folks to trickle on in, but uh because we'll be able to play this back later, we'll just go ahead and kick off. Uh uh I'm Austin, uh founder of Gauntlet AI. We train engineers to use AI and uh wield all of its powers. Um, and Palmer here, uh, was one of the students in our first cohort, which started in January and ended in April. Um, and as a part of Gauntlet AI, we've been looking at all sorts of different uh, AI development workflows, how people are building stuff, how they structure everything, how they feed information to the agent they're using or the model that they're using, how they don't, how they structure everything. Um, and I think you I've probably seen hundreds and hundreds of these different workflows and I think I've asked maybe a thousand people about how they do it. Um, and I think Palmer's was probably the most impressive of all of those that I've seen. Not to put you on the spot, Palmer, but I guess that that is uh why we're here to some extent. Um, Palmer was uh an engineer in the blockchain space before he joined us and before that uh he was a professional baseball player. Is that accurate to say?

Yeah. Yeah, you can say that. Um, so we're super excited to have Palmer with us. Um, I'm gonna mostly shut up and let Polymer drive and he's going to walk us through um all sorts of stuff. So, when uh when he starts a project, when he's managing a project, how does he control it all? What does his uh workflow look like? How does he manage his context window? All that fun stuff. Um, and I will be monitoring the chats and if there's anything uh interesting, we'll pop it over to Palmer and then if we got a little time, we'll uh we'll close out with some Q&A, but uh for right now, we'll turn the time over to Palmer.

Awesome. Yeah, thanks for having me. I know we've talked about doing this uh for a while and so I'm glad glad we're making it happen. Um, yeah. So, on on the topic of this being the the most impressive workflow, it's definitely the one that's best for me, but I' I've seen a lot of others that I think are equally like very very strong. Um, so before we get into any of it, I want to stress like everyone should find their own thing that works best for them. We've seen, you know, countless people do different things in Gauntlet. Uh, and I see a new thread on Twitter every day about someone's AI workflow and I believe that they're all like really, really solid. Um, if anything, I think mine is like simplified and that's why it's been really reliable for me. So, uh, so yeah, we'll go into it. I think it I think could help a lot of people. Um, Austin, like even I know you've had me show this to a couple like hiring partners and stuff and I think a lot of this stuff is like standard gauntlet knowledge. You know, we all come out of the program thinking like, okay, this is, you know, this is very normal, but every time I show it to someone outside, they're like, oh, this is great. This is exactly what we needed. Right? So, uh, so yeah, we'll we'll get into it a little bit. Um, so yeah, I'm not the most technical person, uh, compared to some of the people we had in Gauntlet. And so this is great for me. It starts very simple. We start with like kind of the project overview and then we work our way into getting like a whole project together. Um, so I'll pull up this document that we'll get into in just a second. Um, it's the new project setup doc. Uh, Austin, do you still have the link for this, by the way? If not, I can find it on uh on GitHub, but I have this put into its own repo so that people can clone it if they'd like.

Yeah, I'll find it and check it out. Sweet. Um, before we go into these steps because I think they can be kind of boring, uh, wanted to also share like so we've got some people that are um, very very technical, right? prefer full full control over everything that they're doing. That's great. I think this is good for kind of like middle ground people to lower people, but at the same time, you can have a lot more control over these documents than just what the AI is going to spit out. So, you know, to each their own, but you know, take it all with a grain of salt. Yes. Walk us through these documents and tell us what they are and what you're doing with them. Kind of start at the top and some of those names off.

So, this is designed for like starting from complete scratch. You have only an idea of what you want to build in your project. So, it's a step-by-step essentially prompt guide where I've laid out kind of how many is this 12ish steps that you should go through to get the entire what I consider like the scaffolding put together for your project. So, we've got the project overview, which everyone should probably start with before they're writing anything. It's just your project's purpose, goals, whatever, you know, all the loose features that you're going to have. Then from there, you pop into the user flow, which kind of defines the the journey through the application. This is good for planning out your routes. This is good for kind of seeing your uh project come to life and kind of a uh you call it like navigation structure so that the AI can have a better understanding of how the different features will interact with one another. Then you get into the tech stack, which is what I would consider to be the most important document. This covers all the different things that you're actually building your project with. So all the libraries, packages, all that good stuff. The UI and theme rules I found very useful for creating like a cohesive theme throughout the project. So when you ask the AI to generate a new component, right, or a new page, giving it these theme rules and the UI rules can make sure that it's pretty close to anything else you have in the rest of your codebase without linking all the other stuff, right? So these are just kind of like some some great sources of truth for your codebase. Um, project rules for the naming conventions for the file structure. This helps the AI know exactly where it needs to place new files and folders within your directory. uh they're making progress every day on like what's included in context. Like even now, I think you guys can see my cursor window. Um, but even now in here somewhere, they've got like the ability to include your entire um maybe here your entire directory. It's been a while since I looked through it and they change it every day, but uh yeah, it's somewhere in here. You can include your whole Yeah, here we go. Full folder context, right? um kind of the ability for you to include actual like folder contents and stuff instead of just the files. But especially back in the day and even still now having this is really useful for consistent outputs. And then the phase dock uh there's a lot of rage around checklists right now. It's interesting because originally checklists were like a really hot thing and it was super useful and then the AI kind of started getting overly eager to update checklists. So I would consider them to have kind of fallen off a bit over like the last several months and then this month they've kind of picked back up where the context windows have expanded and the model capabilities have improved. So now actionable checklists are like kind of kind of hot again. So that's that's good. I like I like the check approach.

So you have all these docs. Are you just literally creating you know markdown files in the parent directory of your app and then uh or like where where does all this live?

Yeah. So, I have this docs folder. Um, I name it with an underscore just so it stays at the top of the the hierarchy. Uh, otherwise it would fall kind of down here. Like if you have a client directory, it get sandwiched or something. So, up here, I populate this with all of the documents that I've mentioned here. Uh, and then any additional documents that I want to have for my project. So, through these steps, there's instructions on where to put uh those documents. So, the AI will generate all of these for me, right? Um, so we start out with project overview. I recommend always having at least a project overview. Uh, if you don't, you know, just pop over into the window and give the the AI a rough explanation of what you're doing. But actually, for my preferred workflow, I recommend doing this outside of cursor. So use like Claude or Gemini or Chat GBT or Grock. I actually use Grock for a lot of my planning stuff. But before you start your project, you should have a document that clearly outlines what you're building. maybe very loosely like how you want to build it. You don't have to get into tech stack or anything like that. Um, but at least a highle overview, right? So that's something that I would typically include on my own. So I have like an example uh project overview in here somewhere. Yeah, here we go. So this is what one might look like. This is a very uh intentionally lean example from uh Gauntlet actually. So this is like two phases of a document. It doesn't get into the details of any features, but you could follow this entire um setup doc and you would have by the end of it a complete actionable checklist of how to build your project from top to bottom. Um, so yeah, all those all those files would go here. And to give an example, uh here's what another one of my projects looks like now that it's built out. So we have the docs folder. We have all of these. Some of these you'll recognize from the new project setup folder. Others I've added on my own. Uh, like brainlift Austin, I know you guys are talking with the gauntlet guys about that right now. Um, so that's something that I update through my projects as I go. That's essentially something that covers my personal views on what I'm building. So if I think a feature is interesting or if I think it should build be built a certain way, right? or if we have certain information that's guiding that feature like uh like at alpha school right we use learning science a lot so if I have any opinions or research on learning science that goes in my brain lift and is referenced in my workflow but um, you know, not really important right now these are the great documents to have. I also have a resources folder. This is where I keep more uh arbitrary or temporary files. So like uh I had a brain dump where I just wrote down a bunch of notes one night. I threw it in there so I could reference it if needed. Um, we had some very loose data models I defined at one point, but I don't want them treated as a full document, so I put them here. Um, so yeah.

Yeah. So, it's probably worth pointing out this structure is kind of your starter structure, but if there's more information, you'll create a new, you know, maybe it's relevant in one app and not another. You're not like, oh, this is rigid. You'll you'll add a new doc. You'll reference it wherever you need to. You kind of just you use your docs as a storage for all the rules that you or all the stuff you want AI to be able to understand at some point.

Absolutely. Um, your documents are your second brain in a sense, right? They're also your guard rails for your project. So any opinions you have about how the project should be built or any facts, right? Anything, it should be documented because otherwise the AI will have very little ability to to derive that, right? Even if it's in your files somewhere, if you don't have them organized for you to attach at will, the odds of the AI finding it at the right time, the right place, right, it's it's kind of low. Um, even all the time, right? I have these clearly defined docs, but the AI is not going to pull them on its own. Typically, you have to kind of guide it into that. So, but yeah, these are what is this? Seven, six docs and then this folder that I have in any project that I ever build. Um, I think they're absolutely essential and these have been around like this sort of recommended structure has been around since like January or earlier. Like people were starting January. That's Yeah, that's forever ago. It really It feels like forever ago because I had I had a similar workflow back in January and I think you even tweeted about this like half of it is completely different now than than the way it used to be. It it all changes so fast out here.

Cool. One thing before uh not to interrupt you too much before we get into the nitty-gritty. Um, cursor rules. Um, how does this differ from cursor rules? What do you do with cursor rules? Um, or do you use cursor rules at all?

Yeah. So, cursor rules in the the way that most people still think of it I think is like the cursor if I can type cursor rules file, right? That used to live in I think it used to live here. I don't know if people put it in root or what uh cursor themselves is actually actually announced this is like deprecated and that you should be using cursor rules. I think in part they've realized like how important these rule documents are for people. So having something more robust because if you have a cursor rules file it would be absolutely gigantic, right? And as we say in the business, context is everything. So the ability to manage these more fine grain rules is really important. So I pulled over some examples from another repo. Um, I was using Drizzle in in this other repo. And so we created some Drizzle rules for our project. Some of these are best practices from Drizzle and others are things that we defined ourselves. But stuff like this is really important, right? So I set this as an agent requested rule and then I give a description. So rules for the Drizzle OM. So anytime we're working with Drizzle, typically the agent will automatically reference this file. So anytime you have like a something specific in your text stack, maybe you need to provide more context or maybe you have personal opinions on how you want the agent to operate, these types of rules are critical. Um, and then to like I mentioned, put these in the docursor rules instead of a cursor rules uh like a monolith file. So, if you go to cursor settings, this is in the rules section. Um, down here, actually need to have this disabled, but down here, you just click add rule. Uh, you give it a name. So, test rule, and it'll open up a new markdown file or MDC file, which is markdown cursor. But yeah, as an example, um I made this GitHub CLI example doc and I use it to create issues for my codebase so that I can literally say uh at GitHub CLI example use this to raise a new issue for defining our projects color scheme. Right. Um, I actually haven't I don't even know if this computer's hooked up to GitHub, so we'll see if it works. But basically any any workflows or step-by-step instructions you want the agent to have, I would put them in here. Um, and yeah, looks like this will work great. So Oh, never mind. This thinks I'm in uh I haven't installed GitHub CLI on this, so never mind. But anyway, you should use this in your in your own repo. It works pretty well. It'll create issues, read issues, and even resolve issues. It's almost like having like a a miniature Devon in your in your codebase.

Awesome. It's going to figure out how to install GitHub for you if you let it run too long. Oh, yeah. Yeah, no, totally. I don't use this computer for coding right now, so it was a bad example.

Got it? Okay. Uh, yeah, keep on going.

Sure. Uh, on the topic of rules, user rules are also pretty important. This is one that they just recently gave us the ability to add multiple. Um, and even here they say that they recommend like a style request, a response language or a tone. Um, so this is where you should use stuff that will apply very broadly to your codebase, right? Something that is always in context. So you shouldn't have anything here that is not meant for like broad applicability. So I hate how you can't see this very easily. I'll make a new document. So, here's just an example of what I have. Right? You're an expert in Typescript, Node.js, Nex.js, Nap Router, right? This is my just standard stack for for my code bases. Um, and then I have some instructions for code style and structure. There are some great uh repositories online that have all sorts of like sample user rules. I don't remember the name of them off the top of my head, but uh I can find them maybe after this uh after this call, but they're super useful. They just kind of back on the guardrail topic, right? They help you silo your code into kind of this like structure that you would want to point where I've so like I have a senior engineer on my team and he reviews my code all the time and I always tell him like, "Oh, I'm not technical. I'm not technical." But then he's like, "Dude, your PRs are like really really clean." You know, he's like, "The code in here looks good. like it's well commented, right? And that's all because we have like or I have like these user rules that keep a very consistent structure. So, I think that's pretty critical, especially if you want to get familiar with your own code. If it's written in a different structure, every time you query the LLM, right? You're kind of just like rolling the dice on what it's going to create. It's going to be harder for you to understand your codebase. So, I think guardrails are absolutely essential if you're doing any sort of like AI first programming.

Awesome. All right, we got a question here that I think is relevant um from Dan. Are you importing and configuring your tech stack from scratch every time you start a new project or do you have dedicated boilerplate to avoid this setup of things like O every time?

So, right now I'm doing it from scratch. I would recommend boilerplate if you're creating projects that are going to have pretty like similar baselines. During gauntlet, you know, we're doing a new project every week or two. So boilerplate would have been super useful, but we had very few projects that shared the same structure as the last. So I never had a had a reason to.

Yeah, we were intentionally trying to switch it up on you, so that became harder.

Exactly. Okay, I'll I'll stop interrupting and let you let you drive.

Sure. That's a great question, though, and it is a good opportunity. I'll touch on these uh these custom modes that cursor has. Um, I don't think hardly anyone uses this, but I think they are pretty useful overall. This is Austin. You may recall I requested this feature from the cursor team when they came to us.

Yeah. So like about three months later it was released and they told me at the when I suggested it at the time they were like, "Oh, that's a pretty good idea." I don't have confirmation that that led them to develop this feature. But I like to think that it kind of got their brains working. Um, so you can add a custom mode. If you don't have this, it's in the settings uh chat maybe. And then custom mode. I looked for this the other day when we were presenting to Oh, yeah. Here we go. It's a beta feature, but it's not in the beta section. It's in the chat section. Um, you can create specific models, tools, key bindings, and instructions. Most important, in my opinion, is the instructions that are tailored to your workflow. So, as an example, I created this scaffold um mode. And let me see. Oh, I didn't copy the instructions over. Basically, it has everything in uh project over no new project setup. So, I had, you know, as I mentioned, these steps with these documents, I condensed all of this into an agent mode. So, it basically just like oneshots it. Like, if I give it this whole document, it'll go ahead and produce all of these files just from the project overview. I don't use it often because I like having I like it to be a two-way street and I'll get into that in a bit of how I like having a lot of conversations with uh with the LLM. But if you have any workflows that you want like automated, this is a really good thing to use. Like for example, I mentioned I have this GitHub CLI workflow. This might work really well as a custom mode. Um, similarly, I'll just to demo like kind of how it works. This will be uh what like a I'll just call it gather mode. So what I want it to do is I want it to like understand my codebase. So I'm going to take away edit ability and then I'm going to say uh you are not I don't know why this keeps exiting to write any code. Use tools to explore and understand the codebase and and if the user has made a change request, put together a plan for said change. Right? So, this is just this is just like a prompt, right? If you have a prompt that you use all the time, you could throw it in something like this. And it may have exited it out. Let's see. Um, you can set models for it. So like I might want to use 03 max for this because this is a planning instruction essentially. I'll call it plan. It's cleaner than gather. I always think gather like gather context but um 03 max really good thinking model, right? So we'll just pick that here. GPT4 might be good for that as well. But anyway, we could say let's get started. with our project C. What did I call this? Project overview example. Even though it's an example, please proceed with uh plan. You probably don't need to give it that much context, but basically it's, you know, as you can see, it's a custom model. It won't make a document. it'll just go and, you know, explain what it's going to do by reading the file. So, I think that's a fun feature that you should definitely play around with, especially if you're honestly maybe maybe on either side. If you're an experienced dev that has solid workflows that you want to reuse a lot, or if you're a new dev who finds someone else's workflow, try putting it in a custom model. It you might be really pleased with with the results. Um, but yeah, it'll just spit out, you know, kind of my plan here. I would prefer it markdown formatted. So, typically I'll write this to a file anyway. But, yep.

Okay, on to or back to the new project setup unless we have any any pressing questions. Austin, we good?

Uh, yeah, there's one we'll get to later, but I'll see see Carlos, but we'll stay for a minute.

Awesome. So, I'll just give a high level overview on this. Um, so you start project overview, then you go into the user flow. Again, that's kind of the user journey through the application. Then we get to the tech stack section. Um, so we tell it anything that we know we want to use. So I have, you know, TypeScript, React, Tailwind as examples here. And then for each part of the stack, I have it propose an industry standard and a popular alternative. So, this is a good way, especially for a new developer, to kind of learn what your options are. Uh, instead of industry standard and proposed alternative, you could say like industry standard and open-source alternative or, you know, anything that you might want to deviate from the industry standard. Typically, I'd recommend industry standard if you're a new developer just because the agents are going to or the LLM know the industry standards better, right? There's just more code available with that stuff to train them on. But like I know one of my friends from Gauntlet is like die hard spelt, right? Um, he would be very sad if we always just requested industry standards because the AI would always just say React, right? Oh, use React, use React. Uh, popular alternative, right? Or open source al open- source alternative would be spelt, I think, right? Spelt's open source. Um, and new developers would never discover that, right, if they're just relying on AI recommendations all the time. And I've found many new things to add to my tech stack through this approach. Um, getting like a popular or open source alternative. So would definitely recommend doing this step even if you know what you're going to build and what you want to use. Um, after that I have it update that text stack document with every best practice limitation and convention that it can think of uh for each of the technologies. This is more for my learning. It can sometimes be useful for reinforcing the model, but overall it's probably an antiattern because like the model created these in the first place, right? It's the one writing the best practices in there. So, it's probably not going to look back at the document later and find something new that that wasn't already in its knowledge base. But I really like reading through this so that I know what to look for and what to avoid. Um, stuff like that. Next is the UIUX section. Uh, so the UI rules document that's produced by this is more probably in the UX realm because it defines like here are certain like break points for our uh for our screen sizes right here are the different components that we want to adhere to. Here's kind of a a loose overview of um how we're going to set up like our component architectures. Whereas the theme guide is the one I use more which are the the colors and just the overall theming of the codebase. Right? So, like we have some examples here of minimalistic, glassorphic, neworphic. These are all different like styles that you might use. But this is really great because right off the bat you've described how you want your components to look and how you want them to be styled and colored. And so even if you're making just a hello world application, it's going to look really pretty from the start. And this is great because you can just drop it in context anytime you're building um a component and it'll automatically be formatted the way that you want your projects uh theme to be. An easy pairing with this is Shad CN because you can make your reusable components from the start, right? And theme them really nicely. But even if you're not using Chad CN, like even for mobile app development, this was great because you're creating a lot of components that are kind of independent of one another. And so if you're using like a central theme, this is great for getting it to adhere to that. Um, and then real quick, I'll go through these last two. So this is one that a couple of the cohort 2 people really seem to like. I know one of them said that this is in their opinion the most important document here. Um, I hear people talk about this every once in a while. For a long time, I've used the term an AI first codebase. So, what that means is I want to set up all my code bases to be very easily explored by the agent, right? Especially several months ago, I did not know where all my code was. I had a hard time navigating my larger code bases and I needed to really rely on the agent to find the relevant files which sometimes goes against uh naming conventions right or uh structural conventions for projects. So uh I forget what all the tools are nowadays but you know the agent has the ability to like GP your codebase and use like string matching and all sorts of exploration techniques to find relevant files folders and whatnot. So this document, this uh codebase, what is it? Codebase structure maybe uh project rules. I used to call it codebase organization and it was way too long. So I I cut it down to project rules. Um, but basically this is a nice way to make it very search optimized for the agent. So highly navigable. The code is well organized, easy to read. I keep all my files under 500 lines. That way they're easily included in context. Otherwise, it won't provide like the entire file. That cut off used to be like 250 lines and it's kind of changed over time. I don't even know that 500's a clear cut off anymore, but I like it just for the sake of keeping my files modular. Um, and then I also want to do these kind of JS doc and TS doc comment blocks above all my files, uh, functions, stuff like that because it helps me understand them as well as the agent. Uh, and then lastly, this is like the whole checklist thing. I have it, you know, this is long, so I won't go through the whole thing. I feel like I've kind of blabbed for a minute, but uh, this outlines kind of your your entire checklist from start to finish for how you're going to build the project. Really important is I have this set up to keep these phases iterative so that each one builds on itself. I want a working product through every phase of my project. through Gauntlet I used the checklist structure which this is also a checklist structure um and it'll look like this. Um, so you can see over here you've got like this is just a setup phase. So you've got like the overview and then you've got the checks and then it'll mark them when they're finished and so on and so forth. This is a pretty long one. Uh, the setup phase is always very long for my projects because I like to do everything up front. But uh, if you do it through uh, if you try and do how do I want to explain it? If you try and make your phases feature-based, sometimes you'll risk not having a usable product along the way because one feature may not work until another one's developed. So even though these are relatively feature-based, I try to separate it into the setup phase and then like an MVP phase and then like several more like expansion expansion phases on top of that. That way the thing actually works all the way through delivery. And that's pretty much the uh, the scaffolding approach of of my code bases. They all start with these steps uh that I've outlined here every single time. And it's worked really well for me.

That's awesome. All right, we'll go to Carlos's question real quick. Um, I hear a lot of hype around using the rue/client extensions to help plan and even save on tokens. Does this fit into this flow at all?

So, I don't use rue or client. Uh, even in gauntlet, I don't know that we really had anyone who did. I checked out Klein at one point. It's great. It's definitely something for saving cost. Typically for planning and stuff, I'll just take it outside of the IDE. So, I don't know how badly this is still the case, but cursor like kind of cuts down the context windows probably just to save on cost, right? They minimize the number of tokens. Um, so you're probably better off for any serious planning, take it into whatever your preferred model is, whether that's JGBT, Claude, Gemini. I think it's just cheaper that way in general. And it's also just a better context window. Like we had a guy in Gauntlet, uh, Tyler who made Tinyvec, his own like vector database, right? The dude's insanely cracked. And as opposed to using Klein, he just used VS Code and then pulled out whatever context into Claude himself. Like he would use the the I guess he had the app like the actual app for Claude. Um, but I think anytime you're trying to save costs or manage context like super effectively, do that. pull it out into into your preferred LLM, but client's great. It's a it's a good option for for anyone who wants to try it.

Cool. Um, and then yeah, kind of on that topic, it's great. I mentioned at the start to kind of find your own workflow. That was his workflow right during Gauntlet. But as with everyone in Gauntlet, he was constantly reassessing it. So like now he does use cursor because he's kind of figured out how to manage the context in the way that he likes within cursor which is great. I think he still pulls stuff into claude um if he needs to but overall it's cool to see people's like methodologies change over time. Uh, kind of on the flip side of that we had a guy uh Michael who Austin you may know as well. He was in Gauntlet. He was like an engineering only background. Had not done any programming and he was one of the best engineers to come out of Gauntlet in my opinion. And I think Ash may have told him that as well. Um, because he was dedicated to like understanding the code that the agent was producing. I think that's maybe the most beneficial thing you can do when you're relying on agents very heavily for your code is ask questions as you can and understand what it's actually doing. If you just let it write code all day, right? As soon as you hit a bug, debugging becomes very difficult. I think that's like by the end of week one in gauntlet, that's always everyone's number one question is how do you get unstuck? Uh, the best way to get unstuck is to have a little bit of understanding of your codebase yourself, right? So you can provide the correct context. Um, but I like I liked Michael's workflow a lot because he was constantly learning from the LLM. Um, and then also another example I wanted to mention is like my old boss, he uses Claude code for everything. He like does not like cursor, right? And he's incredibly experienced. Whereas I can't stand Claude code because I think Claude just in general tries to make way too many changes. So it's really really good at getting stuff done fast, but it doesn't feel as surgical to me as Gemini. But I'm over here trying to be surgical when this dude's got 20 years of coding experience and thinks that like quad code is by far the best and that there's never a reason to use cursors. So that's kind of in my opinion a testament of find what works best for you because everyone's everyone's a little bit different.

Awesome. Awesome. Um All right. Uh okay. So now we got project set up. We've got all the docs in the right place. Um, I guess first uh what when you're doing all this planning, what other outside of cursor and the tools that it has, you just use Chad Chica? what what what are your favorite models? What are your favorite workflows for that?

So, if I'm doing anything that's like my own idea, I'll typically dump it into uh Grock, which I don't think it's a super popular method. I like it because I like the conversational style of Groc. So, I feel like I get more out of it. I feel like it's more of a two-way street where it'll present information. I'll ask it a question and so we kind of like form the document as we go and then anytime I'm doing this like kind of setup step I'll have it summarize the conversation at the end and again this is super I I think a lot of people do this right have a conversation with an LLM summarize it at the end and then pull it into your project. So just copy and paste it as a document, right? So that could be that could be your PRD, that could be a project overview, that could be a brain dump, right? Whatever you want to call it. But I think all of that provides really good context for for your cursor agent, right? Um, for a lot of the stuff we do at Alpha School, I mentioned we we want to bake learning science into our into our stuff, right? So we're doing a lot of research as well. So like using different models for research is really useful. Grock deep research is good. Um, I've actually I think a lot of people don't care for perplexity but I've been using perplexity just because it's quick and simple for just like answering basic questions about learning science and whatnot. So I know a lot of people that like to take their stuff outside the IDE for for their planning phases. I think in fact uh chatbt is probably the best one if you have like the premium account. I don't so I don't really use that much but I have a friend who who works in like sales and marketing and he's been using it like non-stop for everything and he actually recent recently started using cursor and uses this workflow and he's built several applications already and uh he does all of his stuff in chatbt out anything outside of the IDE he uses chatgbt for it and I'm very impressed with the results so I think that's probably a subscription that's that's worth the money.

Awesome. And then when you're coding? So okay, we've got projects set up. Um, take us through some of like how you will include these documents or how you'll reference them as you're building. Um, and I mean just, you know, don't want to spend forever on how you actually build a full app. Maybe that's for another day. Uh, yeah, now that you've got kind of this scaffolding place of all these different docs and a good project requirements and project rules and hierarchy and user flow, then what?

Yeah. So, as I'm going, I do kind of what's very similar to what I've mentioned in these prompts, which is I'll just reference the files down here, right? I'll say, "Hey, use these files to do this task." Um, as far as like anatomy of a prompt, I don't know that that stuff's as important as it used to be. For 01, I know it was massively important where you had to structure your prompts a certain way. Typically, I'll put the files either at the start or at the end of my prompt, right? So, I guess I don't have these actual docs created in this repo, but I'll go back to the the GitHub CLI example, right? I would say like use GitHub CLI to raise a new issue for you know blank and then I would say the relevant code is in you know and then I would at reference some files here. That's really common for like kind of a one-off task that I'm trying to accomplish. However, if I'm trying to address like a larger feature, um, so I'll use the GitHub CLI example again. I use this to create uh issues in my in my like GitHub project. So, I would have it grab the issue. So, I have um let me open up the CLI example. So, I have like these instructions in here for how to view issues in the repository. So, I would say, hey, grab the issue from this. And then I'd be like, okay, let's get started. Let's get started on res resolving the issue. Pretend there's already, you know, some chat started here. And then I'll use this button to add context that's persisted throughout the entire chat. Um, the reason this matters is because I can say let's get started on the issue. I link the read me, right? And if I hit enter, you'll see that that file is no longer in context down here. So at reference a file if you want it just used for like a a single message, right? However, if you want this persisted through the entire chat, you should add it up here. So let's say we're going to do a lot of work on our readme. Oh, I kind of bugged out this chat window. Um, let's say we're doing a lot of work on our readme. I'll attach it up here and I'll say let's make some changes to the readme, right? And then you'll see it's still attached down here. So files that are commonly used for this, I would say from the new project setup would be the text stack, right? Because oftent times anytime you're making a change to your codebase, it's probably going to touch some sort of package or library. So, keeping the text stack file in permanent context is really good. Um, which we don't have it so I can't attach it here. And then the project overview is usually pretty good as well. Even though that doesn't explicitly tell the AI where any files are, I think it's still really good for helping it understand the context that it's working in of just like what your larger project is. Uh, typically if it has to call in extra files or folders, if it has some understanding of your project as a whole without having to explore your codebase in the first place, I think that'll help it find it more effectively. Obviously, it's really hard to measure some of this stuff because there's no good metrics or whatever, which is kind of where like the whole vibe coding thing comes from, right? You just kind of got to do what works for you. But attaching the tech stack in almost all cases and the project overview in almost all cases has been super useful. Um, anytime I'm making a new component, I'll attach the theme rules. Every once in a while, I'll attach the UI rules. I don't use it that much. And then if it puts a file in the wrong place, uh, that's another thing we I mentioned earlier. Always learn from the AI, right? Similarly, always review what the AI is doing. It's kind of a pain to look through all the outputs all the time, but at the very least, look at where it's putting files. Um, that's something that in Gauntlet I was surprised by how many times the AI would put the file in the wrong folder or make like a new folder for a file that we already had either a similar file or a similar folder or whatever. So, to keep your sanity, I would double check where all of that's done. And then if it's in a weird spot, just link the project rules because this is supposed to define your folder structure, file naming conventions, and whatnot. Um, typically I include like a file tree in there as well that's mentioned uh down here somewhere right here. Um, so highly recommend that. But I'll touch on this which I know you shared on Twitter. This is obviously always subject to change. This is different from what it was three months ago, but I think it's still pretty true um based on just experimentation. So this is what I've referred to as the rule inclusion hierarchy. Uh, I've, you know, we have it in this like little pyramid here. So I'll just go top to bottom and explain kind of the difference between each one. So you have your cursor mode which is effectively the system prompt, right? This is what typically cursor handles in the background. You can find the cursor uh system prompt like online. People have already like leaked it or hacked it or however you want to say it. prompt engineered it out of the model. Um, this takes precedence. If you've ever worked with uh like the OpenAI API, you'll know that like there's kind of the there's the system prompt and then there's user prompts, right? The system prompt trumps everything. All the conversations are started off with the system prompt. So, you don't really need to interact with the system prompt on your own unless you're making a custom agent. I don't think it replaces the system prompt, but I think it's attached to it. Um, but that's like number one. That'll be more important than than everything. Um, I just zoomed in. How do I zoom out? Okay, cool. There we go. Can you see this? Okay. I kind of messed with the sizing.

Yeah, I can see.

Great. All right, cool. So, then you've got user rules and cursor notepads. These seem to be on the same level. So these are always active if you put them in context and they're user selected. So well sorry I misspoke. User rules are always active. Cursor notepads are user selected uh because I've labeled these like respectively. So user rules are the ones I mentioned here in the settings. You've got the rules and then your user rules. This is like the user prompt. I think it's even attached when you send uh like a request like if you type a chat, right? This is attached as a user rule in the the hierarchy like the I think it's XML the XML that's provided to the LLM. So this has like special privilege

in there. So these are most important again, these apply very broadly to like everything that you do.

Similarly, cursor notepads are this random feature that I've hardly seen anyone use, and they're really neat because they work similarly to your docs. So like, you know, you see we have these these docs down here, the cursor rules and whatnot, but they're treated on the same level as the user rules. They have high visibility in your prompts. So one thing that I'll actually do in some of my projects is I'll say, like, uh, directory guide or something like that. And it's nice because you can at reference other files in your codebase in this document. So the notepads are a little bit special in that regard. If you were to make a normal document, uh, I'll say it's a markdown file. So referencing at docs example, right? You don't, you don't get any actual like link to that document. I don't know how cursor manages this in the background, but I can say use docs example, and it actually will reference it here. So again, I don't know how it provides that and what it looks like in the background, but it's really nice because you can tell the agent exactly where to look for certain documents. So typically I'll use this as a directory guide, and I will say, use project overview for a high-level overview of the project, right? Use user flow for navigation, use text stack for information about the complexities of the project's text stack, right? Uh, those sorts of things. And then I'll just attach it up here.

So I would say, is this count yet? Yeah. So I haven't named it. So it's just new notepad. You can rename it by going up here. Um, so you can attach that to permanent context, and it'll be treated just like your user rules in terms of importance, but you can remove and attach it at will, which is really handy in my opinion.

Uh, getting back into the hierarchy then, you have the cursor rules, which are these right here, which have replaced the cursor rules file. These can be referenced in three different ways. You can do glob patterns, you can do user selection, or you can do by request. Um, so glob patterns means short for like global, I think. But you can say, okay, I want this to be attached anytime there is a markdown cursor file. Um, this isn't actually what you would do for this because this is a RLS uh rule thing. How's it uh starsql? I need quotes or something. Anyway, not not important. Oh my god, I can't type right now. Anyway, so you can set which types of files you want this rule to be attached with. For something like the Superbase RLS policies, you can set it to attach anytime you're working with a SQL file, and RLS policies are at like stored as SQL files. So it's good to have it that way. And the agent will automatically reference these when it's making uh such files, which is super handy.

And then you've got the user selection, which means that you can just mention it yourself, right? So if you make a rule like drizzle rules, you can attach it here, and then the agent will have it in context. Or AI request, which is um right here. So you give a description of the file. So this one is guidelines for writing postgress for level security policies. And if you're lucky, when you're doing something with RLS, the agent will recognize that it's RLS and that we have documentation for that. I haven't found that to be as reliable. I typically stay away from agent requested. I either do auto-attach with the glob or I'll do manual and I just attach it myself.

Continuing with the hierarchy, you have attached. Oh, and then I also have the persisted or not persisted thing in here. I think some people asked questions about that last time I posted this. So persisted means it it'll remain in the chat context whether you're reattaching it or not. So like every time you send a new message, if I have something labeled as persisted here, it means that it's included in future messages without you having to explicitly attach it. Whereas if something is not persisted, it means that it goes away if you haven't included it again. So for example, attached files are the ones that are attached up here in the header. These will remain as attachments even in the next message, right? So they're all here again. Whereas mentioned files will not be persisted. So I'm going to say at uh where we have drizzle rules, right? It is up here, but it's not persisted. So it's going to fall down here because this is a mentioned file.

Um, this is something that is not critical to know. It really will only come into play if your chats get very, very long, or not even very long, just reasonably long, but typically you should avoid that anyway because if your chats are covering more than one feature, just make a new one. Always.

Yeah, I was going to ask how how often do you tend to create a new chat?

Yeah. So, I keep chats scoped to tasks or features. I don't go beyond that unless it's just like really cooking. Every once in a while I will do like great exploration of the codebase at the start, and so I feel like the model has really good background for what we're working on. Then I'll tackle a couple features in the same in the same chat. But typically I recommend splitting it up as much as you can. Um, so unless you have very valuable information in one chat that you want to to continue operating on, make a new one. And even then you can summarize a chat. Um, I don't know if I have enough content in any of these to summarize them. There might even I think at one point there's like a command you could use to summarize one and carry it into the next. But if a chat gets sufficiently long, um, cursor will pop up a message right here that says, you know, create a new chat, like summarize this one and include it. It'll include a summary of of the previous chat. I don't love that feature. It's the summaries are usually like pretty bad, and it'll grab a lot of context from like random parts of the chat in an attempt to summarize it. And especially if you're debugging, right? Some of the context could just be dead wrong because if you're continuing a debugging loop, typically that means that not everything's going perfectly. You literally could have changed it since then, and it's going to grab incorrect information.

Yeah. Correct. Yeah. So, I I don't use the summarize feature super often. Um, but you know, to to each their own on the

Oh, go ahead.

No. Okay. On the topic of uh like bug resolution, because a lot of people have asked me about that. Always create it. So step one, always create a new chat. You should probably Well, if the bug is related to a change that was just made, tackle it in the same chat, right? Don't don't have context for for your recent changes and then like dump them and make a new chat. If if your recent changes are relevant, keep it in the same chat. But if you're encountering a bug later in development that you missed earlier, always start with clean context, and then always start I use these custom modes now. So I'll use like the planning mode, and I'll say like, hey, gather information about what we're working on. Here's a file or two that would be useful. Um, but one essential thing is always say use tools. So if you're having the agent explore the codebase, I don't know if cursor has um some stuff in their prompt that discourages the agents from using a ton of tools because if it used them very liberally, it would cost a lot of money and people may not like that. So I think it's a little hesitant to like tool max. But if you just tell it like, "Hey, use use tools to explore the codebase." That's what I found to be the most effective for gathering context. Um, because it can

What kind of tools is that referring to?

So, cursor has like these built-in tools. Like when you build an agent, you provide it with tools, and cursor's done essentially that. So they have these like read file tools, they have, you know, edit file, they have MCP, you know, they've got all these things that your agent can plug into that enable it to be agentic, right? So one of the most frequently used tools is just the the codebase exploration set. So there's like the GP one, there's the read file one. These are things that allow it to kind of work through your codebase. And I always just encourage it to use them because I want it to use as many as possible. I want it to explore several directories, right? If if you don't tell it to use tools and you just say, "Hey, explore the codebase a little bit," it'll pick like a folder or two or maybe a few files. But if you really tell it to just go wild and just say like, "Hey, use as many tool calls as possible," it'll actually gather a lot of really useful context.

So, I've gotten in the habit of anytime I make a new chat, I always have it explore the codebase first. um to the point where I even have that in my in my user rules of you know whenever you're making a change always explore the codebase first stuff like that um but yeah these these tool calls are useful so when I'm debugging explore the codebase first and then identify the target right so wherever the bug is occurring and then do your best to supply it with as many files as you think it'll need off the rip. The agent will do its own job of gathering relevant files, but the more you can provide it with, the better because the less tool calls it needs to make. So, you save money and you tighten up the context, right? It'll work just with the files you've given it instead of pulling in a bunch of other stuff to make decisions.

Um, and then if you're really, really stuck, I think the best approach is to take it outside of the IDE. So if you've at least narrowed down the relevant files, copy all of those and pull them into Claude, right? Or pull them into Gemini or ChatGPT, and then you get the full context window. And I've seen people have a lot of success with tackling very difficult bugs just by getting out of cursor. So don't get stuck in like this like debug hell where you're going down like a super long chat and then you know, oh this didn't work, try this, this didn't work, try that. Just pull it out into a different different LLM, right?

Uh, on that topic though, there are a couple things that can help debugging a lot and to avoid future bugs. So, if I've gone down a very long chat where I've worked on a difficult bug, or if the agent keeps messing up something that that is like true for our codebase. So, so uh one example is like I use npm for my codebase. I know a lot of people like bun right now too, but the AI actually has a tendency to try to use yarn. So if I've gone through several times where it's trying to use yarn for this or yarn for that, I'll say, "Hey, we're using we're using npm like create uh a document that explains what we're using and why we're using it." So then that's how I've mentioned, you know, my docs will grow throughout a project. if I encounter like an error loop like this. And that's a basic example because it's a dependency. But if it's like a feature, you can do the same thing where if you have a feature that behaves a certain way, pull it out into a document. That way you can provide it to the LLM so it doesn't make the same mistake again. Um, that's like a critical debugging step in my opinion.

Fascinating. So if you see it making the same mistake too many times, you turn that into a doc or a rule or whatever and limit it that way. That makes a ton of sense.

Yeah, I wouldn't have thought to do that. Um, cool. Yeah. So, you you kind of eliminate these bad paths by telling the AI in advance, like, "Hey, we've gone down this path before. Don't do it again because it won't work."

Um, one last thing on debugging, if you're going down a lot of chats and let's see. So like here uh well, we haven't made any changes so there's no checkpoints to restore, but if you make changes to a file um in a prompt, up here there'll be like this little restore checkpoint option at the bottom. When you're going through a debugging phase, try expanding your chat downwards, and then if you don't reach a resolution, don't keep going down that same chat because you have all these like bad examples and bad paths previously, and the model will start to like kind of grab the wrong context. Typically, you're better off just trying to like oneshot it again from the start. Um, and you can update it with context as you want, right? If it tries something that doesn't work, just restore your checkpoint to go to a previous chat. And then you can say, okay, like we've already tried this, now try that. That's typically way more effective than continuing down a very long chat window because it just waters down your contact.

Got it. So you say, you know, okay, actually back up, undo all of that. Here's some more context. Let's try again instead of fixing what was fixed incorrectly.

Yeah, exactly. It's like version control but within within cursor, right? In the background, cursor is using its own version control to to map like the different changes it's made. So you can always revert to a previous state and then just try it again.

Awesome. I think we've taken uh more than enough of your time, Palmer. Uh thank you for uh being willing to spend some time with us and walk through all of this. Um, as you can tell, there's a lot going on. There's a lot that you can learn. There's a lot that I'm sure this will be different six months from now, and we'll have to have Palmer come back and explain what's changed with Cursor and the models and uh how everything works. But uh, yeah, thank you for your time. And if you are interested in hanging out for a few weeks with a hundred or so people that are like Palmer, you can always apply to Gauntlet AI, um, or hire from Gauntlet AI if you want uh someone like Palmer in your company. So, thank you all. Um, and we'll we'll end the end the stream. Thanks everybody. Thank you.