Cursor, Claude Code, Codex: a layered stack, not a winner-take-all

The New Stack published a piece this week arguing that Cursor, Claude Code and OpenAI Codex are not fighting for one seat. They are settling into layers: orchestration, execution, review. It is a thesis, not a release, but it matches what I see in teams that have all three, and it comes with one hard number: Codex now reports more than 5 million weekly users. The interesting question is no longer which tool wins. It is which layer each one owns in your team, and how you stop three subscriptions from turning into three ungoverned accounts.

The three layers

• Orchestration is where a human or a top-level agent decides what to do: breaking a ticket into tasks, choosing a model, holding the plan. This is a terminal-and-repo job, and Claude Code lives here for most teams I work with.
• Execution is the inner loop: edit, run, test, repeat, inside the editor with the developer watching. Cursor's whole product is this loop, and it is still the best-feeling place to do it.
• Review is the asynchronous check: a PR arrives, an agent reads the diff, runs the suite in a sandbox, comments. Codex's cloud mode and its GitHub integration were built for exactly this, which I covered in Codex GitHub code review.

None of these tools is bad at the other layers. All of them are trying to expand into the adjacent ones. But if you place each where it is strongest, the overlap stops being waste and starts being redundancy you can actually use.

Buy one coding agent and you get a tool; place three at different layers and you get a pipeline, provided someone owns the pipeline.

Why this beats picking a winner

The obvious objection is cost and cognitive load. Three tools, three prompts, three ways of doing the same thing. The counter is that the layers have different feedback loops. Execution wants sub-second latency and a human in the loop. Review wants minutes and a sandbox nobody is watching. Orchestration wants long context and a plan that survives across sessions. Forcing one product to serve all three means it serves two of them badly. I ran through the individual tools in AI coding tools 2026 and the editor-level comparison in Cursor vs VS Code Copilot; the layered view is what falls out once you stop scoring them on the same axis.

Governance before the third account

This is where the thesis gets practical. Three tools with three vendor accounts is how a team ends up with no idea what it spends, no idea what code the agents saw, and no way to enforce a policy across them. The 2026 ROI data is blunt about the consequence: 72% of companies have an AI workload in production, only about 29% see significant return, and 56% of CEOs report zero measurable benefit. Teams that measure report 2.5-3.5x ROI on AI coding tools, with the top quartile at 4-6x. The difference is not the model. It is whether anyone is watching.

• One owner for the stack, with a written map of which layer each tool serves and which repos it may touch.
• One enforcement point where possible. Anthropic's inference hooks, in beta since August 5, route every prompt and tool-call response through a customer DLP server for an allow or deny verdict across chat, Claude Code and MCP tool calls, with a shadow mode for rollout. That is the shape of control you want at the orchestration layer, whichever vendor provides it.
• Pinned model versions in every tool. GPT-5.4 and 5.4-mini leave Codex on August 31 and o3 retires August 26; an unpinned config changes behaviour without a commit.
• One cost view built from your own logs, not three vendor dashboards.
• A sandbox for the review layer that cannot reach production secrets, because the reviewer runs unattended.

The honest limit

The layering is a description of today's products, and all three vendors are actively trying to break it. Cursor ships background agents, Claude Code ships review-style workflows, Codex ships an editor extension. In twelve months one of them may genuinely own two layers, and the 5 million weekly users figure is OpenAI's own, not audited. Plan for the layers, but keep the boundaries as configuration rather than architecture, so that when a tool grows into the next layer you can move it there in an afternoon.