Developers Miss This Cursor Context Trick (Don’t Be One of Them)

Let's talk about context in the case of cursor. So you know what context is. You probably know that as you get up to about 50% of the context window within any given model that the quality reduces greatly. Kers has been putting out some articles recently and I want to talk about them and how to put them into use. So if you're unfamiliar with some of the folks over at Curser, you should go and follow Eric. He's one of the people that works there and we're going to go through his writing and then I'm also going to pull up a Python codebase and talk through how I put this into practice so you can see my thoughts and also critique them. So I'd love to hear from you guys because having the collective knowledge base is much larger than just me. I'm just doing my best here. So when working in cursor context is important but it's not about dumping your whole codebase in. Yep. We want to be surgical about it. Here's how to actually make it work for you. So you take your intent, you state what is true, you feed that to the model, the model does it predictions because again these are predictions they're making and then it does the thing. So at its core, context is a combination of intent and state. It's what you're trying to do plus what already exists in your codebase. The agent needs both to produce high quality results. Okay? Don't just rely on automatic context gathering. Use the at symbols. Of course, for patterns you often use, write rules as they capture reusable knowledge and help your whole team stay consistent. This is really important because if you have one way of fetching data, then you should put that somewhere. If you have one way of mutating data, you should put that somewhere. If you have one way of doing tests, you should put that somewhere as well. And then within that, you probably have different ways of doing tests. For patterns, you use it often. Yep, we just covered that. You can also extend cursor using MCP to connect external systems surface live data and give the agent more awareness. Missing context leads to hallucinations. Yes, the key is finding the right balance. So that's the high level. Let's see if it goes a little deeper because that frankly is a little too high level for me. Let's see. That's why I want to also bring up the way that I think about it. But we'll do the official docs first. So you know what a tick tokenizer is. But what is context? You have intent. You have state you use your at symbols. Sure. This is mostly just the same honestly. Self-gathering. Okay. A powerful pattern many users are adopting is letting the agent write shortlived tools that it can then run to gather more context. This is especially effective in HITL workflows where the review where you review the code before it's executed. For example, adding debugging statements to your code, running it, and letting the model inspect the output. Yes. In Python, you can do this by adding debugging statements. Of course. Of course. Yeah. So, this is too high level for me honestly. So, I want to show you the way that I think about it. So, this is a relatively new codebase and what it does, it's a product called Echo that I'm building. problem that it solves for me is doing all the work around the videos that you're watching right now. So, I like this part. I don't like the part of doing thumbnails and playing the game of YouTube because there's a lot of metadata that's involved. Probably like 20 different things that you have to do. Chapter markers. So, I want to have something that does all of that, right? Just so you guys have context. And it looks something like this on the right. Cool. And that's part of the mark coding workshop that we have in Vibe with AI, by the way, which is half off because we're launching a new platform. We're getting off school. But in this case, the way that I'm working now is I've tried all the tools. I spent the entire week last week doing one day dedicated to each tool. So, all of them. And I just come back to the basics, which is you want to be as close to the prompt as possible. I learned that from Indie Dev Dan. And then you can basically understand how these things work. So in my case, I have a little AI folder and the way that I was doing this was I essentially start out by asking a million questions about the codebase. So this because I'm much stronger in JavaScript and TypeScript and the that sort of stack, I am weaker in Python, of course. So I'm going to treat this differently. So in my case, I had an initial run where I'm doing a bunch of product requirement documents and writing a pitch first. So that's narrowing down the problem, coming up with a solution, thinking through the no- goes, the rabbit holes, all those things from shape shape up methodology, which is DHH. And then I input that into a PRD. So I'll just do at F1 and I'll put the actual initial doc within those XML tags and this will prod for more additional questions. So that's how I actually get the initial build out from going from 0 to one. Now, in this case, when I want to add new stuff, this is something I found very helpful last night for essentially redoing my back end and making it a lot more modular, a lot easier to work with, having a higher, well, a better DX. And so, I'm asking a million questions about the codebase, silly little things that someone that's a senior, even a mid-level Python dev, would know. I'm asking, how do I make it better? And I don't take it as gospel because then I'm going and I'm actually reading real people's opinions on these things. So that's the research. A lot of people forget that is the there are two letters in research and development. It's not just development. So by going and seeking other opinions and going into subreddit and seeing what they have to say and just looking things up, it gets you a better opinion, right? rather than just listening to this because if I ask three LLMs three different opinions, they're all going to be different. Then I press it on how am I going to take that or why would I take that direction? I'm comparing those model outputs and then I have it take another pass at actually building out a PRD with that prompt. That's when I'm doing what that article said where I'm passing in relative paths myself and I'm saying here's all the existing things that we have we want to improve this and what that will give me in the end is a basically a comparison of what we have now versus what we want and I'd love to hear anyone's opinion who's a big Python advocate but this is the proposed backend structure that I going for which jived with me through the context of being a Typescript dev. So in Typescript projects before this when I work with a lot of different external services I like to have a singleton for the client that's the ones one bottleneck and then each method will have its own list of the operations that I can do within it. So in the case of Google calendar, I'll have Google-cal-service.ts and that's going to handle refresh tokens and making the connection, authorizing it. And then I'll have calendar list as a directory and calendar as a directory, colors, events, keyboard shortcuts, all those things. And then all the actual operations in there. So I like to see it in my codebase as I see it on the API reference because it's very clear and then each one is very small and I know things are going to fail. It makes it easier for tests as well. So I was looking for something like that and then by asking it to give me a bunch of different opinions then I get a proposed version that I feel comfortable with and this is the one that I ended up with. So we have a bunch of different pieces in here. It it does look a little bit strange the way that it's laid out. So, let me just go back to this. But yeah, you'd have this main package where it's the video processor. Then within that, I have these domains, which is really this model structure. And I have services. I have interfaces. I have this one was strange to me, but it said I needed to have data transfer objects. I had not used those before. And then adapters. So for each service we have an adapter then the actual infrastructure and the API endpoints some utilities and then tests and scripts. So then it's essentially selling me on why this structure works right. So I have that structure and I think okay cool. Then back to how I am using this set of prompts. Then I say okay I've included these relative paths include as many so it's not like we're starting from scratch and then print the existing file tree with a before and after with the expected outputs and the expected outputs would be in my case backend prdxt. So that's the full requirements document and it's following that format that is in my prompt and then it'll give me another file which is the before and the after and then the tasks. So tasks are really important. I've been using Taskmaster, but I'm also realizing that it's filling a job that I did for a very long time and I'm very competent in it. So if I want to quickly parse tasks out of an existing PRD, I'll reach for taskmaster. But on this project, I didn't because I want to get closer to the project because I have a skill gap. And that's something important because you want to get competent. Competency is awesome. So if I'm incompetent with Python, then I need to get competent. How do you do that? You don't let it do everything for you. So in this case, I wrote out all the tasks as a first pass and then I have them go and make them better. So after that, it gives me all this stuff and I say, okay, well, take another look at the tasks and make sure that they are broken into atomic steps. Atomic is a really good word for LMS for a junior dev. Include the specified data from the original checklist such that nothing is conceptual and this list can be given to developer to implement for production. Do not write any code. If necessary, you can use pseudo. Cool. So then it'll output something that looks like this. And if we scroll down, we can see all the different steps. It had a really good idea because we were migrating from using Flask to fast API because in my architecture originally I didn't realize that Flask didn't have a lot of the features that I need and so it'll replace the additional things that I was thinking of adding which are like Firebase for real time and stuff like that. But in this case, I now have them broken out into these tasks with all of these. And it kind of does the same thing as Taskmaster, but in more detail because again, like it's not like I found with Taskmaster that it's going out, it's doing an API call and then when it comes back, it doesn't check against the code base to know where the existing stuff is. So I found this more effective and it gets super detailed. And so you can see this is what line are we at? How many lines is this? 640 lines. So a lot of to-dos. And I'm getting close to the end of it, which is great. So let's get back to this chain. So then I say, okay, now once it's given me all those lists of things to do, my context window is running up. And I know that I haven't gotten to the point where it's asking me to create a new one. But I'll say what would be a good prompt for telling enthropic an enthropic coding assistant on how to get started with this refactor. It gives me a really good prompt because it has that context. I think I have it in raycast. Yeah. So then it gave me this. I need help continuing the refactor of our video processing pipeline from a monolithic architecture to a clean hexagonal architecture. following a detailed implementation plan have several initial tasks. And so then it references all these. And so when I paste that into a new window, I'll just add the at signs for these. But I don't even have to directly because it'll just find them. And then I open that new chat. I review the answers and I ask it to update it. So this is doing a combination of my favorite things from the tools that I used this last week. It's doing a combination of some of the memory bank stuff because we have the overview as well and we have the task list, we have the tree, we have the comparisons, we have the PRD and I almost forgot, we have examples. So it also generated examples which are incredibly helpful with any prompt. So in the case of the GCS adapter, this is a nice example that I wrote. So that way when we're going to write it any adapter, it's going to know how to do it because we have an example. And I did read through this to make sure that it's legit. And so let's go back, which that's another step. You should be reading these things because you're trying to learn. And then it's just really like rinse and repeat with that. So that's where I'm at with this. After having used every single tool, I think I'll still leverage Taskmaster when I'm in Typescript. But for now, no. And every day it changes, right? Like if I look at our Discord for Vibe with AI, everyone's always trying to find the next thing, right? Oh, I used Rue. Oh, I used that. But what I find is that you end up getting frustrated because you're tool hopping so much. And I've talked about this on previous videos, but find something that works for you. And then it's case by case. So in my case, if I'm in Typescript, I'm going to use Taskmaster because I know it and I'm not trying to level up the skill gaps. But in Python, I'm not going to touch it. And if you guys are interested, then you should check out the community. It's half off right now for a limited time. actually though because we're moving off of school. We have an active Discord. We do weekly workshops and I'm definitely not the smartest person in the room in there which is just awesome. So, it's really cool having smart people in there that want to learn product and marketing and code. And that's all for today. Make sure you like the video if you like coffee. Do you guys put honey in your coffee? You know, it's an anti-inflammator anti-inflammatory man. I like the video as well and I will see you in the next one.