Can Cursor come back from this?
Microsoft is gunning for Cursor, what options do they have? Can Gitlab save Cursor?
Over the past few days Microsoft has let loose a direct broadside into Cursor’s business model (as well as every other VSCode AI plugin caught in the crossfire). Two big things happened in rapid succession:
Microsoft added Cursor-like agentic workflows to VSCode, powered by MCP
Microsoft is pulling back licensing on various language extensions that used to be free
(more of a 2.5) Microsoft revamped their pricing to enable more fancy model usage, including a new $40 tier with 5x the large model usage, and pay as you go.
(Why Github defaults this usage to 4o when everyone else is using Claude I don’t understand, likely because it’s cheaper for them via the Microsoft deal.)
Cursor is a record breaking unicorn, recently valued at nearly $10 Billion dollars, and Microsoft pulled the rug right out from under them. Did they see this coming and properly prepare? I suppose we’ll find out, but at first glance it looks ugly.
So where is Cursor’s moat now:
People who don’t like Microsoft
People who don’t care about Microsoft’s C#, C and C++ extensions
Being better at picking which model to use when, and making those models perform the best.
A pretty big install base, already approved in many organizations
Good RAG tech
The first two aren’t very exciting, but the third might be. Microsoft also has a way of attacking fast and then getting bored and moving off to something else. I like to say they can only focus on one thing at a time. It’s very possible that if Cursor can make itself the easiest to use, drop in and just works great, and then leverage that into less sophisticated programmers and maybe even product people, it could be a big deal.
The install base is worth mentioning, they have momentum, but it’s fleeting. They have to figure out the path forward quickly.
The RAG tech is a incredibly important and if they can remain better at this it will be a clear differentiator. This is the actual hard problem of GenAI coding, even with very large context windows the models don’t perform very well if you just dump the entire source tree in. Not to mention that it’s incredibly expensive to fill a huge context window every call. Code represents an arbitrary graph with cycles, and so it’s very complicated to model. Being good at figuring out what needs to go into context will be a major differentiator across the board in GenAI tooling for a good while to come.
It seems to me that the next move for Cursor has to break the dependency on Microsoft, it’s clearly a major weakness. I’m sure at this very moment the Microsoft team is brainstorming new ways to use this leverage. They can run with the fork, but they should root out all sources of dependency on Microsoft.
They should lean into “the best at being easy to use”. Microsoft is typically bad at making things easy to use, instead opting to make things complicated but meet all of their enterprise client’s needs. They can still win on this, like how Slack is still clearly much easier to use than Teams. They can still be the slack of Gen AI Dev tooling.
Microsoft also clearly has a major potential advantage with GitHub itself. Github hasn’t yet been substantially exploited. Clearly AI for the rest of the dev lifecycle is coming, and there are throngs of AI startups foaming at the mouth for a piece of that. Will Github be able to deliver in a major way there, or will they have to open up yet another front in the AI dev tooling wars? If I were them I’d be dumping money into that side as well, they could make VSCode and most desktop tooling completely superfluous supporting the entire AI driven workflow in the browser. Think of how nice that would be for the rest of the workflow.
Potentially Cursor could partner or even merge with Gitlab and work on a real end-to-end offering. This would fix Gitlab’s biggest weakness: being terrible at AI, and then give Cursor that home field advantage as well. I don’t expect that this will happen, but it seems clearly like the biggest power play. In the end if they can’t get a foothold in a source and ticketing management tool their potential utility will clearly be capped compared to the Github offering.
I would not count on Gitlab saving Cursor. If anything, the other way around.
Cursor has the install base to get very good (and is probably doing this!) at being smart about context window management when decomposing larger problems that deal with complex codebases. One thing to remember is that the context window rag optimization stuff has to be pretty tuned on a per LLM basis. Given they already are working on "let Cursor pick the model", they could hyperspecialize towards the ones they have the most experience with and not have to solve for all of them each release which really can slow things down.
This is similar to what I was thinking, a match made in heaven. Gitlab as it is right now is likely doomed with no one to support them from the AI side. They are manifestly bad at it.