I was just chatting with one of our senior engineers, and he mentioned that he barely types code anymore—he just types into the agent box in Cursor.
I told him that is basically what I do these days as well (~80% of the time).
This only works well for complex tasks if you know what you are doing, so let’s get into how exactly I use Cursor and my best tips.
Using YOLO mode
One of the coolest features that people often overlook in Cursor is letting the agent write code until it verifies the code is correct beyond just lint. To do this, you need to turn on YOLO mode.
Go to settings, scroll down, and make sure you turn YOLO mode on. Don’t be scared by the name. When I first heard it, I figured I shouldn’t use it, but you absolutely should, in my opinion.When you check the box, you get a bunch more options. You can give a prompt, an allow list, and/or a deny list. Here’s my prompt for YOLO mode:
This way, if it wants to run mkdir, tsc, or check for lints directly, it can. A really cool workflow is to run tsc, and if there are any build errors at all, it’ll just go ahead and fix them. It’ll find any build errors in any file, fix them up, and iterate until the build passes. That’s awesome.
Handling complex tasks
Let’s explore how I use Cursor for more complicated things. I’m going to give it this prompt:
I like this prompt because pretty much no AI can consistently one-shot this. It can take a few iterations to figure it out.
Traditionally, you’d type this in, see some code, test it by hand, come back and say, “Oh, that’s not right,” and go back and forth. You start to feel like your job is a bit like a QA tester. That’s fine, but it’s not always fun.
That’s why people invented automated tests and test-driven development. I’m not a fan of test-driven development in general, but when it comes to AI, I actually really am. So let’s make this prompt a thousand times better, especially for non-trivial things, by adding one more line:
I didn’t have to tell Cursor anything. I didn’t have to add example context files or approve it creating a test directory. It’s going to find that from the package.json—it’s quite smart.
Watching the AI work
Here’s where it gets interesting. Cursor is creating a test file, and unlike most AI-generated code, we get some level of guarantee that the behavior of the code the AI writes is correct. If it passes these tests, it’s at least doing something right.
Now it’s writing its implementation code, and it’s going to run the tests. We’ve got six tests failed. Because I have YOLO mode on and told it it can run tests automatically, it’s iterating on the code until the tests pass. And I’m doing nothing.
You do need to babysit these things. There are plenty of times when it’s definitely just going off track. It’s super common that I have to hit stop and say, “Wait, wait, wait, you’re way off track here. Reset, recalibrate, get back on the right track.”
In my case, eventually, all tests passed!
Building on existing test suites
Another cool thing you can do is build off an existing test suite. You can say, “Let’s add a few more test cases, then make sure the code passes.”
In another project I work on, we have certain compilers and converters for Builder. I have this one converter that sometimes errors. What I do is I grab the code that couldn’t convert from our logs every few days. I paste it into Cursor and say, “Run this code and see what doesn’t compile, then write a test for that issue and then update my code until all the tests pass.”
It’s amazing. I just do that every few days, pulling in new cases. It’s a great way to improve your code’s robustness.
UI design with Cursor
Someone in the comments asked if you can make a design look good with Cursor. Unfortunately, Cursor and other LLMs are very bad at checking if a design looks right in your code.
If you’re not already familiar, you could use Builder.io (our Figma plugin) to convert designs to code. It gives you a certain level of guarantee, especially if you set up your design file a bit.
Here is my preferred design to code workflow:
Fixing TypeScript errors
Let me show you another technique I like a lot.
Let’s say I’ve been working on some code for a while, just coding away, and then I realized – ah, TypeScript issues. You run the build and hit all these errors. Here’s what you do: Just go over to Cursor and say
I end a lot of my work this way. I do a bunch of stuff, there’s lint issues or whatever, who cares. I literally just tell Cursor to fix everything.
In all projects, I usually keep a command I call “pre-PR”. It’s usually the build steps that run the fastest. It might not run the end-to-end tests that run in the CI, but I rarely break those. It might just run tsc, Prettier, and ESLint – all the fast stuff that can quickly tell me if this is going to break the CI build or not.
Then I just have Cursor run that and fix up the PR until everything passes, and it works pretty great for me, even in large and complex projects.
Debugging with logs and iterative fixing
Sometimes, when you’re dealing with a particularly tricky issue, it can be helpful to have Cursor output logs and then use those logs to fix the problem. Here’s how I do it:
Let’s say we’re still struggling with our original issue. We’ve tried a few things, but we’re not getting the results we want. Here’s what I do next:
- I tell Cursor: “Please add logs to the code to get better visibility into what is going on so we can find the fix. I’ll run the code and feed you the logs results.”
- Cursor will add logging statements to the code at key points.
- I run the code and collect the log output.
- Then I go back to Cursor and say something like, “Here’s the log output. What do you now think is causing the issue? And how do we fix it?”
- I paste the raw log output for Cursor to analyze.
This approach gives Cursor more concrete information to work with. It’s like giving it a diagnostic report of what’s happening inside the code.
From there, Cursor can propose a more targeted fix based on the actual behavior of the code, not just its static analysis.
This method is particularly useful for those hard-to-crack bugs where the issue isn’t immediately obvious from just looking at the code. It’s like having a junior developer who can quickly add logging, run the code, and then help you interpret the results.
Remember, though, that this process might take a few iterations. You might need to add more logs, or focus on different areas of the code. But it’s a powerful technique for solving complex issues with the help of AI.
Conclusion
Overall, Cursor is an incredible tool. If you’re just using autocomplete, you’re probably missing out. Try the agent features and some of the other exciting features. Build familiarity with the types of workflows that work well, what works well with the agent, and what works well for testing.
Remember, it’s about delivering a better product to customers that’ll ultimately drive more revenue for the business. Use these AI tools to help you do that more efficiently, but don’t forget the importance of your own coding skills and problem-solving abilities.