| 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 |
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..