The IDE is now the model: what vertical integration means for code review

Two releases shipped within 48 hours of each other on August 4–6, 2026. Cursor Research published Mixture-of-Kittens (MoK), a custom mixture-of-experts training kernel that increased end-to-end training throughput by 41% on 512 GB300 GPUs. Zed announced early access for DeltaDB, a storage layer that captures every code operation between commits and attaches each change to the agent conversation that generated it. Neither release is incremental. Together they mark a structural shift in what IDE vendors actually are.

What Cursor shipped and what it means#

MoK is not a model. It is the infrastructure Cursor built to train Composer, its agentic coding model, more efficiently on Nvidia GB300 NVL72 racks. The kernel fuses all MoE communication and computation into a single deterministic kernel, eliminating the bottleneck that had consumed more than half of end-to-end training time. Against the fastest public baseline, MoK achieves up to 2.37x higher MXFP8 forward throughput on single-layer benchmarks. The production number, measured across multiple NVL72 racks with 512 GPUs, is 1.41x tokens per second over the previous DeepEP-based stack.

Cursor now runs that kernel across tens of thousands of GPUs to train Composer. The MoK paper cites Kimi K2.7, GLM, Qwen, and DeepSeek-V3 as the model shapes against which benchmarks were run. This is not a company using third-party model APIs with a thin editor wrapper on top. Cursor is doing original kernel research to train its own coding model at scale.

What Zed shipped and what it means#

DeltaDB, announced August 6 by a report citing Niklas Berg, sits below Git. Traditional version control centers on commits: developers edit files, stage a snapshot, push. DeltaDB targets the work that happens between those checkpoints, capturing every code operation and linking each one to the agent conversation that produced it. Developers can branch from any point in a project's history, including in-progress work, not just from commits.

The practical consequence: Zed now has a record of which agent suggestion produced which line, at sub-commit granularity. That data is potentially training signal. Whether Zed uses it that way is a separate question, but the infrastructure to do so exists.

The procurement question has changed#

Until recently, choosing an AI coding tool was roughly equivalent to choosing which frontier model API to route through. That framing is now wrong for at least two vendors.

Cursor owns a training kernel, a production GPU fleet, and an agentic coding model (Composer) trained on that fleet. Zed owns the storage layer beneath the editor, capturing agent-to-code attribution at a level Git never could. The procurement question for engineering leaders is no longer "which model does this IDE use." It is: what parts of the stack does this vendor control, and what data flows through each layer.

This matters for procurement for straightforward reasons. A vendor that controls storage, telemetry, model training, and editor behavior occupies a different risk category than one that wraps an external API. Data handling terms, subprocessor disclosures, and security review should reflect that difference.

Why review independence is the right response#

The more immediate concern for engineering teams is architectural, not contractual. When the tool that writes code also trains the model on the codebase's telemetry and agent interactions, using that same tool for code review creates a closed loop with no external check. A reviewer that shares training data with the generator will not reliably catch the generator's systematic blind spots. Research published August 4 by LeadDev found that pairing Claude with a mismatched AI reviewer dropped its solo pass rate from 91.4% to 82.8%, and that Codex fixed 3 of Claude's failures while breaking 13 correct solutions. Reviewer-generator independence is not a soft preference; it has measurable correctness consequences.

The practical implication: code review must run on infrastructure with no data-sharing relationship to the code generation tool. That means different vendors, different training pipelines, different telemetry endpoints. It also means the review surface should operate at the repository level rather than the session level, so it sees accumulated patterns across all commits rather than the local context of a single agent conversation.

Hyrax runs as a repository-level review surface with no dependency on any IDE vendor's model or storage layer. The review surface is separated from the generation surface by design.

What to configure now#

Teams using Cursor, Zed, or similar vertically integrated tools should take three concrete steps. First, audit data handling agreements with any IDE vendor that owns both storage and model training. The scope of what counts as training data is now wider than most DPAs written two years ago anticipated. Second, confirm that CI-level code review runs on a vendor-independent surface. A GitHub Actions workflow that calls the same model family used to write the code is not independent review. Third, establish a commit-level audit trail that does not depend on the IDE vendor's storage layer. DeltaDB's sub-commit attribution is useful for debugging agent behavior, but critical security and quality review should not rely on infrastructure controlled by the same vendor producing the code.

The vertical integration Cursor and Zed have now demonstrated is not inherently a security problem. It is a supply-chain fact that changes the threat model. Teams that treat their AI coding tool as a thin client and their review tooling as independent infrastructure are well-positioned. Teams that have collapsed both onto the same vendor stack are not.

Hyrax is live at hyrax.dev.