I use Cursor daily - here's how I avoid the garbage parts

I’ve been a paying cursor user for 4-5 months now and feeling the same. A lot more mistakes leaking into my PRs. I feel a lot faster but there’s been a noticeable decrease in the quality of my work.

Obviously I could just better review my own code, but that’s proving easier said than done to the point where I’m considering going back to vanilla Code.

I saw this post from a professor this morning:

https://x.com/lxeagle17/status/1899979401460371758

Students are not asking questions anymore.

Small assignments work well!

But then the big test comes and scores are at an all time low.

> I think it's weakening junior engineers' reasoning and coding abilities as they become reliant on it without having lived for long, or at all, in the before times.

I have a feeling there will be a serious shortage of strong "old-school" seniors in a few years. If students and juniors are reliant on AI, and we recruit seniors from our juniors, who will companies turn to when AI gets stuck?

> I think it's weakening junior engineers' reasoning and coding abilities as they become reliant on it without having lived for long, or at all, in the before times.

Same as StackOverflow, same as Google, same as Wikipedia for students.

The problem is not using the tools, it's what you do with the result. There will always be lazy people who will just use this result and not think anymore about it. And then there will always be people who will use those results as a springboard to what to look for in the documentation of whatever tool / language they just discovered thanks to Cursor.

You want to hire from the second category of people.

> Personally, and quietly, I have a major concern about the conflict of interest of Cursor deciding which files to add to context then charging you for the size of the context.

> As with so many products, it's cheap to start with, you become dependent on it, then one day it's not cheap and you're fucked.

If it gets too expensive, then I guess the alternative becomes using something like Continue.dev or Cline with one of the providers like Scaleway that you can rent GPUs from or that have managed inference… either that, or having a pair of L4 cards in a closet somewhere (or a fancy Mac, or anything else with a decent amount of memory).

Whereas if there are no well priced options anywhere (e.g. the upfront investment for a company to buy their own GPUs to run with Ollama or something else), then that just means that running LLM based systems nowadays is economically infeasible for many.

> Personally, and quietly, I have a major concern about the conflict of interest of Cursor deciding which files to add to context then charging you for the size of the context.

Can you elaborate on what you're referring to? I don't used Cursor extensively, but I do pay for it, and it was a flat fee annual subscription for unlimited requests, with the "fast" queue being capped at a set number of requests per month with no reference to their size.

Claude Code does work the way you say, since you provide it your Anthropic API key. But I have not seen Cursor charging for context or completion tokens, which is actually the reason why I'm paying for it instead of using something like Aider.

https://www.cursor.com/pricing

Has anyone tried limiting Cursor or Cline, etc, to a higher level role such as analysis and outlining proposed changes, and then coding those changes yourself with minimal LLM interaction? Aka, ask to define / outline only a high level set of changes, but do no actual changes to any file; then proceed through the outlined work, limiting Cursor to roughing out the work and hand writing the actual critical bits? That’s the approach I’ve been taking, a sort of best of both worlds that greatly speeds me up without taking the hands 100% off the wheel.

Heavier architecture / systems design stuff is sometimes easier to do with a differently configured cursor, or claude.

The key I find is experience doing that kind of stuff to begin with, vs domain experience as well, vs little to none and wanting to learn the ropes.

>Cursor has been trying to do things to reduce the costs of inference, especially through context pruning. For instance, if you "attach" files to a conversation, Cursor no longer stuffs the code from those files into the prompt. Instead, it'll run function calls to open those files and read bits and pieces of the code until the model feels it has enough information. While that seems like a perfectly reasonable strategy, it starts to fall apart when integrating reasoning models.

In general I feel like this was always the reason automatic context detection could not be good in fixed fee subscription models - providers need to constrain the context to stay profitable. I also saw that things like Claude Code happily chew through your codebase, and bank account, since they are charging by token - so they have the opposite incentive.

> This seems like a perfectly reasonable strategy until you realize you cannot do the same thing with reasoning models, if you're limiting the reasoning to just the initial prompt.

Keep in mind that what we call "reasoning" models today are the first iteration. There's no fundamental reason why you can't do what you stated. It's not done now, but it can be done.

There's nothing stoping you from running "tinking" in "chunks" of 1-2 paragraphs, doing some search, and adding more context (maybe from pre-reasoned cache) and continuing the reasoning from there.

There's also work being done on think - summarise - think - summarise - etc. And on various "RAG"-like thinking.

This is only surface-level deep. Cursor already has Quotas for their paid plans and Usage-based Pricing for their larger models, which I run into and fall over to their usage based model every month.

Imo most of their incentive on context-pruning comes not just from reducing the token amount, but from the perception that you only have to find "the right way"tm to build that context window automatically, to get to coding panacea. They just aren't there yet.

> Instead, it'll run function calls to open those files and read bits and pieces of the code until the model feels it has enough information. This seems like a perfectly reasonable strategy until you realize you cannot do the same thing with reasoning models, if you're limiting the reasoning to just the initial prompt.

There's nothing about this that conflicts with reasoning models, I'm not sure what you mean here.

> Cursor has been trying to do things to reduce the costs of inference, especially through context pruning.

You can also use cline with gemini-2.0-flash, which supports a huge context window. Cline will send it the full context and not prune via RAG, which helps.

I think you're right, but what company's business model doesn't produce a conflict between the user's well-being and the company's finances?

Reflecting on your comment I realized that using a huge amount of GPUs is akin to an Turing machine approaching infinite speed. So I think the promise of LLMs writing code is basically saying: if we add a huge number of reading/writing heads with unbounded number of rules, we can solve decideability. Because what is the ability to generate arbitrarily complex code if not solving the halting problem? Maybe there's a more elegant or logical way to postulate this, or maybe I'm just confused or plain wrong, but it seems to me that it is impossible to generate a program that is guaranteed to terminate unless you can solve decideability. And throwing GPUs at a huge tape is just saying that the tape approaches infinite size and the Turing machine approaches infinite speed...

Or put another way, isn't the promise of software that is capable to generate any software given a natural language description in finite time basically assuming P=NP? Because unless the time can be guaranteed to be finite, throwing GPU farms and memory at this most general problem (isn't the promise of using software to generating arbitrary software the same as the promise that any possible problem can be solved in polynomial time?) is not guaranteed to solve it in finite time.

I had the exact same experience, pretty sure this happens in most cases, people just don’t realize it

Just get a Mac Studio with 512GB RAM and run a local model when the internet is down.

Me too. I completely forgot the standard library and basic syntax of my daily language. wow. I went back to VSCode and use Cursor for the AI model to ask questions.

> aider [...] It kept telling me to "add files" that are in the damn directory that I opened it in.

That's intentional, and I like it. It limits the context dynamically to what is necessary (of course it makes mistakes). You can also add files with placeholders and in a number of other ways. but most of the time I let Aider decide. It has a repomap (https://aider.chat/docs/repomap.html), gradually building up knowledge and makes proposals based on this and other information it gathered also with token costs and out-of-context-window in mind.

As for manual changes: aider is opinionated regarding the role of Git in your workflow. At first glance, this repels some people and some stick to this opinion. For others, it is exactly one of the advantages, especially in combination with the shell-like nature of the tool. But the standard Git handling can still be overridden. For me personally, the default behavior becomes more and more smooth and second nature. And the whole thing is scriptable, I only begin to use the possibilities.

In general: Tools have to be learned, impatient one-shot attempts are simply not enough anymore.

> Nvidia is rich because they have insane margins on their GPUs. They cost a fraction of what they sell them for. That means that price will crash over time. So, I'm optimistic that a lot of this stuff will improve rapidly.

OTOH currently the LLM companies are probably taking a financial loss with each token. Wouldn't be surprised if the price doesn't even cover the electricity used in some cases.

Also e.g. Gemini already runs on Google's custom hardware, skipping the Nvidia tax.

> Nvidia is rich because they have insane margins on their GPUs. They cost a fraction of what they sell them for. That means that price will crash over time. So, I'm optimistic that a lot of this stuff will improve rapidly.

That still leaves us with an ungodly amount of resources used both to build the GPUs and to run them for a few years before having to replace them with even more GPUs.

Its pretty amazing to me how quickly the big tech companies pivoted from making promises to "go green" to buying as many GPUs as possible to burn through entire powerplants worth of electricity.

Try Claude Code. It figures out context by itself. I’m having a lot of success with it for a few days now, whereas I never caught on with Cursor due to the context problem.

By trying things and seeing what it’s good and bad at. For example, I no longer let it make data modelling decisions (both for client local data and database schemas), because it had a habit of coding itself into holes it had trouble getting back out of, eg duplicating data that it then has difficulty keeping in sync, where a better model from the start might have been a more normalised structure.

But I came to this conclusion by first letting it try to do everything and observing where it fell down.

AI tools aren’t all or nothing. You use them when it makes sense and you go back to regular coding when they don’t (or when they’re unavailable).

You’re also not limited to a single tool. You can switch to different tools and even have multiple editors open at the same time.

There's always Aider with local models!

This is true of every single service provider outside of fully OSS solutions, which are a teeny tiny fraction of the world's service providers.

I had that same experience with Claude Code. I tried to do a 95% "Idle Development RPG" approach to developing a music release organization software. At the beginning, I was really impressed, but with more and more complexity, it becomes increasingly incoherent, forgetting about approaches and patterns used elsewhere and reinventing the wheel, often badly.

Agreed. One useful tip is to have Cursor break up large files into smaller files. For some reason, the model doesn't do this naturally. I've had several Cursor experiments grow into 3000+ line files because it just keeps adding.

Once the codebase is reasonably structured, it's much better at picking which files it needs to read in.

Or the context not being large enough for all the obscure functions and files to go into the context. I am too basic to have dug deep enough, but a simple (automatic) documentation context for the entire project would certainly improve things for me.

Yeah I have seen this a bunch of times as well. Especially with deprecated function calls. It generates a bunch of code. I get deprecation warnings. I fix them. Copilot fixes them back. I have to explicitly point out that I made the change for it to not reintroduce the deprecations.

I guess that while code that compiles is easier to train for but code with warnings less so?

I remember there are other examples of changes that I have to tell the AI I made to not have it change it back again, but can't remember any specific examples.

It’s due to a problem with Cursor not updating the state of the files that have been manually edited since the last time they were used in the chat, so it’ll thing the fix is not there and blindly output code that doesn’t have it. The ‘apply’ model is dumb, so it just overwrites the corrected version with the wrong one.

I think the changelog said they fixed it in 0.46, but that’s clearly not the case.

Cursor in agent mode + Sonnet 3.7 love nothing better than rewriting half your codebase to fix one small bug in a component.

I've stopped using agent unless its for a POC where I just want to test an assumption. Applying each step takes a bit more time but means less rogue behaviour and better long term results IME.

I think you’re absolutely right and I’ve come to the same conclusion and workflow.

I work on one file at a time in Ask mode, not Composer/Agent. Review every change, and insist on revisions for anything that seems off. Stay in control of the process, and write manually whenever it would be quicker. I won’t accept code I don’t understand, so when exploring new domains I’ll go back with as many questions as necessary to get into the details.

I think Cursor started off this way as a productivity tool for developers, but a lot of Composer/Agent features were added along the way as it became very popular with Vibe Coders. There are inherent risks with non-coders copypasting a load of code they don’t understand, so I see this use case as okay for disposable software, or perhaps UI concept prototypes. But for things that matter and need to be maintained, I think your approach is spot on.

Do you have any Cursor rules defined? Those tend to control its habit of trying to go off the rails and solve 42 problems at once instead of just the one.

This is a huge issue that was already raised on their forums and it's very surprising they didn't address it yet.

[0] https://forum.cursor.com/t/environment-secrets-and-code-secu...

> why forking VS Code when all this functionality could just be an extension, same as Copilot does?

Have you programmed extensions for VSCode before? While it seems like a fairy extensible system overall, the editor component in particular is very restrictive. You can add text (that's what extensions like ErrorLens and GitLens are doing), inlay hints, and on-hover popup overlays (those can only trigger on words, and not on punctuation). What Cursor does: the automatic diff-like views of AI suggestions with graphic outlines, floating buttons, and whatnot right on top of the text editing view - is not possible in vanilla VSCode.

This was originally driven by necessity of tighter control over editor performance. In its early days VSCode was competing with Atom - another extensible JS-powered editor from GitHub, and while Atom had an early lead due to larger extensions catalog VSCode ultimately won the race because they manged to maintain lower latency of their text editor component. Nowadays they still don't want to introduce extra extension points to it, because newer faster editors pop out all the time, too.

> and the gain vs Copilot is not that high

I think that's (at least part of) your answer. More friction to move back from an entirely separate app rather than disabling an extension.