That was a long preamble to this question: any senior devs out there (20+ years) who enjoy using Cursor? What’s the trick?
I started programming professionally around java 1.3, and the greybeards around that time were talking about how they had moved to OOP. Most disliked it but the people who didn't adapt got stuck in dead ends. (Stay in a dead end long enough and it becomes lucrative - see Oracle DBAs and COBOL developers - if you can stay there long enough!)
You absolutely have to treat coding with LLMs as a new skill. It's just like learning a new editor to the same precision that you know Emacs or Vim. It's learning the rough edges - and the rough edges keep changing. As a senior, it's frustrating! However, as I learn more, I learn the necessary concepts to utilize what is good and try the frustrating part in a month or two when it has gotten better and so have I.
I've spent a career reading others' code, so that doesn't bother me.
Now, I prompt through TDD for code that matters and that has helped stop many of the problems I see others face. It's a little slower as an iteration loop but it generates the test data well, it allows me to make sure I understand the problem and the prompt, and it forces the changes to be small, which increases success.
If I have to make a non-trivial change to the code, I know it will try to rewrite it if I don't start a new agent session. So, I'm liberal with creating new sessions.
It is much better at small problems than large problems, which makes me cognizant to keep my problems small. Not only is that good for the LLM, it's good for the codebase.
In some cases, it's better to have the LLM create a script to make the change than try and have it go through the code with a prompt. It's very good at simple scripts.
And I'm not afraid to discard it when it's not valuable at the moment.
But the keyword here is "simple and concrete". I do not understand why people expect those tools to be good at tasks that involve having years of context on something. It really makes you think that the people that say that AI will replace SWEs have never actually used any of these tools.
Then paste that output into Cursor with Claude 3.7 and have it make the actual code changes and ask it to build/fix errors along the way with yolo mode enabled.
The 2-step process is a lot better since Grok can refer to the entire context of your codebase in one shot and come up with a high quality implementation plan, which is then handed off to Cursor to autonomously make the code changes.
Mostly you have to guide it a lot in verbose, planning methodology, often chained via other LLMs. It is like working with a junior developer - no doubt about that. But that's still really good for $20/month.
Coding is not my full time job and it really hasn't been more than 20 hrs/week since my time in FAANG; I do a lot of statistical work, IT, and other stuff too. Maybe that's why I like the mercurial help of Cursor since I am not using it 50 hours/week.
Cursor is magic. Two massive use-cases for me:
1. Autocompletion of a copied function.
So I have some function, modX(paramX), and I need to duplicate it to modY(paramY). They're near enough the same. I love that I can copy/paste it, rename a variable or two, and Cursor then intuits what I need. Tab tab tabbity-tab later, job done. This might not be the most amazing use of AI but is sure as shit helps my RSI.
(I know I should abstract my functions yada yada.)
2. Generation of a new function where I have no idea how to start.
I tell the prompt what I need. "I'll give you a bunch of Markdown files and I'd like you to take the frontmatter properties and put them on an object then take each of the headers and its following content and put that in to this property on the object".
It'll do that, to 90%. I'll fix the 10%, making sure that I understand what it's created for me.
This would have taken me 4 hours. With Cursor it takes 15 minutes.
In my experience, the solution to low traction languages and frameworks with lots of boilerplate and busy work coding is to use higher traction languages. I much prefer to grapple the problem with my brain in a tighter way than to attempt shaping a loose language with a looser one...
My prompts usually resemble actions I could tell a college student — they just have a better understanding of concepts and professional lingo.
The benefit of this approach is that you know the code fairly well. You are staying with the LLM in developing a deeper understanding of the code you'll ultimately create a PR for. Then when there's an incident, you have enough deep knowledge of the code that you can be tactical.
I have found that until I trust AI to develop the code unsupervised, I have to have an equally good mental model of everything AI makes.
Other times, I’m just jumping into a quick feature of bugfix ticket that’s nothing particularly fun or interesting - so it’s more fun to basically roleplay overseeing a junior dev, without any of the social pressure of interacting with a real person, and not have to get my hands dirty with boring tasks.
It’s all about finding the opportunity to have fun with it.
I feel like a lot of time is being wasted debating how serious and how real it is - but are you having any fun with it?? Cause I kinda am.
So the next generation of "rules" for Cursor, Claude Code, etc should have some predictability baked in, i.e. not be entirely driven by AI.
Having rules driven by a vanilla, non-AI program ensures that they're actually, consistently applied, with some logs showing if/how they were applied.
Of course, one can augment vanilla rules with some AI capabilities, but the main orchestration should resemble determinism.
I suspect that the main reason why this isn't a reality yet is because costs could easily skyrocket. Personally I'd be willing to pay the extra buck if that means that my comprehensive rule system is actually doing something.
that would be ironic give ppl using these tools are using it write code that have consistent outputs.
I have seen a number of articles and Youtube videos posting more or less the same thing.
In the parts of the open source LLM community that are interested in roleplay chat, the veterans seem to have the viewpoint that spending a lot of time tinkering to try to overcome the inherent flaws in this technology is relatively pointless; at a certain point, it's random, and the technology just isn't that great, you're expecting too much. Just wait for the next great model. But don't waste your time putting bandaids all over the huge flaws in the technology, you're still not going to get the results you want consistently.
I can't help but think of that here. I don't want to spend my time managing a junior engineer with amnesia, writing Rules files for it to follow, come on now. We're supposed to pay $20/mo with usage limits for that? The promise of "vibe coding" according to all the breathless media coverage and hype is that it'll supercharge me 100x. No one said anything about "Cursor rules files"!
I'll stick with Copilot's "fancy auto-complete", that does speed me up quite a bit. My forays into Agent mode and Cursor left me feeling pretty annoyed, and, like I said, I don't want a junior developer I'm managing through a chat sidebar, I'll just do the programming myself. Get back to me when Cursor is at senior or principal engineer level.
My experience mirrors yours in the sense that most coding agents are very fast, but quite junior, engineers who sometimes struggle to fix their own bugs. Nonetheless there is an advantage to speed, and if you're working on a problem a junior engineer could solve, at this point why bother doing it yourself? One of the coding agents (I prefer Claude Code personally since it's a terminal-based tool, but Cursor is similar) can write out the code faster than I can. If it adds a bug, I can usually fix it quite quickly anyway; after all, I'm not using it for the more complex problems.
Where they are today though, I wouldn't use them for hard problems, e.g. dealing with race conditions in complex codebases. For simpler webdev tasks though they're pretty useful: it's been a long time since I've hand-written an admin dashboard, for example.
If you explain the problem exactly as you would explain it to a junior coworker and gave it some handholding, it can save you a ton of time plus you don't have to actually hire such coworker. It also helps sharpen communication skills. If you cannot communicate what you want to Cursor, then most likely you cannot do that to human either, just that humans might be much better at getting the information out of you.
Just trying to say, I've been getting amazing results with Cursor as it is sparing me from doing some less "glamorous" tasks.
Documenting code style, how to work etc. makes a lot of sense for everyone and i normally have good documentation.
The problem? I know what i do, i don't write the docs for myself but for others or for my future me who might forgotten things. The good thing? Writing it for me, others and LLMs makes it a lot more helpful day to day.
Instead of explaining myself multiply times to AI OR a Junior / new Team Member, i write it down once.
I never understood the pushback on pricing. A junior engineer maybe makes 150k a year in US so $20 is 16m of his time. If you can save 16m of a junior devs time a month, it’s worth it. Much less for more senior engineers.
Sure if it’s net negative then you wouldn’t use it even if it were free. But surely the value isn’t 0 < min saved < 16m so what’s the point of bringing up the price
1. Document everything that you're doing and update a core architecture or technical doc that the LLM can read.
2. Update your .cursorrules with specific instructions for .cursor which can grow more specific as you nail down parts of your stack and the patterns you're following. This can be updated (by cursor itself) if you find the same problems recurring.
3. I have pre-commit script which runs some internal scripts. If I find the IDE is STILL making the same mistake after I've documented it and added cursor rules, the nuclear option is to add a script here which verifies the integrity of whatever construct is being violated (e.g. tests go into this folder structure, env variables are consistent between these files, import of this model that the LLMs like is forbidden)
I would add: any time you expect to be working on a particular feature / enhancement / refactor, have the LLM create a temporary document with a description and an implementation plan and work from that.
In addition: I have a specific workflow for resolving testing errors or pre-commit errors which follows the above pattern: Document each failure and work through them one at a time, running the test script and updating the document between runs.
I've established these patterns slowly with usage, but it has improved my experience a lot.
I did something similar for a small vibe-coded app. After a few back and forths to develop the first working version, I asked the LLM summarize the requirements and state of the app so far. I saved that summary into a `description.md` file, and can include it in a fresh conversation.
I was using simonw's llm so adding a new feature or making a change looks like:
`llm -f description.md -f code.py "Instructions for making another change."`
After quickly testing it seems to be reasonably good.
I’ll give this a try soon. Thanks for sharing!
