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.
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.
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.
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!
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.
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:
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.
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.
Let me show you a couple of other cool things you may or may not already know. These are really handy shortcuts in Cursor.
Command K is great for making quick changes. For example, let's say I want to make all the fonts smaller except for the main copied text. I can just select the relevant code, hit Command K, and tell Cursor what I want to change.
Command I will open up the agent. If you select some code and hit Command I, it'll put that code in the context for the agent chat. This is useful when you want to chat about or modify specific parts of your code.
The main reason to use Command K instead of Command I is that it's faster. It knows we're only working with the selected code, so it's really quick. The inline UI is kind of nice too - it's simple and feels good to use.
Command K in the terminal is another favorite of mine. I love using it to save keystrokes. For example, I can say "list my five most recent git branches" and it'll do that for me.
I don't bother memorizing complex git commands. I have more time and mental capacity to solve the things that matter most. Cursor just does what I want, and I love it.
We all know about autocomplete, but let me show you something I find sometimes unintuitive in Cursor. After using this thing for over a year, I think I've figured out how to do it right most of the time.
See that gray text? If I hit tab again, it's going to auto-complete me over there. The confusing part about Cursor is this "tab again" feature is a little different. Sometimes it completes code, sometimes it just jumps to the next suggestion. You've got to get a feel for it.
You may not know that Cursor can generate commit messages for you. I always forget about this feature, but I really should use it more often. Just go over to the source control tab and hit the little magic wand icon.
It's not always perfect (see the clip below 😅), but it can give you a good starting point for your commit messages.
Let's talk about the bug finder feature. It's pretty cool. You can access it by hitting Command Shift P and typing "bug finder".
The bug finder compares your changes to the main branch and tries to identify potential bugs you've introduced. It's not perfect, but it can catch some issues you might have missed.
For example, it might catch things like forgetting to handle zero values properly, which can bite you especially when dealing with positions in UI work.
A common question people ask is whether using AI tools like Cursor might lead to losing coding skills. It's a valid concern, but here's my take on it:
If we define coding skills as the ability to build good products in a good way with code (which is probably what most companies are hiring for), then I don't think a person needs to hand-code software all day, every day, to maintain or increase these skills.
AI can automate a lot of the basic work, which saves time and mental energy and allows you to focus on the harder problems. I can let AI, using Cursor's Composer, build out these UIs, and then when things get harder, I can jump in.
In my opinion, there's no world where you can just vibe code an entire product. I've never seen anyone do it, and I don't think anyone will ever be able to do it. These AI tools are getting better, but they're also plateauing in some areas.
We will always need to be fixing and manually implementing things in the code. If you don't know how to code at all, if you don't know how to debug, those are good skills to build. You will get stuck by coding and you'll need to unblock yourself.
I think AI helps a senior developer the most. The best thing anyone can do is learn as many development skills as they can, and let the AI help you, but you need to actually know how to work with this code.
As long as you're still working with code, you're still building coding skills. And most importantly, you're building productivity and efficiency skills. I would rather hire developers who use Cursor well than developers who refuse and hand-code everything.
I want developers who work as leanly and as efficiently as possible. I can't solve hard problems for eight hours a day, every day. But I can vibe code a UI for four hours and then work two hours on really hard problems by hand, and that gets a lot more done ultimately.
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.
That's it for my best Cursor tips. Give them a try and see how they can improve your workflow.
Introducing Visual Copilot: convert Figma designs to high quality code in a single click.
