8 ms·

Man, I wish they'd keep the old philosophy of letting the developer drive and the agent assist. I feel like this design direction is leaning more towards a cha

• mat_b 6mo ago
  Exactly how I feel. If I wanted this agent-centric view without being able to easily see the code I would be using Claude Code. I use Cursor because agents are not ready to be the ones driving. I need to drive. I still need to understand all the code (and easily browse it) and keep a close watch over what the AI is doing.
• whicks 6mo ago
  Agreed completely on this (as a heavy daily user of Cursor). It's been the perfect in-between of coding by hand (never again!) and strictly "vibe coding" for me. Being able to keep my eyes on all the changes in a "traditional" IDE view helps me maintain a mental model of how my systems work. I'm hoping in this new UI in v3 I can still get that experience (maybe it's just hidden behind a toggle somewhere for power users / not shown off in the marketing materials).
  • leerob 6mo ago
    I'm an engineer at Cursor, can try to clarify questions here. > I wish they'd keep the old philosophy of letting the developer drive and the agent assist. Even when I'm using AI agents to write code, I still find myself spending most of my time reading and reasoning about code. We very much still believe this, which is why even in this new interface, you can still view/edit files, do remote SSH, go to definition and use LSPs, etc. It's hard to drive and ship real changes without those things in our opinion, even as agents continue to get better at writing code. > I'm hoping in this new UI in v3 I can still get that experience (maybe it's just hidden behind a toggle somewhere for power users / not shown off in the marketing materials). This new interface is a separate window, so if you prefer the Cursor 2 style, that continues to exist (and is also getting better).
    • whicks 6mo ago
      Great, glad to hear that! Stoked to kick the tires on Cursor 3. Thanks for confirming, leerob!
    • seamossfet 6mo ago
      > We very much still believe this That's good to hear, I might have jumped a little too quickly in my opinion. It's a bit of a Pavlovian response at this point seeing a product I very much love embrace a giant chat window as a UX redesign haha. I would love to see more features on the roadmap that are more aligned with users like us that really embrace the Cursor 2 style with the code itself being the focal point. I'm sure there's a lot you can do there to help preserve code mental models when working with agents that don't hide the code behind a chat interface.
    • vvilliamperez 6mo ago
      Once I downloaded it, it made sense. The blog post almost made me cancel my subscription because it seemed to get rid of the IDE entirely.
  • dominotw 6mo ago
    > It's been the perfect in-between of coding by hand (never again!) and strictly "vibe coding" for me. I dont think there is an inbetween. Its really hard to 'keep an eye' on code by casually reading diffs. Eventually it will become vibe coding. Software engineers are deluding themselves with spec driven, plans, prds whatever nonsense and thinking its not vibecoding.
    • jimbokun 6mo ago
      Why? Reading diffs is an inescapable skill, needed for evaluating any kind of PR. This just makes it more interactive. I just use Copilot with VS Code, but my flow is to just ask Claude to make a change across whatever files it needs to touch, then either accept the changes, edit the changes directly, or clarify whatever was different from my expectations. Reading diffs is central to how I work with these agents.
• emp17344 6mo ago
  AI labs think they’re building an autonomous replacement for software engineers, while software engineers see these systems as tools to supplement the process of software engineering.
  • pjmlp 6mo ago
    AI labs won't replace all of the engineers, while engineers becoming more productive, leads to smaller team sizes.
    • cruffle_duffle 6mo ago
      Smaller teams working on much more diverse set of problems. The truth is absolutely nobody knows how this will all shake out.
  • seamossfet 6mo ago
    Yeah that's the disconnect though right? Even with the best frontier models, you need to do a lot of system design work, planning, and reviewing before you can let these models run. These models are infinitely more effective when piloted by a seasoned software engineer and that will always be the case so long as these models require some level of prompting to function. Better prompts come from more knowledgeable users, and I don't think we can just make a better model to change that. The idea we're going to completely replace software engineers with agents has always been delusional, so anchoring their roadmap to that future just seems silly from a product design perspective. It's just frustrating Cursor had a good attitude towards AI coding agents then is seemingly abandoning that for what's likely a play to appease investors who are drunk on AI psychosis. Edit: This comment might have come off more callous than I intended. I just really love Cursor as a product and don't want to see it get eaten by the "AI is going to replace everything!" crowd.
  • dominotw 6mo ago
    > AI labs think they’re building an autonomous replacement for software engineers And management everywhere is convinced that thats what they are paying for. My company is replacing job titles with "builder". Apparently these tools will make builder out of paper pushers hiding in corporate beaurcarcy. I am suddenly same as them now per my company managment.
• cyral 6mo ago
  I just upgraded and you can still show/hide the entire editor like before
• vachina 6mo ago
  Agent is where tokens are consumed, and where they can charge you more.
• Bnjoroge 6mo ago
  That philosophy wouldnt help justify the narrative for their massive valuation.
• adityamwagh 6mo ago
  How would they make money from the tokens then haha? The main revenue driver of these companies is to get people to use more tokens. That’s what they will optimise for. Getting the developers out of the way is the way to do it.
  • Archonical 6mo ago
    Isn’t Cursor’s business model mostly subscriptions? They’re the ones paying for inference, not the user directly, right? So wouldn’t they be incentivized to minimize token usage per unit of user value, not maximize raw tokens?
    • adityamwagh 5mo ago
      I think enterprise users have a API for the whole company do pay as you go? I believe that’s where they make the most money.
    • bb1298 6mo ago
      Nope. Enterprise you pay for seat to access all of the enterprise features and then you just pay for tokens as you go. Vast majority of their actual revenue comes from enterprise and their revenue is just api pass through to the model providers.
    • fweimer 6mo ago
      It's pay-as-you-go after a certain number of included requests/tokens: https://cursor.com/docs/models-and-pricing https://cursor.com/docs/models-and-pricing
  • moregrist 6mo ago
    Does Cursor make money from tokens? I thought it was primarily a user of Anthropic and OpenAI APIs, so the fewer tokens you use to accomplish a task, the higher their margin.
    • rnxrx 6mo ago
      Gemini is featured just as prominently, and they've most recently been pushing their own model series (Composer).
• verdverm 6mo ago
  Why I harp on owning your stack instead of outsourcing your Ai experience and interface to Big Ai. There are many frameworks that make this much easier today. I chose ADK which is more of a lift, but also works for non-coding use cases.
• digitaltrees 6mo ago
  [flagged]
• laanako08 6mo ago
  [dead]
• davnicwil 6mo ago
  My guess would be this is less driven by product philosophy, more driven by trying to maximise chances of a return on a very large amount of funding in an incredibly tough market up against formidable, absurdly well-funded competitors. It's a very tough spot they're in. They have a great product in the code-first philosophy, but it may turn out it's too small a market where the margins will just be competed away to zero by open source, leaving only opportunity for the first-party model companies essentially. They've obviously had a go at being a first-party model company to address this, but that didn't work. I think the next best chance they see is going in the vibe-first direction and trying to claim a segment of that market, which they're obviously betting could be significantly bigger. It's faster changing and (a bit) newer and so the scope of opportunity is more unknown. There's maybe more chances to carve out success there, though honestly I think the likeliest outcome is it just ends up the same way. Since the beginning people have been saying that Cursor only had a certain window of time to capitalise on. While everyone was scrambling to figure out how to build tools to take advantage of AI in coding, they were one of the fastest and best and made a superb product that has been hugely influential. But this might be what it looks like to see that window starting to close for them.
  • htrp 6mo ago
    > They've obviously had a go at being a first-party model company to address this, but that didn't work. I thought there was an entire initiative to build their own coding model and the fine tunes of in Composer 1.5 and Composer 2 were just buying them time and training data
  • rustystump 6mo ago
    It is interesting that i find composer to be one of my favorites as while it is a bit dumb it is about 100x faster than the fat boys. Sometimes u need the beef of opus but 80% composer is plenty.
    • rubyn00bie 6mo ago
      I have been on the fence if I think composer is useful, but the speed argument is one I hadn’t really considered. I use cursor with Opus almost exclusively but the other day I tried using OpenCode locally with a 6-bit quantized version of Qwen 3.5 and holy crap the speed and latency were mind blowing. Even if not quite as sharp as big boi Opus and the gang. Now you’ve got me thinking I should give composer another go because speed can be pretty darn great for more generic, basic, tasks.
• w29UiIm2Xz 6mo ago
  As a Cursor user who hasn't tried Claude Code yet, am I missing anything? I seem (sometimes) exceptionally productive in it and it's working for me. To my understanding, Claude Code is all terminal, but something like an IDE seems like the better interface to me: I want to see the file system, etc. It seems Cursor doesn't have the mindshare relative to Claude in public discussion spaces.
  • deleted 6mo ago
    [deleted]
  • nu11ptr 6mo ago
    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.
    • vira28 6mo ago
      Curious, why cursor for this? VSCode or pretty much pure open source IDE's have CC integration. Or am i missing something?
      • slashdave 6mo ago
        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.
  • ohmahjong 6mo ago
    As someone whose work enforced a switch from Cursor to Claude Code, I do keep on top of the code by pairing it with an IDE, tracking/viewing changes etc. There's no real obstacle to using an IDE as you normally would, with Claude Code as a sidecar.
  • zwaps 6mo ago
    Claude Code is where you move up one abstraction layer. Almost everyone using it productively has spend a lot of time working on their harness, ensuring that everything is planned out and structured such that all that is left is really type in the code. This typically works without error. Before that, you interact a lot via Claude Code in whatever abstraction you feel is right. That's basically it. You can review changes afterwards, but that's not the main point of Claude Code. It's a different workflow. It's built on the premise: given a tight and verifiable plan, AI will execute the actual coding correctly. This will work, mostly, if you use the very best models with a very good and very specific harness. Cursor, same as Copilot, has been used by people who are basically pair programming with the AI. So, on abstraction down. I have no idea what is better, or faster. I suspect it depends at least on the problem, the AI, and the person.
• retinaros 6mo ago
  that is what is catching the most users right? they want to vibe code their way into oblivion
• throwaw12 6mo ago
  > I still want to _code_ not just vibe my way through tickets. Now we have 3 ways of coding: * vim / emacs - full manual * VSCode / IntelliJ - semi-automatic * ClaudeCode/Codex/OpenCode/... - fully automated Cursor can't stay in between
  • hparadiz 6mo ago
    There are some critical parts of architecture where sometimes I really do need to see the code and even sometimes put a wall around it and tell the agent they can't touch it.
  • Hoefner 6mo ago
    Cursor CLI exist - https://cursor.com/cli https://cursor.com/cli
    • vorticalbox 6mo ago
      This is how use cursor 99% of the time. The other 1% is in zed.
  • ninininino 6mo ago
    Saying it can't stay in between is like saying a company can't sell both regular bikes and electric bikes. Or bikes that can do both.
  • jimbokun 6mo ago
    Why? Are you saying they can’t compete with VS Code in the semi-automatic space?
    • throwaw12 6mo ago
      Yes, They can't compete VSCode is open source and ahead, and getting lots of contributions from different companies. On the other hand, you have JetBrains with a specific expertise in JVM based dev environments, it's possible to compete with them, but very time consuming They better focus on one thing and win the developers, otherwise they would lose (and losing) to Claude Code and Codex on one side, on the other side they will lose to JetBrains and VSCode Better to focus
• yieldcrv 6mo ago
  At least these are IDEs with the save button finally gone We needed that jump, there were still floppy disk icons
• peder 6mo ago
  > I feel like this design direction is leaning more towards a chat interface as a first class citizen and the code itself as a secondary concern. That's because that's exactly where we're headed, and it's fine.
  • skor 6mo ago
    NASA vibes all its note taking apps
• cedws 6mo ago
  Yeah, this model where you don't get an editor anymore feels like a step backwards. I don't want to give up LSPs, being able to step into/rename functions and stuff like that. I should still be the one in control of the code - the agent is the assistant, not me. This is why Zed's direction felt pretty strong to me. Unfortunately their agentic features are kind of stagnating and the ACP extensions are riddled with issues.
  • trevordilley 6mo ago
    We're building DevSwarm, and it's aiming to strike the balance between agentic coding in parallel without losing your IDE. Each workspace (worktree) gets a dedicated vscode instance, and in that instance we make it easy to fire up Claude Code, Codex, etc. Would love to hear if it hits the sweet spot we're going for. edit: https://devswarm.ai https://devswarm.ai
  • anthonypasq 6mo ago
    did you watch the 90 second video in the post? all of this is addressed
    • cedws 6mo ago
      No but I have now. It’s hard to tell from that few seconds but it doesn’t look like it’s really putting the developer in the driving seat, just providing a minimal escape hatch for manual edits.
  • blks 6mo ago
    It’s very unfortunate what direction Zed has taken. It was very fast and nice editor, that’s now infected with those “AI” features.
    • logicprog 6mo ago
      It's still a very nice and fast editor, and you can just switch off those AI features. They're still releasing features and fixes for the non-AI parts.
  • 6mo ago
• whazor 6mo ago
  Imagine you are the top engineer of your company. Everybody wants your attention, many meetings, design sessions, and of-course code reviews. With Claude Code, I use Gitlab for reviewing code. And then I let Claude pull the comments. It looks like the new UI has a big focus on multiple agents. While it feels wrong, the more you split up your work into smaller merge requests, the easier it is to review the work. Chat first is the way to go since you want the agent busy making its code better. Let it first make plans, come up with different ideas, then after coding let it make sure it fully tests that it works. I can keep an agent occupied for over a hour with e2e tests, and it’s only a couple hundred lines of code in the end.
• blks 6mo ago
  Then code.
• throwaway613746 6mo ago
  [dead]
• uduni 6mo ago
  I guess they are assuming LLMs will just get better and better until youn don't look at code at all. Ignoring the fact that software will just keep getting more and more complex and interconnected... There will always be a new frontier or code and UX
  • scottyah 6mo ago
    They're targeting the 90% of code that doesn't really need to be looked at. Software is already so complex and interconnected that it is fully beyond human capabilities, each person only knows a tiny part of the stack. If you create your own full system from scratch, it's not going to be very generally useful.
• criley2 6mo ago
  The philosophy still works, you just have to change your view. Instead of trying to work side by side with the agent on every turn (inside of your IDE), instead the agent performs a unit of work and then you review it. You can use your IDE to view the diff, or another diffing tool. If you've dug in sufficiently on plan mode, then what the agent is executing is not a surprise and shouldn't need input. If it does, the plan was insufficient and/or the context around the request (agents.md, lessons.md, or whatever tools and documents you use ) weren't sufficient. EDIT: Maybe it doesn't work in cursor, but I continue to use vscode to review diffs and dig in on changes.
• nektro 6mo ago
  embrace tradition, return to vscode
• rebolek 6mo ago
  I vibe my way through my ideas. I look at LLM code sometimes to cry and cringe and then I beg LLM to have basic dignity and self respect to write code it shouldn’t be ashamed of. But then I instruct it to do something and it does it with speed I’m never able to achieve, even if the code is ugly. But it works.
  • varispeed 6mo ago
    Works until you discover subtle bugs hiding behind ugliness.
    • hombre_fatal 6mo ago
      Which is true for human-written code as well. In both cases, it's your processes (automated testing, review, manual QA) that is the bulwark against bugs and issues. With AI, you can set up great processes like having it check every PR against the source code of your dependencies or having it generate tests for what's an intermediate step or ephemeral solution that you would never write tests for if you had to do it yourself. There's this idea on HN that if you delegate too much to AI, you get worse code. Presumably not appreciating all the code-improving processes you can delegate to AI, particularly processes you were never doing for hand-written code.
    • rebolek 6mo ago
      Yes, there are so many. As in hand-written code. I don’t take LLM written code for granted and I rewrite is sometimes. I know it’s not perfect. But it’s useful. Compile code is not perfect also. But who does hand-written assembler anymore? Yes, LLM is another layer, it would be ugly and slower but it’s much faster to use.
      • varispeed 6mo ago
        The thing is that with the code you've written you wrote it in a way that you understand and you have mental model of how it works therefore it is much easier to reason about potential edge cases that have not been covered.
• girvo 6mo ago
  > I still want to _code_ not just vibe my way through tickets. You and I want this. My EMs and HoEs and execs do not. I weep for the future of our industry.
• _palf 6mo ago
  [dead]
• claud_ia 6mo ago
  [dead]