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

We don't plan on reporting SWE-bench Verified, for similar reasons to OpenAI: https://openai.com/index/why-we-no-longer-evaluate-swe-bench...

Comments URL: https://news.ycombinator.com/item?id=47264311

Points: 7

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47141048

Points: 12

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46951394

Points: 20

# Comments: 9

Comments URL: https://news.ycombinator.com/item?id=46902095

Points: 8

# Comments: 0

We're making this better very soon! In the coming weeks hopefully.

Comments URL: https://news.ycombinator.com/item?id=46724597

Points: 4

# Comments: 0

https://news.ycombinator.com/item?id=46650998

Comments URL: https://news.ycombinator.com/item?id=46534268

Points: 2

# Comments: 0

> By prioritizing the vibe coding use case, Cursor made itself unusable for full-time SWEs.

This has actually been the opposite direction we're building for. If you are just vibing, building prototypes or throwaway code or whatever, then you don't even need to use an IDE or look at the code. That doesn't really make sense for most people, which is why Cursor has different levels of autonomy you can use it for. Write the code manually, or just autocomplete assistance, or use the agent with guardrails - or use the agent in yolo mode.

> One way to achieve that would be to limit the number of lines seen by an LLM in a single read: read first 100 lines

Cursor uses shell commands like `grep` and `ripgrep`, similar to other coding agents, as well as semantic search (by indexing the codebase). The agent has only been around for a year (pretty wild how fast things have moved) and 8 months or so ago, when models weren't as good, you had to be more careful about how much context you let the agent read. For example, not immediately putting a massive file into the context window and blowing it up. This is basically a solved problem today, more or less, as models and agents are much better are reliably calling tools and only pulling in relevant bits, in Cursor and elsewhere.

> Try to write a prompt in build mode, and then separately first run it in plan mode before switching to build mode. The difference will be night and day.

Agree. Cursor has plan mode, and I generally recommend everyone start with a plan before building anything of significance. Much higher quality context and results.

> Very careful with asking the models to write tests or fix code when some of those tests are failing. If the problem is not trivial, and the model reaches the innate context limit, it might just comment out certain assertions to ensure the test passes.

Agree you have to be careful, but with the latest models (Codex Max / Opus 4.5) this is becoming less of a problem. They're much better now. Starting with TDD actually helps quite a bit.