There’s no doubt that Cursor has achieved product market fit. Developers, including myself, have spent too much time copy pasting between chat windows.
An integrated AI developer experience is the next iteration.
However, as with vim, Cursor requires developers to practise new development workflows and master new keyboard shortcuts. The docs on cursor.com are great but don’t capture how to achieve an ergonomic experience. This takes time and practise, which, between tasks and meetings is hard to spend time on. The image below summarises the situation quite well.
Most people that I’ve interacted with have experienced at least 10x efficiency by adopting Cursor. I’ve have collected their workflows, thoughts and experiences.
Note: If you are doing Java development it’s more complicated to use Cursor and you will most likely be better off using Intellij. The reason is primarily that Cursor is a Vscode fork. Cursor, like Vscode, does not have the great language server that Intellij has. I’ve been coding Kotlin lately and I’m using Fleet (yes, I’m cheap) for tests and better syntax highlighting and Cursor for code creation. If these two IDEs are not in perfect sync you might end up overwriting code you weren’t supposed to overwrite. So, unfortunately, if you are a Java dev you might be better off sticking with Intellij.
So, unfortunately, if you are a Java developer you are better off sticking with Intelli over Cursor.
Now, let’s go through some tips and tricks that I and others have gathered by using Cursor extensively over the last couple of months.
Prompts
Prompt engineering is crucial for optimizing productivity in Cursor and leveraging Large Language Models (LLMs). The goal is to guide LLMs effectively by providing sufficient context, similar to leading a detective through clues in a mystery.
We all laughed at the “prompt engineering” title last year but this seems to be a huge unlock for improved productivity in Cursor and using LLMs in general. The general idea is to lead LLMs on the right path.
Ilya (previously at OpenAI) explained very well the “predict the next work” in this interview with Jensen Huang (NVIDIA). Simply put, you should view LLMs as trying to predict the killer in a classical crime story. However, in order to do so you need to provide enough context for it to put two and two together. The same goes for prompting when coding.
The prompt should guide the model towards the ideal outcome.
A couple of weeks ago a prompt was released specifically targeting reasoning. The prompt could turn Claude Sonnet 3.5 into a legit contender against OpenAIs o1. Basically it directs the LLMs to process a task step by step at a maximum of 20 steps. At each step the model should assign a quality score. If the quality drops below a certain threshold it should stop. So basically an optimization strategy. There’s more info about the feat in this twitter thread.
Many have found success in creating longer prompts for specific tasks. These tasks could be programming in a specific language, finding a bug, working with a framework etc. A great starting point is cursor.directory. It’s a directory of various user submitted prompts that targets specific languages or frameworks. Naturally, these should be tweaked a bit for your specific need.
Integrating into Cursor
If you want to use these prompts in Cursor I would advise you to create a folder structure like this
github
cursorrules
rust
go
kotlin
debug
reasoning
...
...And when you want to use any of the rules in Cursor then in your project you should symlink the cursorrules folder in like this
ln -sf $HOME/github/cursorrules cursorrulesAnd proceed to add cursorrules to the .gitignore so you don’t bloat the project.
Alternatively, you could check in specific cursorrules that fit the project. However, this would quickly diverge with your own repo.
I believe that in the future, Cursor or prompt package directives will be used instead as it’s a better DevX.
Main functionalities
Composer
By hitting cmd+k you’ll get the small window you see below. This is where you can get Cursor to generate and apply code.
Chat
This is very familiar to the copilot chat and can be activated by hitting cmd+L. Then you get a similar modal to that on the right. Similar to the composer you can add context through using @ or commands by using /. A big difference is that the code generated here will not be applied. If you are happy with proposed changes in the chat you can pop them into the composer by hitting cmd+i
Tip: If you are starting on a new task remember to clear the chat history ny hitting / and then reset.
Tip: In chat, if you hit cmd+enter you use the entire codebase.
Review
This is more an experimental feature that is meant to review code against different branches. It is quite useful if you want to do a pull request and want to catch syntax errors. However, it’s not particularly good at catching potential logical flaws.
I’ve tried it a couple of times and find it to be quite sensitive to the prompt. You will need to specify what kind of bugs you are looking forward to and maybe even highlight areas of the code that might be error prone. Also you can not pick a model.
You can basically achieve the same functionality by using the regular chat and hitting @ git, your prompt and choosing say o1 which is very good at reasoning.
Tab
This is basically the famous Copilot tab that we have in our muscle memory by now. I would argue that Cursor’s tab is a little better than copilot.
Model choice
There are new models, open source and closed source, popping up all the time. However, Cursor have limited themself to models from Anthropic and OpenAI. At the time of this writing Sonnet 3.5 and o1 are considered the top tier models to be used in Cursor. As with any model, context is king. And Cursor can actually assist you in building great context. As mentioned earlier you can @ to add specific files, / for commands such as /web, /<folder> and of course Cursor includes your chat history.
At the time of this writing Sonnet 3.5 and o1 are considered the top tier models to be used in Cursor
OpenAI o1 mini
o1 mini is widely used as a planning model. It’s slower but its output is more structured and often more on point. So in the planning phase of a task o1 mini is recommended.
Sonnet 3.5
Sonnet 3.5 is brilliant if you want to make code changes. It’s fast and most of the time correct. A tip is to, in the prompt, provide information about your current language version and packages. This is so that you don’t use old documentation and methods that might be deprecated.
Commands
Recently, ian shared these shortcuts on X
As you can see there’s a lot of shortcuts. However you can get really really far by knowing a subset of these.
Personally, my most used commands are
- cmd+k: composer
- cmd+L : chat
- cmd+i : in chat: pop chats message into composer. This is especially useful when you
- cmd+/ : switch between models
- @ web : to use up to date information
Workflow
Formulate idea to be solved
Now we can finally put all the shortcuts, modes and models together into a productive workflow. Say you receive a task like
Implement an endpoint /olaf that returns all users that have Olaf as their surname.
Select the right framework
Say you had to use a new framework to accomplish the task, but you’re not sure which. You have an idea of how to weigh the pros and cons of a framework but not the time to read docs. This would be a perfect opportunity to use the chat. To get into the chat, hit cmd+L. When you’re there, select the o1 mini model and hit @ web to get the up to date information. If you have a specific cursorrule for your environment make sure to at (@ ) that in. Finally, write a short prompt like: “I need to implement an API endpoint for my application. I want simple syntax and the framework should be industry standard”. Great, hit cmd+enter to use the whole codebase. As mentioned earlier o1 will be slow but it’s worth the wait. Now dig into the chat to find what’s best for you.
Select the right database
Similar to selecting the optimal framework, you can prompt your way to the optimal database.
Compose the solution
If you’re happy with what o1 mini has come up with, move the chat into the composer using cmd+i. Finally, you can tell the composer to apply the latest suggestion together what your goal is. It could be something like this: “I want to create an endpoint /olaf that queries my database for users with firstname Olaf. Please apply your previous suggestions to solve this. If not already implemented, create a database client with methods to achieve this.” For this you could use o1 mini.
Evaluate the output
When the code generation is finished you can select save all in order to test the changes. If you’re happy with the changes then choose Select all from the compose modal.
If you need dependencies like a local database then both Sonnet 3.5 and o1 mini are great at creating necessary dockerfiles and docker compose files. Just make sure that you select the right version of your dependencies. Sonnet 3.5 can be more conservative when it comes to using newer versions of postgresql for example.
Test for consistency
Creating tests is easier than ever when using Cursor. However, if you are used to writing tests a specific way then it’s wise to include that in the context, either through a cursorrule or in the prompt itself. I have also noticed that it helps to be very specific of what you want to test by at (@ ) files with methods that you want to test. It’s also important to specify what kind of tests you want to have so that the models don’t set up a fragile integration test.
Search and squash bugs
From here you can really get a feel with Cursor and the underlying model. By iterating, specifying which files you’re unhappy with or coding styles you would like to avoid. A tip is to be very specific from here on out. Remember that some view Cursor as having a couple of junior developers.
Some view Cursor as having a couple of junior developers.
Cursor alternatives
Everyday new alternatives to Cursor pops up. Some might target a specific type of developer, Aider targets terminal users while Zed have created an blazingly fast IDE built in Rust with some smart AI capabilities. Now, what sets Cursor apart is the ergonomic developer experience. It’s easy to get up and running with, but it also allows you to improve your workflow through shortcuts and new features.
Here are some ideas by Imrat on the development in the AI coding buddy space. Checkout the comments of the post to learn more about what is brewing.
Conclusion
The post is not meant to just get you up and running, but rather show you a small glimpse of the future.
Now, close your eyes and imagine a cool product that would make your day better. Found it? Great. Now use this post to set up your environment and formulate your idea. Let o1 mini plan it out and Sonnet 3.5 execute it. Run it. Still not an MVP. Iterate, iterate, iterate. Ask Sonnet to set up a Stripe integration, ask o1 to debug. Try v0 for frontend development in react. Let Sonnet create your dockerfile. Ask o1 to explain how to deploy it on digitalocean. In a couple of hours or days you have launched a product. Congratulations, you are wielding the best tool man has ever created.
Thank you so much for taking your time reading through my post. It’s based on feedback I’ve received in the past on popular posts such as
Have you tried using Cursor? Share your experiences in the comments below or connect with me on on X or Github.
If you found this post helpful, please leave a clap, follow me for more content, and share your thoughts in the comments. Your feedback helps me create better content tailored to your needs!
Refrences
- Twitter/X content by ian: https://x.com/shaoruu
- Twitter/X content by Imrat: https://x.com/imrat
- Cursor docs: https://docs.cursor.com/get-started/migrate-from-vscode
