> 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.
Hello Lee, incredibly honored, huge fan of your work at vercel. The nextjs tutorial is a remarkable s-tier educational content; it helped me kickstart my journey into full-stack dev to ship my research tools (you might appreciate the app router love in my latest project: https://github.com/ischemist/syntharena).
On substance: my critique is less about the quality of the retrieval tools (ripgrep/semantic search are great) and more about the epistemic limits of search. An agent only sees what its query retrieves. For complex architectural changes, the most critical file might be one that shares no keywords with the task but contains a structural pattern that must be mirrored. In those cases, tunnel vision isn't a bug in the search tool but in the concept of search vs. full-context reasoning.
One other friction point I hit before churning was what felt like prompt-level regression to the mean. For trivial changes, the agent would sometimes spin up a full planning phase, creating todo lists and implementation strategies for what should have been a one-shot diff. It felt like a guardrail designed for users who don't know how to decompose tasks, ergo the conclusion about emphasis on vibe coders.
That said, Cursor moves fast, and I'll be curious to see what solution you'll come up with to the unknown unknown dependency problem!
I would have appreciated if he asked me before using my name in the post. Especially after I intentionally did not mention them by name at all. Was trying to avoid talking about any one company.
Fair point, we appreciated that courtesy, and I should have reached out first. That was a miss on my part.
My thinking was that it became public pretty quickly once your post went viral (folks were already connecting the dots in the replies), and it felt awkward to respond to the substance without being direct about the context.
But you're right that a heads-up would have been the better move.
Your original post was very public under a very well known brand - you have no expectation of privacy after that. People are going to respond to you publicly.
It's not about a privacy, but common courtesy. Especially after I gave them a heads up in DM about the post and offered to answer any more questions they had. They said they'd reach back out, then didn't, then posted this publicly? Really strange.
(I wrote the original post) I'm a developer, but you can call me a marketer if you want. I don't think it changes the point of my post.
The point was that bad abstractions can be easily replaced by AI now, and this might work well for some people/companies who were in a similar situation as me. I was not trying to say you don't need a CMS at all. In fact, I recommended most people still use one.
What you describe as an "extremely brittle proprietary system" is working great for us, and that's all that I care about. I don't "love to build software" for the sake of building software. The post is about solving a problem of unnecessary complexity.
1. Checkpoints/rollbacks are still a focus for us, albeit it's less used for those working with git. Could you share the bug you saw?
2. Autocomplete for prompts was something we were skeptical of as well, but found it really useful internally to save time completing filenames of open code files, or tabbing to automatically include a recently opened file into the context. Goal here is to save you keystrokes. It doesn't use an LLM to generate the autocomplete.
3. A lot of folks don't want to juggle three AI subscriptions for coding and have found the Cursor sub where they can use GPT, Claude, Gemini, Grok models to be a nice balance. YMMV of course!
I find the amount of credits included in the pro subscription per month totally insufficient. Maybe it lasts 1-2 weeks.
Today I got a message telling me I exhausted my subscription when the web dashboard was showing 450/500. Is there a team level constraint on top of individual ones?
Addressing 2) first: That's good, I totally misunderstood then, and guess I'll need to try it to understand what's new since I thought that kind of tabbing had been there a while.
Back to 1): The type of bug I see most often is where conversation history seems incomplete, and I have trouble rolling back to or even finding a previous point that I am certain existed.
Git shares some features but I think Git was not made for the type of conversational rapid-prototyping LLMs enable. I don't want to be making commits every edit in some kind of parallel-git-state. Cursor's rollback and branching conversations make it easy to backup if a given chat goes down the wrong path. Reapply is tedious since it has to be done one edit at a time - would be nice if you could roll-forward.
I haven't put much thought into what else would be useful, but in general the most value I get from Cursor is simplifying the complex state of branching conversations.
FWIW, my workflow with git is to stage changes I want to keep after every prompt. Then I can discard changes in the working area after a bad prompt or stage individual changes before discarding from the working area. Works really nice for me.
i really tried to use cursor and really wanted to like it but i constantly ran into this problem where the agent wasnt able to see what was happening in the terminal.
Since we have cursor people joining, let me bring up my constant problems around applying code changes. For background, I mostly work with "chat":
1. The apply button does not appear. This used to be mostly a problem with Gemini 2.5 Pro and GPT-5 but now sometimes happens with all models. Very annoying because I have to apply manually
2. Cursor doesn't recognize which file to apply changes to and just uses the currently open file. Also very annoying and impossible to change the file to which I want to apply changes after they were applied to one file.
For both of these scenarios, it seems to happen when the context limit is getting full and the context is summarized. I've found it usually works to respond with the right file, i.e. "great, let's apply those changes in @path/to/file", but it may also be a good time to return to an earlier conversation point by editing one of your previous messages. You might edit the message that got you the response with changes not linked to a specific file, including the file path in that prompt will usually get you back on track.
> 2. Autocomplete for prompts was something we were skeptical of as well, but found it really useful internally to save time completing filenames of open code files, or tabbing to automatically include a recently opened file into the context. Goal here is to save you keystrokes. It doesn't use an LLM to generate the autocomplete.
Oh ok, thanks for clarifying. That indeed seems like would be helpful.
Should still be configurable to turn off though (like any auto-complete, right)
> 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.
reply