Live data from Hacker News

Cursor 3

cursor.com

131–140 of 438 posts

Re: Cursor 3

#131

Earlier quoted context omitted.

I'm not convinced people who are doing real work on production applications with any sizable user base is writing code through only agents. There's no way to get acceptable code from these models without really knowing your code base well and basically doing all the systems thinking for the model. Your workflow is probably closer to what most SWEs are actually doing.

This, at least for me, has changed in the past six months. Which is the same thing people were saying in the months prior to that, so I will accept some eye rolls. But at least for our pretty large monorepo opus + a lot of engineering work on context got us to a point where a large portion of our engineers are doing most of their work with agents first and a lot of back and forth + smaller hand edits.

Agreed. The size of the repo isn't a limiting factor anymore. It's more about the type of change.

Agents today can generate solid code even for relatively complex requirements. However, they don't always make the right trade-offs.

Just because something works doesn't mean it scales. It doesn't mean it can handle unexpected user input. It doesn't mean it's easily extensible.

Today engineers really just need to define those high-level technical requirements.

Re: Cursor 3

#132

Earlier 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 have personally found that I cannot context switch between thinking deeply about two separate problems and workstreams without a significant cognitive context-switching cost. If it's context-switching between things that don't require super-deep thought, it's definitely doable, but I'm still way more mentally burnt-out after an hour or two of essentially speed-running review of small PRs from a bunch of different s…

This is a struggle I've also been having.

It's easier when I have 10 simple problems as a part of one larger initiative/project. Think like "we had these 10 minor bugs/tweaks we wanted to make after a demo review". I can keep that straight. A bunch of agents working in parallel makes me notably faster there though actually reviewing all the output is still the bottleneck.

It's basically impossible when I'm working on multiple separate tasks that each require a lot of mental context. Two separate projects/products my team owns, two really hard technical problems, etc. This has been true before and after AI - big mental context switches are really expensive and people can't multitask despite how good we are at convincing ourselves we can.

I expect a lot of folks experience here depends heavily on how much of their work is the former vs the later. I also expect that there's a lot of feeling busy while not actually moving much faster.

Re: Cursor 3

#133

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 chat interface as a first class citizen and the code itself as a secondary concern. I really don't like that. Even when I'm using AI agents to write code, I still find myself spending most of my time reading and reasoning about code. Showing me little snippets of…

Then code.

Re: Cursor 3

#134

Maybe I'm old, but I only recently started using Gemini to assist me in coding. Now it seems everyone is heading to giving agents to do the full-blown coding. I guess if the result code is good, it doesn't matter who's coding (me or AI). But are they affordable already for developers who don't earn a Silicon Valley salary? Developers in 3rd world countries?

I'm not convinced people who are doing real work on production applications with any sizable user base is writing code through only agents. There's no way to get acceptable code from these models without really knowing your code base well and basically doing all the systems thinking for the model. Your workflow is probably closer to what most SWEs are actually doing.

You really need to keep them on a tight leash, stop and correct them when they start screwing up, and then the remaining 90% of the work starts after they say their done, where you need to review/refactor/replace a lot of what they produced.

The only way you're going to let an agent go off on its own to one-shot a patch is if your quality bar is merely "the code works."

Re: Cursor 3

#135
post #131

Earlier quoted context omitted.

This, at least for me, has changed in the past six months. Which is the same thing people were saying in the months prior to that, so I will accept some eye rolls. But at least for our pretty large monorepo opus + a lot of engineering work on context got us to a point where a large portion of our engineers are doing most of their work with agents first and a lot of back and forth + smaller hand edits.

Agreed. The size of the repo isn't a limiting factor anymore. It's more about the type of change. Agents today can generate solid code even for relatively complex requirements. However, they don't always make the right trade-offs. Just because something works doesn't mean it scales. It doesn't mean it can handle unexpected user input. It doesn't mean it's easily extensible. Today engineers really just need to define…

> Today engineers really just need to define those high-level technical requirements.

At least within our company, this is quickly becoming what it means to be a software engineer.

Re: Cursor 3

#136
post #116

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 chat interface as a first class citizen and the code itself as a secondary concern. I really don't like that. Even when I'm using AI agents to write code, I still find myself spending most of my time reading and reasoning about code. Showing me little snippets of…

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 iss…

It’s very unfortunate what direction Zed has taken. It was very fast and nice editor, that’s now infected with those “AI” features.

Re: Cursor 3

#137

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 chat interface as a first class citizen and the code itself as a secondary concern. I really don't like that. Even when I'm using AI agents to write code, I still find myself spending most of my time reading and reasoning about code. Showing me little snippets of…

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.

You don't have to stop using the IDE just because you are using Claude Code. Using both at the same time is best of both worlds in my experience.

Re: Cursor 3

#138
post #136
post #116

Earlier quoted context omitted.

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 iss…

It’s very unfortunate what direction Zed has taken. It was very fast and nice editor, that’s now infected with those “AI” features.

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.

Re: Cursor 3

#139
post #116

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 chat interface as a first class citizen and the code itself as a secondary concern. I really don't like that. Even when I'm using AI agents to write code, I still find myself spending most of my time reading and reasoning about code. Showing me little snippets of…

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 iss…

I actually run a custom fork of Zed based on their master branch because of how stagnated the built-in agent is. Master branch Zed agent did get sub-agents, parallel threads, better thread management, and worktrees though, and I implemented agent skills and the ability to select which model to use for sub-agents for it. And with those features, I'm fairly satisfied.

Re: Cursor 3

#140
post #20

What would all these companies do without Microsoft shipping VS Code as open source, probably still stuck with vi and Emacs. Still curious which ones will survive when the AI gold diggers finally settle.

VS Code wouldn’t have won the mid-2010s editor wars if it was closed source (note that VS Code has not helped MS ramp people up to VS itself). The winner of that war was always going to be an open source editor, it was just Microsoft whose concept won out. Closed source editors like Coda failed to gain traction and even Sublime Text fell eventually.

If MS ever decided to discontinue VS Code or relicense it, there would be blood in the water. I guarantee you there would be multiple compelling competitors in under a year and probably a new open source winner with consolidation in 5.

So to answer your question: they would be forking Atom (which I think would’ve won otherwise).

Post reply on HN