Cursor Composer 2 Arrives. The Week After the CEO's Warning. Lining Up SiliconANGLE and The Register's Opposing Verdicts to Build a Standard for Trust

It’s Gen. Let’s talk about “trust or doubt”

It was just last week that I wrote the article on Cursor’s CEO warning that “the foundation is shaking”. In that piece, I proposed three design principles for escaping tool dependency.

The very next week, Cursor made its move.

A new feature called “Composer 2.” An update that ships a dedicated AI model specialized for programming.

SiliconANGLE reported it favorably as “an evolution.” Meanwhile, The Register threw out the question, “Can we really trust it?”

Opposite verdicts on the same product.

I have no intention of declaring which one is right. Instead, I read both articles carefully and decided to build my own standard for judgment. As one user who keeps paying Cursor $20/month (about ¥3,000).

A new model launched the week after the CEO’s “shaking” remark. What’s going on?

One week after its own CEO’s warning, Cursor announced Composer 2 with a dedicated AI model. Behind it lies a sharp shift in market share.

CEO Michael Truell told Fortune that “vibe coding has a shaking foundation.” It was an unusual statement: the person leading a product with annual revenue of $2B (about ¥300 billion) speaking openly about the risks himself.

And yet, the very next week, he shipped Composer 2.

It might look contradictory. But here’s how I read it: “We admit the foundation is shaking — and we’ll be the ones to build the new foundation.” A declaration, in other words.

There’s data that backs up the urgency of this move. A survey by Pragmatic Engineer of 906 developers. The most-loved AI coding tool: Claude Code took first place at 46%. Cursor stayed at 19%.

Eight months ago, Cursor was dominant. Now the positions have flipped.

I feel it myself — my Claude Code usage time grows month after month. The reason is simple: from the terminal, a single instruction takes it all the way from creating files to running tests. Cursor’s code completion is excellent, but on the “autonomous agent” arena, Claude Code has the edge.

Composer 2 is probably a move to stop this trend. The CEO’s warning and the new release aren’t a contradiction — they’re two sides of the same sense of crisis. Read that way, it all lines up.

For Cursor, valued at $9B (about ¥1.3 trillion), a share reversal is an existential issue. Investors and developers are watching. They were pushed into a position where they had to play “the next card.”

The question is whether this card will actually work. SiliconANGLE and The Register gave completely different answers.

Timeline diagram of "CEO warning → 1 week → Composer 2 release." Top row: Fortune interview date, bottom row: SiliconANGLE coverage date. Pragmatic Engineer share data in the background

What SiliconANGLE saw as “evolution”

The heart of Composer 2 is that it reduces dependence on external general-purpose models and brings a programming-specialized completion model in-house.

Reading SiliconANGLE’s coverage, three points stood out.

A dedicated model on board. Until now, Cursor stood as a “middleman” calling external models like Claude or GPT. Composer 2 embeds its own model specialized for code completion. There are reports that it improves “completion grounded in the context of the entire project,” something general-purpose models struggle with.

In other words, Cursor is trying to shift from “a tool that borrows other companies’ AI” into “a platform with its own AI.”

Stronger long-context handling is also notable. Even on large codebases, cross-file references are said to be more accurate. For someone like me who builds internal business tools, edits that span multiple files are everyday work. If this improves, the felt impact is going to be big.

Faster response is also reported. By going with a dedicated model, the API round trips shrink, and code completion responses get quicker. Less time staring at the “thinking…” indicator translates directly into coding rhythm.

This matches my own experience. When developing internal business tools in Cursor, completions through the API came with 1–3 seconds of waiting. Just a few seconds, you might think. But a “pause” while coding breaks the flow of thought. If a dedicated model cuts this lag, the feel will change a lot.

If I had to summarize SiliconANGLE’s tone in one line: “Cursor is pivoting from middleman to platform.”

I personally resonated with this direction. The era of just riding on top of external models will end someday. The stance of trying to own your own tech stack — I get it, as a former dropout who once admired professional engineers. Fight not with “borrowed gear” but with “your own gear.” I have respect for that resolve.

The question is whether the reality matches the signboard. The Register pokes at exactly that point.

Comparison diagram of Composer 1 (architecture dependent on external APIs) and Composer 2 (architecture with a built-in dedicated model). Arrow directions and thicknesses visualize the change in dependencies

The skepticism The Register raised

The criticism focuses on two points: “Is it training on user code?” and “Is it prioritizing speed over quality?”

The Register’s reporting is the opposite of SiliconANGLE’s. It takes the doubts behind the praise head-on.

The weightiest point is the privacy issue. Cursor’s mechanism sends the code users write to a server to generate completions. If they “built” the dedicated model “in-house,” where did that training data come from? This suspicion has been debated repeatedly in developer communities for some time.

Cursor’s terms of service clearly state that “we do not use your code to train our models.” But The Register points out that “there’s no external way to verify that the terms and the implementation match.” A lack of transparency breeds distrust.

For contrast, let me bring up Claude Code. Anthropic publicly declares that it does not use conversation data to train its models, and has also obtained SOC 2 Type II certification. Whether or not third-party verification exists is a point directly tied to trust.

The other criticism is quality stability. Right after Composer 2’s release, developer forums reported code completion bugs and editor freezes. Is the push to ship new features fast coming at the cost of stability? The Register asked, “Are paying users at $20 being forced to beta test?”

I have my own memory of this kind of complaint. I’ve had Cursor’s completions go off the rails a few times. The cold sweat when half a file got overwritten with unintended code — I won’t forget it.

Let me reproduce it concretely. I was editing a React component and gave an instruction to Composer: “Add validation to this form.” It rewrote three related files at once. But the existing state management logic was completely gone. I only caught it because I checked the diff in Git. The thought of what would have happened if I’d deployed it without noticing still makes me shudder.

Even for someone like me whose motto is “if it works, it’s fine,” “deleted without permission” is a different story. This shows that vibe coding’s “comfort” and “danger” are paper-thin apart.

To summarize The Register’s tone: “Cursor sells speed and innovation — but isn’t it putting trust and stability on the back burner?” This perspective can’t be ignored.

Two-column diagram of the two doubts The Register raised. Left column "Privacy: code sent → used for training?" Right column "Quality: new-feature speed prioritized → instability"

The “three axes of tool trust” that emerged from both sides

Judge along three axes — performance, transparency, and exit cost — and you’ll stop being thrown around no matter which tool shows up next.

After laying SiliconANGLE and The Register side by side, I organized my own judgment criteria. Debates over tool choice tend to get emotional. Instead of picking sides — “Team Cursor” or “Team Claude Code” — it’s healthier to evaluate flat along three axes.

Axis 1: Performance. Completion accuracy, response speed, and the ability to understand the full project context. Composer 2 is indeed reported to be improved. But “reported” and “felt firsthand” are different things. Spend a week trying it on your own project and see if you actually feel the improvement on your skin. That becomes the material for your judgment.

Axis 2: Transparency. How is the code handled? How is it used for model training? Are there mechanisms for external audit? This is the area where Cursor and Claude Code show a clear gap. Whether SOC 2 certification exists, how concrete the terms of service are, how openly data processing policies are published. Hold these as checklist items.

Axis 3: Exit cost. If you become dependent on a tool, how expensive is it to switch? Cursor is based on VS Code, so settings and extensions are reasonably portable. On the other hand, optimize too hard for Composer-specific workflows and the relearning cost when migrating balloons.

The “three layers of tool dependency” from the previous CEO-warning article overlap with these evaluation axes. Operation dependency, knowledge dependency, design dependency. Know which layer you depend on, and you can estimate exit cost yourself.

If I put these three axes into a table, the current comparison sorts out like this.

Axis	Cursor (Composer 2)	Claude Code
Performance	Dedicated model improves completion accuracy (needs verification)	Strong at autonomous agent execution
Transparency	Denied in terms of service, but no external audit	SOC 2 Type II obtained
Exit cost	VS Code based, settings portable	CLI-based, lightweight config files

This isn’t about which one is “correct.” Depending on which axis you weigh, the answer changes. If performance matters most, Composer 2 is worth trying. If transparency comes first, the edge goes to Claude Code.

Now that OSS tools are rising, the list of exit destinations has clearly grown. The era of locking yourself into one tool is ending.

Which type are you? Decide today’s move using the four exit categories

Status quo, gradual migration, hybrid, wait-and-see — your “do this today” changes by type.

If you’ve read this far and are thinking “Okay, but what should I actually do?” — check which of these types you’re closest to.

Type A: Status quo. Satisfied with Cursor’s performance, and consider the privacy risk acceptable. Do today: update to Composer 2 and log how performance changes on your own project for a week. If satisfaction rises, deciding to keep using it is fine.

Type B: Gradual migration. Has high interest in Claude Code or terminal-style tools. Do today: try one small task on Claude Code’s free tier. The comparison article on Cursor’s $20/month vs. free tools can also serve as judgment material. Don’t fully migrate — start with the feeling of “putting one foot in.”

Type C: Hybrid. Wants to use different tools for different jobs. Do today: split roles like “Cursor for code completion” and “Claude Code for agent execution.” Try it for a week and log which one you used more. The reality of your usage will come into view.

Type D: Wait-and-see. Feels there isn’t enough material to decide yet. Do today: nothing. Just bookmarking this article is enough. A month from now, when Composer 2 user reviews have piled up, judge again.

There’s something I want to say to all four types in common. Build the habit of writing a DESIGN.md (design document). When the tool changes, if the design remains, migration isn’t scary. This is exactly the “tool-agnostic design principle” I proposed in the previous article.

I’m currently in a position close to Type C. Cursor for code completion, Claude Code for agent execution, and I’ve also started trying OSS tools. Paying for three is honestly tough. But I believe that once this “comparison experiment period” ends, the tool configuration that fits me will come into view.

One thing I learned in my CS (customer success) days is: “compare tools before you choose.” Tools introduced because sales told you to — they basically went unused within half a year. Touch them with your own hands, verify them in your own work. The people who don’t begrudge that effort come out best in the end.

Flowchart of the four exit categories. "Satisfied with Cursor's performance?" → Yes/No branch, "Prioritize transparency?" → Yes/No branch, ending at Type A/B/C/D

Wrap-up

I read Cursor Composer 2 as an attempt to “rebuild the foundation ourselves,” in response to the CEO’s warning.

The evolution SiliconANGLE saw might be real. The Register’s skepticism has its grounds too. Believing only one side is risky.

The judgment criteria I organized are the three axes of “performance, transparency, and exit cost.” Apply these three to your own project, and you’ll stop riding the highs and lows of tool choice.

What I’m sure of, as a former-dropout engineer, is that tools will always change. Coding that I once walked away from — thanks to AI, I was able to come back. That experience isn’t tied to any specific tool. Whether Cursor or Claude Code, the joy of “being able to build things with my own hands” was the same.

That’s exactly why you don’t need to be thrown around by tool reviews. Both SiliconANGLE’s praise and The Register’s skepticism are, in the end, just “someone else’s judgment criteria.”

If you have your own design and your own judgment criteria, you’re fine. Whichever tool comes next, your code remains. What you built doesn’t disappear when the tool changes.

Next time, I plan to dig into the practice of DESIGN.md-driven development. I want to introduce — with code from an actual project — “why writing the design first raises AI’s code generation accuracy.” As Technical Edition #4, it’ll be content that touches the core of this series.