The Agentic Coding Tool Wars: What Actually Changed in 6 Months
The model stopped being the differentiator. Here's what replaced it and why that shift changes everything downstream.
TL;DR
Four tools: Claude Code, Cursor, Codex and Antigravity converged on the same agentic blueprint inside six months
The model wars are effectively over; SWE-bench scores across leading tools now sit in a narrow band
Differentiation has moved to the harness: workflow, pricing model, distribution, and the habits a team builds around a tool
A fifth entrant, Grok Build, just arrived with the boldest architecture bet in the category: eight parallel subagents
The real question for your org isn’t “which model?” —> it’s “which workflow are we willing to lock into?”
The Convergence No One Announced
Four frontier labs with genuinely different cultures. Anthropic’s safety-first research orientation, Anysphere’s developer-tool pragmatism, OpenAI’s distribution machine, Google’s platform ambition arrived at almost the same blueprint inside last six months.
When that happens, it usually signals the design was less a choice than a discovery. The agentic coding tool has a natural shape, and everyone found it.
That shape looks like this:
A terminal or command-line surface. Not a chat window, not a sidebar: a surface where the agent operates alongside the repository, not above it.
Explicit planning before execution. The agent reads, thinks, proposes. You approve or redirect before anything is touched.
Approval gates at the dangerous moments. The riskiest point in any agentic session is the second before a command runs or a file changes. Every serious tool now puts a human at exactly that point.
MCP as the connector standard. Model Context Protocol has become the pipe through which agents reach external tools such as issue trackers, test runners, deployment systems. It’s the integration layer the category standardized on without a formal vote.
Parallel or delegated agent work. The move from single-threaded agent sessions toward multiple agents working isolated tasks simultaneously is now a design expectation, not a differentiator.
Ask any of the four to fix a failing test across three files and the flow looks nearly identical. That sameness is not a problem, it’s a signal that the category matured.
Where Each Tool Actually Pulled Ahead
Convergence on architecture doesn’t mean identical products. Each tool found a different dimension to own.
1. Claude Code — Deliberate friction as a feature
Claude Code stayed terminal-native and leaned into Anthropic’s long-context reasoning. The approval-heavy flow isn’t a limitation, it’s a design choice. On a serious codebase, the tool puts a human at the exact moment of highest risk, every time.
Teams that want to read every diff before it lands, that work in regulated environments, or that have strong code review cultures gravitate here. The friction is the product.
2. Cursor — The model-agnostic bet
Cursor stayed inside VS Code and stayed model-agnostic. You point it at whatever frontier model your team already pays for. You’re not tied to one vendor’s release calendar or one lab’s pricing changes.
The deeper insight Cursor made: the hardest part of adopting a new tool isn’t learning the tool, it’s leaving the workflow you navigate by reflex. Cursor asks for no workflow migration. Developers add agency without leaving their files, tabs, diffs, and shortcuts.
3. Codex — Distribution as the moat
Codex took the distribution route. Packaged inside ChatGPT plans rather than sold separately, it reached scale faster than anything else in the category over 4 million weekly developers by late May 2026. The real growth engine is enterprise rollouts already inside ChatGPT Business and Enterprise agreements.
This is the classic platform play: make the switching cost near zero by making the adoption cost near zero.
4. Antigravity — The platform bet, at platform risk
Antigravity traveled the furthest distance. It launched as an AI-native IDE, then relaunched at Google I/O 2026 as a five-surface platform: desktop app, CLI, SDK, a Managed Agents API inside the Gemini API, and an enterprise layer for Google Cloud.
The real bet is a route from local coding agent to managed agent runtime on Google Cloud, the same harness running everywhere from the developer’s laptop to GCP production. For Google Cloud shops, this is a serious long-term play.
The risk is also the most visible in the category. Quota changes in March 2026 and the full platform relaunch broke developer setups overnight. Preview-stage instability is real, and the $100/month AI Ultra tier announced at I/O shows where the pricing is heading.
5. Grok Build — The new entrant with the boldest bet
xAI moved faster than most expected. Grok Build arrived in beta in mid-May 2026 with two design choices no one else has made:
Up to eight subagents running in parallel, each isolated in its own Git worktree. This is the most aggressive architecture bet in the category. If it works at scale, it changes the throughput math for agent-driven development entirely.
Local-first execution, source code and credentials stay on the machine during a session rather than transiting to xAI’s servers. This is genuinely appealing to teams in regulated industries, though the compliance documentation is still thin relative to the marketing.
Arena Mode, generating multiple candidate outputs and letting you pick the best has appeared in code traces but isn’t live yet. That’s the feature that could close the benchmark gap in practice rather than on paper.
The Quiet Standard That Matters More Than MCP
Everyone talks about MCP. The standard forming inside repositories may matter more.
AGENTS.md is a convention that turns the repo itself into the agent’s onboarding guide on how to run tests, what style to follow, what not to touch. Codex, Cursor, Copilot, and Windsurf all read it natively. Claude Code reads its own CLAUDE.md. The direction is clearly toward a single portable instruction file that makes agent behavior consistent across tools.
This started with OpenAI, Google and Cursor joined, and it now sits under the Agentic AI Foundation at the Linux Foundation alongside MCP.
Why this matters for you: Your AGENTS.md is a product artifact. It encodes your team’s conventions, your agent’s guardrails, and your review standards. Teams that treat it like documentation approach it to set once, forgotten and will get inconsistent agent behavior. Teams that treat it like a living product spec will get an agent that behaves like it was trained on their culture.
The Model Stopped Separating Products
Here’s the sharpest signal that the category has matured: SWE-bench Verified scores across leading tools now sit within a narrow band of each other as of mid-May 2026. And Cursor will run any of them.
When the engine stops separating products, the difference moves to everything around it.
The harness. The workflow. The approval model. The distribution channel. The pricing at scale.
That is the most important shift of the last six months and it’s the reason choosing a coding agent now turns on fit rather than which leaderboard score a lab published last week.
Benchmarks measure whether an agent can solve an isolated task. In real repositories, the hard part is landing a change that survives local conventions, CI, and a human reviewer. Teams are starting to route work by type rather than swear loyalty to one tool.
What’s Coming Next in This Series
This was a product story on the landscape view, where the category landed and why.
Part 2 goes into builder mode: if you were designing a developer platform today and had to choose or combine these tools, what’s the actual evaluation framework? Cost-per-accepted-change, routing logic, AGENTS.md as infrastructure, and where lock-in really lives.
Part 3 is the rollout playbook: how to pilot one of these tools with your engineering team, what to measure, how to govern it, and how to avoid the traps teams walked into in the first wave.



Genuinely enjoyed reading this! have a look at my lasted and first substack on AI and remaining human if you'd like :)
Good breakdown. The AGENTS.md point stands out to me: most teams treat it as a one-time README when it should be maintained like a living spec, and that's probably where real advantage shows up over time. I'd push back a bit on 'the model wars are over' though. SWE-bench convergence doesn't mean real-world reliability has converged too. Hoping Part 2 digs into failure modes, not just workflow fit.