Graphite Is Now a Cursor Product: Why Independent Code Review Matters

In December 2025, Cursor announced it was acquiring Graphite, the code review platform behind stacked PRs and the Diamond AI reviewer. By March 2026, the integration was live: Cursor Cloud Agents could create, review, and ship PRs directly inside Graphite. One company now owns both the AI that writes your code and the AI that reviews it.

That's not a scandal. It's a structural incentive problem. And it's the kind of thing platform teams should think hard about before locking in their review toolchain.

What actually happened

Graphite started as an independent code review platform with a sharp focus: stacked PRs, merge queues, and a fast review UI. In March 2025 they raised $52M and launched Diamond, their AI code review agent. Nine months later, Cursor acquired them.

Graphite's CEO Merrill Lutsky framed the deal as building "one integrated platform where humans and agents create, review, and merge code changes collaboratively." The roadmap was explicit: combine Graphite's Diamond reviewer with Cursor's Bugbot, leverage Cursor's coding models to make Graphite's AI features smarter, and ship deep integrations between the IDE and the PR surface.

That vision shipped fast. On March 3, 2026, Graphite launched Cursor Cloud Agents directly inside the Graphite PR interface. A Cursor agent can now create a PR, and Diamond can review it, all within a single product surface. The announcement banner on Graphite's site reads: "Create, review, and ship without leaving your PR."

The structural conflict nobody's talking about

Vertical integration like this makes for a smooth UX. But it introduces a problem that's hard to see on a product demo and hard to ignore once you think about it.

When Cursor's agent writes a PR and Graphite's Diamond reviews it, both sides of that transaction report to the same parent company. They share MAU metrics, revenue targets, and product goals. The more PRs the agent creates and the more PRs that get merged, the better the combined product looks.

This isn't a conspiracy theory. Nobody at Cursor is sitting in a room deciding to rubber-stamp bad code. The problem is subtler than that. It's about architectural incentive alignment: when the entity generating code and the entity reviewing code share a P&L, the review layer has a commercial interest in the code passing.

Think about it from a product metrics perspective. If Diamond starts rejecting a high percentage of Cursor-agent PRs, that makes the integrated product look worse. Users see more failed attempts. Merge rates drop. The "create, review, and ship" loop stalls. There's a natural gravitational pull toward approval, even if no one explicitly optimizes for it.

The same dynamic exists in financial auditing. There's a reason you don't hire your own accounting department to audit your own books. Independence isn't a nice-to-have; it's the entire point of the review.

What independent review actually requires

Independence in code review isn't just about using a different product. It's a set of specific structural properties:

• No shared commercial interest. The company reviewing the code should not benefit financially when the code gets approved. If approval drives up metrics that help the reviewer's parent company sell more seats, that's a conflict.
• Separate deployment surface. Review shouldn't run in the same environment as code generation. When both share infrastructure, there's a risk that telemetry, model weights, or fine-tuning data from the coding side leaks into the review side.
• No telemetry cross-pollination. If the review tool knows which coding agent wrote the PR, it can (intentionally or not) adjust its behavior based on the author. An independent reviewer treats all code the same regardless of origin.
• Source-agnostic ingestion. The reviewer should ingest PRs from any source without knowing or caring which coding tool produced them. Cursor, GitHub Copilot, Claude Code, a human typing in vim: same review, same standards.

Graphite, as a Cursor product, can't fully satisfy any of these. That doesn't make it a bad tool. Graphite's stacked PR workflow is genuinely well-designed, and Diamond catches real issues. But the structural relationship has changed, and that matters for teams that care about review objectivity.

How Tenki handles this differently

Tenki's Code Reviewer has no ownership relationship with any AI coding agent or IDE vendor. Tenki doesn't sell a code editor. Tenki doesn't sell a coding agent. There's no parent company whose revenue goes up when more agent-generated PRs get merged.

The review engine ingests PRs from GitHub. It doesn't know or care whether the diff was authored by a Cursor agent, GitHub Copilot, Claude Code, or someone who hand-typed every line. The same analysis runs regardless. At $0.50 per review, the business model is straightforward: Tenki gets paid when you review a PR, not when you merge one. There's no incentive to rubber-stamp anything.

This isn't a theoretical distinction. As AI coding agents produce more and more PRs, the ratio of agent-generated to human-generated code keeps climbing. Teams are already reporting that 30-50% of their PRs come from agents. If your review tool shares a roof with the agent writing those PRs, you've got a growing blind spot.

The question to ask any code review vendor

Before you commit to an AI code review tool, there's one question that cuts through the marketing:

Do you also sell the AI coding agent whose output you're reviewing?

If the answer is yes, you're dealing with a vertically integrated product where the reviewer has a commercial interest in the code passing. That might be fine for your team. Plenty of organizations prioritize workflow integration over structural independence. But you should make that tradeoff consciously, not discover it after the fact.

A few more questions worth asking:

• Does your review tool share telemetry data with your coding agent?
• Are both products on a unified billing model where usage of one subsidizes the other?
• Can you swap in a different coding agent without losing review functionality?
• Does the review tool adjust its behavior based on which agent authored the PR?

The bigger picture

The Cursor-Graphite deal is part of a broader pattern. As AI coding tools mature, vendors want to own the full lifecycle: write the code, review it, merge it, deploy it. That's a compelling product pitch, but it concentrates trust in a single vendor in ways that developers haven't had to think about before.

Code review exists specifically as a check on the code production process. When you fold that check into the same company that runs production, you weaken the check. Maybe not today, maybe not intentionally, but the incentive structure pulls in that direction over time.

Tenki's position is straightforward: review should be independent from the toolchain that produces the code. If you're evaluating AI code review tools for your team, ask whether the vendor reviewing your code also has a stake in the code getting approved. If they do, you know what you're trading away.