Cursor AI Dev Best Practices Just Dropped And it’s Good! + New Features transcript

Welcome back, guys. It's 2026 and just in the last day or two, we've got some big AI development updates for you. So, the team behind Cursor AI, one of the leading AI development tools out there alongside other favorites like Claude Code, have just dropped their master guide to coding with agents along with some really exciting new product updates. I've been waiting for them to release something like this for a year or so and it doesn't disappoint.

It's pretty much a reinforcement of the principles I've been teaching on my course and here on the channel over the last 2 years. So, in this video, I'm going to save you some time and cover the important points in just a few minutes. We're going to cover some of the new releases to Cursor and some of the teased releases which include sub-agents. So, all of that is coming right up. So, they start by creating a mental model of how an agent works and this is really important and something a lot of people skip.

When you understand the basics of an agent interaction, it helps you so much more in your future workflows understanding context, tools, etc. The first concept they're talking about is understanding the agent harness. So, essentially, when we interact with a large language model like Opus or GPT, we're using our code editor, this could be Claude Code or Cursor, and then we're sending all this relevant context to the LLM.

So, this could be the code base. So, Cursor breaks it down to the chat which is the user messages and the prompts that you give. Then there's instructions and a system prompt. So, this is a unique harness that Cursor have developed for each one of the specific models that they work with. So, it's important to note that they have a different system prompt for each model because they all work in different ways. And again, that's a value in using Cursor because it allows you to use multiple different models together at the same time.

And then, of course, you've got tools. So, that might be search, grep, MCPs, anything else like that. So, you have to manage the context of all of these when you're chatting with the LLM because it has a certain amount of memory. So, the next concept that we need to understand is, of course, context. So, this isn't new to a lot of people, but working with an LLM, you have a certain amount of a context window. A lot of beginners run into problems where they keep one conversation open and continue and continue and then they worry why it's starting to degrade or they're having issues.

Essentially, as we add more information, we lose the initial information and our agent doesn't know exactly what's going on. So, if you understand the idea of managing your context, refreshing it as we'll talk about later on, you're going to be at a big advantage. Next up, they express the importance of plans and I totally agree with this. So, in Cursor, the difference between a pro and a noob really is planning. What a lot of live coders do is they just jump in and start throwing prompts in there and end up getting frustrated.

But, Cursor has a great plan mode. So, if you just select plan here, you can put in your initial prompt and it will firstly come back with some qualifying questions to make sure that it's building exactly what you want and then it produces a full-on plan. Now, it doesn't stop there. What Cursor suggests you do is you actually edit this plan, make sure that it's exactly as you need and then when you're ready, you go ahead and hit the build button.

Now, the next thing they suggest is as it progresses that you watch carefully what's happening and if it starts to go off track or go in a direction that you hadn't intended, instead of just stopping and iterating on top of that, it's often a better idea the early stage to just go back to the start, revert here using this button or if you're using Git, you can just go back a commit and then change the plan and then start again.

What happens is if you just iterate on top of a bad plan, you just get a whole lot of spaghetti code. So, use your commits, use your Git workflow to move back and forward in time. I've got a full video on Git with Cursor and Claude Code covered about 2 weeks ago. I'll link that in the description down below. If you're using Claude Code, just hit shift tab once and then you've got plan mode on. You can get exactly the same feature within Claude.

So, next up is context. So, one of the benefits of Cursor is it has strong semantic and grep search. So, you don't necessarily need to be constantly adding context. So, let's say I'm working on this particular file, what I used to do is drag that in for context. As Cursor has gotten more powerful, it will actually go and search out the relevant context for you. Now, if I'm being very specific, I will still add in a particular file, but the argument is that allowing Cursor to do the search itself means that it's covering everything and seeing the full picture before it moves forward.

You'll often see it do this little search here as you initiate a new conversation. So, keeping context in mind, when do you start a new conversation cuz you remember we're going to run out of context. So, I generally use natural breakpoints to switch the conversation. So, let's say I'm working on a particular feature here and I have finished developing that feature and it's been tested and I want to move on. I will naturally just start a new conversation at that point to refresh the context.

You can keep an eye on your context here in Cursor by just hovering over this little icon. You can also do the same in Claude Code by just typing {slash} context and it gives you this visual breakdown here. Now, if you want to keep moving forward with the same conversation, you have two different options. You can compact it or summarize it so that it basically does a summary of the conversation and then gives you a tighter context so that you can move forward or you can actually just move to a new conversation and then you can reference past conversation.

So, you can see here by just typing the at symbol, I can reference the past conversations and pull them in. Cursor have done something pretty cool recently and introduced dynamic context. So, previously in most other agents, you're dealing with static context. So, all the context is always loaded, the tool responses, chat history, everything like that all comes as one big set of context. But, now what Cursor is doing is it's saving all those different responses and context items as actual files.

So, the agent makes a decision about what elements of context it might want to pull in. It can tail a particular file, see if it's relevant relevant, and doing progressive dynamic discovery can pull in whatever it needs. And Cursor are saying this is leading to a big difference in tokens used particularly across MCP tools. Haven't fully tested it myself, but interesting stuff. Website and web app analytics are super important.

You have to know what's going on with your users. So, I found PostHog because I was frustrated with Google Analytics and I was about to build my own Cursor for analytics tool myself, but I found these guys through a recommendation and they pretty much had it nailed already. And these guys are used by some big brands. So, you can simply run this command to install it and then run the AI wizard which works really well with the likes of Cursor, Bolt, Lovable, etc.

So, once it's set up, PostHog doesn't just offer you basic analytics. It kind of does everything you need as a product manager and developer. I've got my Stripe data in there and it also even handles LLM analytics. You can set up all these different dashboards depending on what your needs are and they're super flexible. So, this is one of my favorite features. You can actually do session replays. So, this is an anonymous recording of a user interacting with my site.

My favorite part is the PostHog AI. And this is what I really wanted out of Google Analytics. Because it's got access to my Stripe, my web analytics, my product analytics, I can ask natural language questions and it's going to use SQL to make its way through all the data that I've stored to generate reports, even set up dashboards for me. It really is my go-to. If you want to find out more about PostHog, check them out with this link in the description down below.

Next up, they give their guidelines for rules. So, if you're familiar with using Claude Code or the agents.md file or the claude.md file, rules is pretty much the same thing. And what rules cover or agents.md file covers is static context for your project. So, essentially, these are the commands, the code style, the essential rules you always want to be included in your context. Now, I've seen a lot of beginners make the mistake of putting way too much information into their agents.md or their Cursor rules and it's really not necessary.

New agents and harnesses have advanced so much that a lot of this stuff is covered. I keep my rules file really clean and only as I begin to work on a project, if things start to go wrong or if I see recurring issues, I start to add them into the static context. So, I would say start with a very clean and simple agents.md or Cursor rules setup. So, just to get your head around it, rules are always applied. You can create them here in Cursor settings or in a folder here.

We have static rules and agents.md files and then we have, of course, skills which are more dynamic. And the Cursor team suggests that those are used when you want to give the agents extra capabilities. And an agent will have a list of skills that it has access to and it can choose to use those as it needs. So, let's say you had a test runner. So, when you finish a particular piece of work, you could have a hook fired here with domain knowledge which would be instructions on how to set up and run tests and those would be run for you.

Let's say you've got a recurring skill like PDF extraction, you can set that up in your Cursor folder here and have it triggered by an agent or a command. In the same way that you've got commands in Claude, you also can have commands in Cursor and those would be triggered here by just typing {slash} and here, for example, I've got my own package which is a package health check that I have set up and you also have agent review.

So sub agents are also coming soon to cursor. You can see it here in the nightly builds. So you'll be able to create your own sub agents just like you can in Claude code and I've seen evidence of those running in parallel. Now of course we've had sub agents in Claude code for quite a long time and how I actually work is I use a mixture of cursor and Claude code. Predominantly when I'm developing interface faces when I'm working on front-end apps and moving things forward I'm generally using cursor.

I really love the composer model. It moves very fast but I do like the sub agents feature in Claude code and some of its agentic abilities. So I kind of mix and match between both. So next up the suggestion is to use images for both design to code and visual debugging. So there's a couple of different ways that we can use images within cursor. So brand new just released this week is the ability to actually generate images and mock-ups directly in cursor.

So I believe it uses the nano banana or Gemini 3 API but let's say I'm in Opus 4.5 here. I can actually suggest that it generates a user interface for me. So in this case I was developing a fun little game and I asked it to develop a interface mock-up. When it comes to images something I'll often do is do a quick mock-up myself using Excalidraw or Figma or even just drawing it on paper taking a photograph of that and dropping it into cursor again.

You can use this little button down here to add image context. Use a model like Opus 4.5 or Gemini and it will help design out that interface for you. Let's say I'm having UI issues with my interface. I can also just go and take a screenshot of whatever the issue is in my app and then I can paste that into cursor or Claude code as well for reference and say hey I need to change the color of these green asteroids or whatever it is is that you're working on.

So they also talk about their common workflows. Interesting to see here they're a fan of test-driven development. I've also seen the same come from the Claude code team. Tell the agents to run the tests and confirm that they fail. Commit those tests and then what you do only then is ask the agent to write the code that passes those tests making sure it doesn't modify those tests just in order to get them passed and then commit the implementation once you're satisfied with the changes.

So if you're new to testing and you're working in React or TypeScript I'd highly recommend checking out just and then there's also play right as well. When it comes to testing and when you've actually finished doing a round of development you also have a debug mode here. Essentially debug mode you just feed in the problem or any console errors that you have and it will come up with multiple different hypotheses about how to solve that.

It adds in some logging and different things like that so it's much easier to solve the problem. So I recommend that. Also you can use bug bot. So if you're connected to GitHub and you're doing a pull request you can have cursor's bug bot actually run through the pull request to make any recommendations or check that everything is in order before it gets committed. So next we have get workflows and the team here suggests some usage of skills or commands in order to manage your pull requests and PRs.

If you want a deeper dive into PRs and working with AI development in get I've got a video on that in the description down below. One thing I use quite a bit when it comes to get is using this little button here to generate a commit message or you can just ask the agent to create a new branch and make a commit as well. I think what cursor does particularly well is the ability to run multiple different agents all at the same time.

They're kind of like an agent development environment not just an IDE. So you can see in the right hand side here I've multiple different agents running or had them running at various different times. And then what I can do is use work trees here. So if I set up a work tree I can actually set multiple different models and multiple generations of those models to work on a specific problem come up with the best outcome and then I choose the best outcome and merge that back into the main code base.

So it's kind of like an agent death match. So when I want to run multiple agents together I find this setup really useful. And then also down here I might have another instance of Claude code running and I can also split my terminal here to have maybe two or three instances of Claude code. In reality I don't spend a lot of time running multiple different agents at the same time. I've seen lots of people talk about it on Twitter but to be honest being able to manage one or two agents review their code every single time to make sure that it's not too messy and proceed forward it's enough to manage one or two agents at most for me.

Where I see you might use multiple agents is in a scenario where you've got multiple issues backed up in your repository or on GitHub and you want to assign an agent to each one of those issues. In that case you might have multiple agents running. So in a nutshell if you feel like you're not ahead of the game by having 10 agents running at the same time don't worry. I don't think it's all that necessary. So on the topic of delegating to cloud agents and having multiple agents running cursor have some recommendations there as well.

So essentially how best to work with them is to have like I said multiple issues built up bug fixes or a longer to-do list. These are all things you could send to a cloud agent. So when it comes to cloud agents in cursor you can set them up here. Basically you just connect cursor to GitHub and set up a basic environment. So if it's node.js or Python whatever whatever environment that your current app is running on and then when you create a new conversation here you can assign that as a background task and have that run and you can monitor monitor them here via your agents setup.

You can also handle remote agents via Claude code. So if you type in {slash} remote you can set up your remote environments and then if we go over to the Claude code app I can start a new session here. I can do it locally or I can create a default environment select the repository go to work and then I can actually transfer that over later on to the CLI if I want. So easy to hand them over and back. And if you're feeling super productive you can actually use the Claude app or the cursor app to start off remote sessions while you're out doing something else.

But personally when I'm doing something else I like to be doing something else. So the cursor team leaves us with some closing best practices. Number one is write specific prompts. What I would say is if you have opinions or if you have directions that you want to give please add them in. Don't be too high level don't be too vague that leaves too much room for interpretation. Next piece of advice is to iterate on your setup and that is really to start simple.

Lots of people I know starting out go and get too deep into multiple different agent workflows figuring out how to use Ralph or whatever new approach is popular. Really a lot of the wins can happen just in a simple setup following clean principles. It's how I still operate after two years of agentic development keeping it really simple and understanding the principles. So get set up and only add things in as you see you have a need for them.

So something I highly agree with is review carefully. AI code often passes a high level test. It can work. If you dive deep into it miss edge cases. It's also important for you as a developer to keep an eye on the code to keep upskilling and understand what's going on otherwise your skills will start to atrophy. If you're new to this and you're not even a coder it's important to start to learn how the code works. Next up they're suggesting you do your best to be deterministic and that means that we use typed language like TypeScript or we configure our linters we're writing tests we're writing deterministic code to make sure that the code being generated is being checked as many different ways as possible and it's verifiable.

And lastly treat agents as collaborators. So agents are super smart but you are the human and you are the person that is building this project and knows exactly what way it wants to go. So that's why we ask for a plan we verify the plan we edit the plan we request explanations about things. I'll often use a prompt give me three different alternatives ways that we could run this and also your recommendation. And then push back on any approaches you don't like.

If it feels like it's not a good fit they're using the wrong library don't be afraid to mention that back to your LLM. This really is AI development without the hype and nonsense and some really clean principles you need to grasp. And it's a reminder for all us builders to stop getting distracted by shiny workflows new tools and stick to the basics to get the biggest rewards.