Damnit, now I probably have to update my vscode plugin to support Cursor 3... I mean have a coffee or go for a swim while waiting on AI to update my vscode plugin to support Cursor 3. :P
Cursor 3
231–240 of 438 posts
Re: Cursor 3
#232I find a lot of these IDEs are simply not as useful as a CLI. When I'm running a full agentic workflow, I don't really need to see the contents of the files at all time, I'd actually say I often don't need to at all, because I can't really understand 10k lines of code per hour.
If you can’t understand your code, who can?
Re: Cursor 3
#233[dead]
Re: Cursor 3
#234Earlier quoted context omitted.
I think you are still speaking in the lower abstraction in terms of zwaps' provided understanding. "Tagging specific code" or "files" is likely the type of interfacing most Claude Code users are _not_ doing. Instead they are defining architecture through specs and verification-loops and attempting to one-shot solutions fitting clear tests. On reflection, I personally don't have many prompts with CC referencing files…
So that sounds like Claude Code is an inferior subset of Cursor. That Cursor can work like Claude Code, but Claude Code is lacking Cursor’s editing capabilities.
That is my experience currently.
Re: Cursor 3
#235Stop fucking my shit up please
The output isn't yours, and never was due to copyright law opinion.
The input isn't yours, as it is stolen and re-sold to other people.
The model isn't yours, as it was built with piracy, theft of service, and EULA violations.
What are people doing exactly... outside data-entry for free. =3
Re: Cursor 3
#236[deleted]
Re: Cursor 3
#237I've been running Claude Code in my Cursor IDE for a while now via extension. I like the setup, and I direct Claude on one task at a time, while still having full access to my code (and nice completions via Cursor). I still spend time tweaking, etc. before committing. I have zero interest in these new "swarms of agents" they are trying to force on us from every direction. I can barely keep straight my code working on…
>I have zero interest in these new "swarms of agents" I think you misunderstand "swarms of agents", based on what you say above. An agent swarm, in my understanding and checked via a google search, does not imply working on multiple features at one time. It is working on one feature with multiple agents taking different roles on that task. Like maybe a python expert, a code simplifier, a UI/UX expert, a QA tester, an…
> does not imply working on multiple features at one time.
How can multiple parallel agents some local and some in the cloud be working on a single task?
How can:
> All local and cloud agents appear in the sidebar, including the ones you kick off from mobile, web, desktop, Slack, GitHub, and Linear. (From the announcement, under “Run many agents in parallel”)
…be working on the same task?
Subagents are different, but the OP is not confused about what cursor is pushing, and it is not what you describe.
Re: Cursor 3
#238Wow, really negative comments here! I'm not a cursor user, and I can't say I love the look of this UI, but my team and I are very heavy users of https://www.conductor.build . Managing many agents, each in their own sandbox, felt like indisputably the future after using conductor for a day. We were a cursor company before conductor, but we cancelled all our seats around the time Opus 4.6 dropped because conductor was vastly more productive. So IMO, Cursor is definitely moving in the right direction w/ this -- the days of the IDE are numbered & they're correctly designing for the future.
For me, there's no way to get into a flow state if I'm thinking about terminal windows and Claude Code. Even before conductor dropped on our team, I'd been building CLIs to spin up agent sandboxes on work trees -- but that still required a lot of terminal window management.
My work now is usually: - 1 hard task (hard to think about more than 1 of these at once) -- localized to a sandbox, but with multiple agents in different convo threads - N simpler tasks (usually 4-8). These are usually one-shottable. They're a pleasure to come up with & ship.
I'm thinking about and managing the hard task. When it's cooking for more than 10 seconds, I'm switching to an ez task and pushing them along.
Just like OG coding -- hard to be in a flow state every day. But when it works, you can get an unbelievable amount of work done.
I'll be walking around now, and I'll add voice notes of little tasks or cleanups I want to throw an agent at when I get home. Good products are made of 1000s of small, good decisions -- and now those are free to implement, the slowest part is writing them down as tickets.
Re: Cursor 3
#239Earlier quoted context omitted.
> have zero interest in these new "swarms of agents" they are trying to force on us from every direction. Good for you! Personally waiting for one agent to do something while I shove my thumb up my butt just waiting around for it to generate code that I'll have to fix anyway is peak opposite of flow state, so I've eagerly adopted agents (how much free will I had in that decision is for philosophers to decide) so ther…
I find it puzzling whenever someone claims to reach "flow" or "zen state" when using these tools. Reviewing and testing code, constantly switching contexts, juggling model contexts, coming up with prompt incantations to coax the model into the right direction, etc., is so mentally taxing and full of interruptions and micromanagement that it's practically impossible to achieve any sort of "flow" or "zen state". This i…
LLMs deal with implementation details that get in the way of "flow"
Re: Cursor 3
#240Earlier quoted context omitted.
Claude Code isn't really "all terminal" if you embed that terminal in your IDE. I still use Cursor (for now), but I embed a CC panel via extension. With this launch of Cursor 3, I'll probably get off Cursor for good. I have zero interest in this.
Curious, why cursor for this? VSCode or pretty much pure open source IDE's have CC integration. Or am i missing something?
Probably momentum. It takes some effort to change tooling. This is why Cursor worked so well in the beginning. It just took over from VSCode seamlessly.