Claude Code, Cursor, and the AI-coding stack we reach for

Last updated: July 2026

The AI-coding tool question that consumed 2024 and 2025 has effectively resolved. 70% of senior engineers in 2026 use two to four AI coding tools simultaneously, not one. The interesting question is no longer "which tool wins" — it is "which tool for which task." This post is the stack our senior engineers actually reach for through a normal working day, why each one wins its slot, and where the boundaries between them sit. It is a cluster child of our 70%-AI-generated codebase pillar.

Key takeaways

  • The stack is layered by task type, not chosen by preference. IDE-inline for quick edits, CLI agents for heavy refactors and greenfield features, PR review agents for the merge gate, autonomous agents for scoped background work. Each tool wins at what it is shaped for.
  • Cursor for daily editing, Claude Code for heavy sessions. This is the pattern that has settled among senior teams. Cursor stays in the editor and moves fast on the small stuff; Claude Code takes over when the change is architectural or spans many files.
  • Subagents are what makes CLI tools scale. A single AI agent hits its context limit fast on a real codebase. The subagent pattern — dispatch specialised sub-agents for specific classes of work, aggregate their outputs — is how CLI tools handle work that IDE agents cannot.
  • Cost per PR is now a metric worth tracking. Prompt caching, subagent choice, and model routing between them change per-PR cost by 5-10x. Teams that do not track it are leaving substantial spend on the table.
  • The IDE is not going away. Autonomous coding agents got most of the 2026 press, but the daily driver for senior engineers is still an IDE with an AI assistant. The reason is judgement — the human wants to see what happens as it happens, not read a report at the end.

The four slots in the stack

Every senior engineer we talk to describes a similar four-slot mental model.

Slot 1 — IDE-inline assistant. The always-on, per-keystroke completion and inline suggestion tool. Cursor, GitHub Copilot, JetBrains AI. This is the slot the engineer spends the most hours in, and the tool has to be low-latency, non-intrusive, and easy to override.

Slot 2 — CLI coding agent. The heavier tool the engineer reaches for when the work is beyond what fits into inline suggestion. Claude Code, Codex CLI, Gemini CLI. Multi-file changes, greenfield features, architectural refactors. Runs in a terminal alongside the IDE, with access to the whole repo.

Slot 3 — PR review agent. The multi-agent reviewer that runs when a PR opens. Anthropic's Claude Code Review, GitHub's Copilot PR review, third-party review tools. Runs asynchronously, comments inline, gets merged into the review discipline described in the 70%-AI-generated codebase pillar.

Slot 4 — Autonomous background agent. The tool that takes a scoped task and runs to completion without engineer intervention. Devin, various Anthropic and OpenAI offerings, in-house agents built on top of Claude Code. Used for bounded, well-specified work — dependency updates, test coverage expansion, boilerplate migrations.

The stack is layered because the tasks are different. Trying to make one tool win all four slots is what produced most of the 2024 disappointment with AI coding. Accepting that the tools specialise is what makes the stack productive.

Slot 1: IDE-inline — Cursor is the default, GitHub Copilot the fallback

The pattern that has settled in 2026: Cursor for daily editing, Copilot only when the customer's environment does not allow Cursor. The differentiators.

Cursor's Composer surface — multi-file inline editing without leaving the IDE — is where senior engineers spend most of their AI-coding time. It fits the review discipline: the engineer sees each suggestion, accepts or rejects it, moves on. The latency is low enough that it does not break flow. The scope is bounded enough that the engineer does not lose track of what changed.

GitHub Copilot is the fallback because it works everywhere GitHub works — including in enterprises that have not approved Cursor. The daily-driver experience is a step behind Cursor's, but Copilot has better organisation-wide policy controls, which matters for enterprise procurement.

The one place inline assistants lose is when the task is bigger than a few files. Then the engineer moves to slot 2.

Slot 2: CLI — Claude Code owns the heavy slot

The heavy slot is the one that changed the most in 2026. Claude Code emerged as the default for architectural work and multi-file refactors, with Cursor's Composer covering the middle ground. The differentiators.

Claude Code runs in a terminal, has access to the whole repository, and — most importantly — supports the subagent pattern. When a task requires context that will not fit in one agent's window, Claude Code dispatches specialised sub-agents for specific classes of work. A refactor across 30 files becomes ten paired-up sub-agents rather than one overwhelmed one.

The other Claude Code feature that matters: /loop, the automated test-run-and-refactor cycle. The engineer gives it a failing test and Claude Code iterates until the test passes. This is what makes tests-first at 70% AI-generation practical — the AI writes the implementation, runs the tests, fixes what breaks, and reports back when it is green or when it cannot make it green.

Codex CLI and Gemini CLI compete in the same slot. The choice between them is usually about the model the team already has enterprise access to, not about a substantive capability gap.

Slot 3: PR review — the multi-agent shape has won

The pattern that settled in 2026: multi-agent review at PR open time. Anthropic's Claude Code Review is the reference implementation, launched March 2026. When a PR opens, a fleet of specialised agents examines the diff — one per class of issue (logic errors, boundary conditions, API misuse, security, project conventions). A verification step tries to disprove each finding before it posts. The surviving findings become inline PR comments the human reviewer sees at review time.

The design decision worth naming: the review agents are separate from the coding agents. Not because the model cannot review its own work — it can — but because the review discipline benefits from the review agents having a different system prompt, a different set of allowed tools, and a different failure mode. The reviewer that catches a bug is not the writer that made it.

GitHub Copilot ships a similar surface, tuned for GitHub-native workflows. Third-party tools compete on specific niches (security-focused review, compliance-focused review). The multi-agent shape is the winning pattern across all of them.

Slot 4: Autonomous background — bounded scope only

The slot that got the most 2026 press and delivers the least reliably. Autonomous coding agents work well when the task is bounded, well-specified, and does not depend on judgement calls that only the senior engineer can make. They work badly when either half of that is missing.

The tasks that succeed:

  • Dependency updates. Well-scoped, testable, mostly boilerplate. Autonomous agents nail it.
  • Test coverage expansion. Given a code file and a coverage target, an autonomous agent generates the tests. The human reviews the diff.
  • Boilerplate migrations. Framework upgrades, API version changes, style-guide sweeps. Bounded, high-volume, low-judgement — exactly the shape.

The tasks that fail:

  • Anything with a design decision embedded. The autonomous agent picks a design that looks plausible, gets it wrong in a way that only shows up two weeks later.
  • Anything that spans a merge conflict. Autonomous agents cannot yet reliably navigate a codebase where their assumptions have been invalidated by another engineer's work.
  • Anything security-critical. The autonomous agent cannot own the judgement about acceptable risk. That is a Layer 3 human call — see the 70%-codebase pillar.

The teams that get autonomous agents to work in 2026 use them for the bounded tasks only, with a strict review discipline on the diff.

The cost economics

Cost per PR became a real metric in 2026. The moves that change it:

Prompt caching. Claude Code and Cursor both support prompt caching. On a repo where the same set of files gets re-read across many AI calls, caching cuts cost by 60-80% — the same numbers from our token economics post applied to the coding case.

Subagent choice. A subagent that runs on a smaller, cheaper model for straightforward classification tasks and reserves the top-tier model for hard reasoning saves substantial cost. This is model routing at the coding-tool layer.

Autonomous vs interactive. Autonomous agents that run to completion tend to burn more tokens than the equivalent interactive session, because the engineer would have stopped an unproductive path earlier. Not a reason to avoid autonomous — a reason to bound the scope tightly.

A team running at 70% AI-generation in 2026 typically sees cost-per-merged-PR in the low tens of dollars for CLI-heavy work, low single dollars for IDE-inline-heavy work. Teams that do not track it discover, sometimes at the quarter-end invoice, that the number is much higher than they thought.

The tool churn is the real risk

The tools we describe in this post will not be the tools we describe in this post twelve months from now. That is the pace of the market. The mitigation is not to pick the tools that will last — it is to pick the discipline that will last.

The four-slot mental model. The review discipline from the 70%-codebase pillar. The subagent pattern. The cost-tracking. All of these outlive the specific vendors. An engineering leader who invests in the discipline can swap the tools in and out as the market shifts and lose very little. An engineering leader who invests in a specific tool and skips the discipline has to re-learn the pattern every time the market shifts.

Which is roughly every six months.

go deeper

Keep reading

One step further into the topic — the next post picks up where this one ends.