Progress has been very frustrating over the past two days. Not only have the projects I'm working on repeatedly stalled without progress, but a single oversight also broke a previously functioning project. After a full day of effort, I couldn't restore it and have to find a way to rebuild.
In fact, such examples are ubiquitous among Cursor users—and not just Cursor, but anyone using other "vibe coding" agents will encounter this.
You can't really blame Cursor. As one of the earliest "wrapper" tools (the other being Perplexity), its upper limit is ultimately the underlying model—like the current "coding champion," Claude 3.7.
No matter how fancy the Agent talk gets, in various practical scenarios, the capability remains limited by the base model itself.
However, even with the same base model, the capabilities of "wrapper" applications are now significantly lower than those of the native model applications.
Take Cursor as an example: using the same Claude 3.7 and processing the same document, the native Claude app can generate beautiful visualizations in its "artifacts," whereas in Cursor, it often takes numerous attempts and still struggles to come close.
One is an absolute master-level output:
Back in Cursor, with the same prompt, all I saw was constant failure.
Actually, the issue isn't complicated at all:
- Since roughly the fourth quarter of last year, OpenAI, Anthropic, and Google have made building applications around their models a top priority. The integration between their applications and their own models is naturally much higher than that of "wrappers."
- API limitations: although the models might be identical, API calls still face many constraints.
Of course, even under these constraints, applications like Cursor still have their own core competitive advantages:
- Cursor has its own fine-tuned models that are more aligned with coding habits;
- The Agent workflow has been extensively optimized, making the development process very smooth most of the time—this smoothness is what "vibe coding" is built upon.
However, it will ultimately face massive challenges. Google has launched Firebase Studio based on Gemini. While its current capabilities still seem significantly behind Cursor's, its features are distinct:
- Development in an online environment, meaning you can do vibe coding anytime via mobile. I find myself vibe coding more and more on buses, subways, and park benches; online environments will become increasingly important.
- Blazing fast code generation speed. Token generation speed has been a huge advantage for Gemini models since version 2.0; in the context of coding, this is pure productivity.
Perhaps, given Google's speed in turning things around—from lagging behind to the full-scale counterattack of Gemini 2.5—Firebase Studio might catch up to Cursor in no time.
The Cursor team needs to think hard about how to respond. Actually, since the start of this year, my use of Obsidian has dropped significantly. My current tool environment basically consists of the applications of the big three models plus Cursor. I increasingly need an All-in-One IDE.
Yes, a wrapper is just a wrapper. As base models deepen their application layers, the survival space for third-party wrappers is shrinking.
But startups can still gain an edge through more focused capabilities and flexibility. Perhaps catching that edge two or three times in a row could provide a foundation for survival.
As I was writing this article, Cursor finally completed the task mentioned above. It simply cannot integrate with its model as well as the native Claude app, but if given enough attempts and "full-process guidance," it can still yield decent results.
Nevertheless, a wrapper remains a wrapper. Above the models, we indeed need tools, yet this has become a territory where the best model companies and startups are moving from collaboration toward competition.