SpaceX Bought Cursor: Your Review Gate Can't Live There

On June 16, 2026, SpaceX announced it would acquire Anysphere, the company behind Cursor, for $60 billion in an all-stock transaction. Four days after a record Nasdaq IPO that pushed SpaceX past a $2 trillion valuation, the company exercised an option from an earlier April agreement and locked in the largest AI tooling acquisition in history.

That's the headline. Here's what it actually means for your engineering org: the tool that writes your code, the tool that reviews your code, and the infrastructure those tools run on are now owned by a single defense contractor. If your review gate lives inside that chain, you don't have an independent review gate. You have a feature of the vendor's platform.

The ownership chain, traced end to end

Cursor acquired the code review startup Graphite in December 2025. By March 2026, Graphite had launched Cursor Cloud Agents directly inside its review platform, letting developers create, review, refine, and merge AI-generated code without leaving Graphite's interface. This was pitched as closing the loop from code generation to code review.

Then Cursor announced Origin, a code storage and git hosting product set to launch this fall. That puts Cursor in direct competition with GitHub for repository hosting.

Now trace the chain after the SpaceX deal closes (expected Q3 2026):

1. SpaceX owns xAI (acquired February 2026) and its Colossus supercomputer
2. SpaceX acquires Cursor (the AI coding agent used by millions of developers)
3. Cursor already owns Graphite (the code review and merge layer)
4. Cursor is building Origin (the git hosting and code storage layer)
5. A jointly trained model is already in development, shipping through both Cursor and Grok Build, xAI's coding agent

Code generation, code review, code hosting, model training, and compute infrastructure. One corporate parent. One set of business incentives.

Why the review layer is the one that matters

You can use whatever IDE you want. You can swap out AI coding assistants. Those are editing-time decisions, and they're relatively low-risk because nothing reaches production until it passes the merge gate.

The review layer is different. It's the last automated check before code ships. It decides what gets flagged, what gets approved, and what gets waved through. When the tool that writes the code and the tool that reviews it share the same parent company, the incentive structure bends. Not necessarily through malice. Through product optimization.

A code generation tool wants its output to feel good. A code review tool should be adversarial to that output. When both tools report to the same P&L, the adversarial relationship softens. Maybe the reviewer flags fewer issues on code generated by the in-house agent. Maybe it prioritizes speed-to-merge metrics over defect-detection depth. These aren't conspiracy theories. They're standard product management tradeoffs when two products share a revenue target.

The defense-contractor dimension

SpaceX isn't just a tech company. It holds billions in U.S. government contracts for launch services and satellite infrastructure. That creates a layer of vendor risk that most teams haven't had to think about for their developer tooling.

For teams building products that compete with SpaceX's interests, or teams subject to export controls, or teams whose customers have supply-chain requirements about defense-contractor involvement, the question isn't abstract. Your code, your review decisions, and your merge telemetry now flow through a company whose primary business involves government defense contracts.

SpaceX disclosed in its IPO filing that Cursor's access to developers' coding requests and design decisions could help improve its AI models. That sentence should give every engineering leader pause. Your team's coding patterns, architectural decisions, and review feedback becoming training data for a defense contractor's AI models is a supply-chain fact, not a privacy policy footnote.

A pattern we've seen before

This isn't new territory. Teams learned years ago that in-editor linters can't be the only quality signal. When the editor maker and the linter maker merged, the linter's independence became a product question, not a technical one. Did the linter flag real issues, or did it optimize for keeping you happy inside the editor?

The solution then was the same as the solution now: move the quality enforcement boundary out of the editor and into CI. Run it in a pipeline that the editor vendor doesn't control. Make the merge decision structurally independent of the tool that generated the code.

Cursor plus Graphite plus Origin under SpaceX is the same pattern at a much larger scale. The editor, the reviewer, the hosting, and the model training are all inside one boundary. If your review gate is Graphite, your "independent" review is a product feature of the company that also wrote the code.

What structural independence actually looks like

Independence at the merge gate means three things:

• No shared corporate parent with the code generation tool. The reviewer's business incentive should be catching defects, not smoothing the path for a sibling product's output.
• Runs in CI, not inside the IDE. A review that happens in the same application where code was generated can be bypassed, dismissed, or never surfaced. A CI gate either passes or blocks the merge. There's no "dismiss and continue" button.
• No training on your review data. If your reviewer feeds its findings back into the model that generates code, you've created a closed loop where the generator learns to avoid triggering the reviewer rather than generating better code.

Tenki's Code Reviewer is built on this separation by design. It runs as a GitHub Actions step, outside any IDE vendor's control. It isn't bundled with a code generation tool, doesn't share a corporate parent with one, and explicitly doesn't train on your code or review data. When Tenki flags an issue on a pull request, that finding comes from a reviewer whose only business incentive is catching defects.

That's not a marketing distinction. It's an architectural one. The review gate sits in your CI pipeline, reports as a GitHub status check, and blocks merges based on configurable severity thresholds. Whether the code was written by a human, by Cursor, by Copilot, or by Claude, it hits the same gate.

The numbers behind the independence argument

Independence alone doesn't matter if the reviewer can't actually find bugs. Tenki publishes its benchmark results openly, and the gap with Graphite is stark:

• Tenki: 68.9% recall, 29.9% precision, 41.7 F1
• Graphite: 3.3% recall, 50.0% precision, 6.2 F1

Graphite's 3.3% recall means it misses roughly 97 out of every 100 real issues. Its precision is decent when it does flag something, but a reviewer that almost never flags anything will always look precise. The F1 score, which balances both, tells the real story: 6.2 versus 41.7.

Those numbers existed before the SpaceX acquisition. The ownership change doesn't make them worse, but it does make the question of who your reviewer reports to a lot more pressing.

What teams should do now

You don't have to stop using Cursor. It's a good coding agent, and SpaceX's compute resources will probably make it better. Use whatever IDE helps your developers move fast.

But treat the review gate as a separate vendor decision. Don't let it follow the IDE choice by default. Specifically:

• Audit your review toolchain's ownership. If you're using Graphite for code review, you're now routing review decisions through a SpaceX subsidiary. Decide whether that's acceptable for your team's risk profile.
• Move your quality gate to CI. A required status check in GitHub that runs on your CI pipeline is structurally harder to compromise than a review that lives inside the IDE or on a platform owned by the IDE vendor.
• Check your data policies. SpaceX's IPO filing explicitly noted Cursor's developer data as a model training asset. Review your agreements and confirm whether your code and review feedback are being used for training.
• Evaluate vendor independence as a design requirement. The SpaceX-Cursor deal won't be the last consolidation in AI tooling. Build your pipeline so the review layer can be swapped without touching the code generation layer, and vice versa.

The $60 billion deal is done. The ownership chain is clear. The question for engineering teams isn't whether this consolidation matters. It's whether your merge gate is inside it or outside it.