Stopped using Vim. Moving to cursor
I’ve stopped using Vim. Its speed of editing is trumped by Cursor fundamentally in many other ways. Cursor Cmd+L amplifies our work at least 2x at LocalOps. Here is how:
Vast majority of work we do while building something, is to read existing code, understand the context and then add more to it.
In cursor, we select a piece of code and just press CMD+L to chat and get clarity on the context. Rather than jumping across and reading files manually to understand everything.
Other majority of work goes into planning out new work in terms of how to build something, referring to standard library and other tools.
In cursor again, just command + L and ask on standard library functions/methods one at a time, in a single chat thread. And potentially ask it to generate first piece of code right here in your editor, to get you started with rest of the implementation. Without Cursor, you will have to google it, go to the docs, read on about the function, repeat the same until we get fully clarity, come back to the editor and start working.
Later, when the code you wrote doesn’t work as needed, and you don’t seem to get why, just ask. Command + L and you will get possible mistakes and options to fix them.
The time saved on context switch alone in the entire process is huge!
From our usage, I see that the accuracy of all this response Cursor gives is usually very very good. We never switch the default model set in our editor - Claude 3.5 sonnet. I’m not sure why others would switch to a specific other model. Have you found a specific model useful for a specific usecase?
What are your thoughts on CoPilot and Cursor? Are you using one of these? I’d love to hear more about your experience.
Good to hear this works for you.
Your switch has little do with changing editors and more to do with changing everything else. You frame this as moving from vim to cursor, but I read it differently.
Before, you had to read code, work to understand it, look things up, and then make changes. With any luck repeating that process in the context of a business let you develop a theory of the software [1], which describes the actual value you have to your employer. You also kept your code reading, debugging, experimenting, and testing skills honed.
Now you turn a lot of that over to an LLM (which incidentally you use embedded in a text editor). You can skip a lot of the reading and understanding, the looking things up, even the changing and refactoring. It seems like you get more coding done in less time, at the cost of understanding the code less -- not developing that theory of the code as it relates to the business. And you hone the LLM's "skills" instead of your own.
I can't say which approach will work out best over time in terms of producing quality code, maintainability, on-boarding new programmers, relating changing business requirements to code no one on the team actually wrote. A lot of code has a short lifespan and doesn't control anything critical or even very important, so it may not matter. I would consider how you might sacrifice your own skills and career growth over time, changing from a programmer in command of your tools to a reviewer of LLM-produced code.
[1] https://pages.cs.wisc.edu/~remzi/Naur.pdf
I use Command+L more than Command+K.
Command+L lets you chat and iteratively learn. Command+K generates code which I find moderately useful, at least not as useful as Command+L.
Have you had a chance at trying out cursor, inside an active commercial product codebase? Interested in hearing your review on those..