Which AI Tool Wins? Wrong Question.

Updated 2026-10-25.

The views expressed here are my own and do not represent the position of my employer.

Last month I watched a colleague hunt down a bug: an agent’s frontend refactor had silently broken an API (application programming interface) contract two layers deeper in the backend. He ran Claude Code in one terminal pane to trace which parameter had gone missing, and VS Code in another to step through the TypeScript client that called the endpoint. Cursor was open on a second monitor, where he was already fixing the contract between the two components. That made three AI coding tools for one person on one Tuesday afternoon.

I asked him why he didn’t pick one. He looked at me as if I’d asked why he owns both a screwdriver and a hammer.

Before going further, a caveat: that colleague is a senior engineer with fifteen years of experience. He knew which tool to reach for because he understood the problem deeply enough to decompose it. For the median team, three tools mean three times the context switching and no clear signal about which output to trust. The anecdotes in this article come mostly from skilled practitioners. The more common failure is real too: agents produce plausible but wrong code that nobody on the team can evaluate, and Part III deals with it. The article argues for the direction the industry is taking, and today’s average outcome lags behind it.

One survey reports that 73% of developers use two or more AI coding tools regularly (Ivern AI, n=312, April 2026). The industry keeps asking “which one will win?”, and it has asked the same question about editors before. In the 1990s the answer was going to be Visual Studio, in the 2000s Eclipse and in the 2010s VS Code. None of them won. Thirty years later, classical IDEs (integrated development environments), VS Code and Vim/Neovim coexist, because each maps to a different way of thinking about code. Terminal users don’t become GUI (graphical user interface) users, and visual builders don’t become keyboard users. The tools diverge because the people who use them think differently.

I’ve built IDE features at JetBrains, shipped one of the first agentic LLM (large language model) integrations into a production IDE and built developer tooling for 1C, an enterprise platform dominant in CIS (Commonwealth of Independent States) markets. Now I work on the AI layer for Mendix Studio Pro, part of Siemens, where governance is an operational concern, not a theoretical one.

The question “which AI coding tool will win?” assumes that one tool can win. None will, and the reasons why tell you more than the answer does.

What This Article Argues

The article backs four claims, in about twenty minutes of reading:

  • For an engineering organization, “which AI tool?” is the wrong question, because the platform is the investment. The right question is “what does our platform expose to agents, and is it governed?”
  • AI coding tools serve three markets: pro-dev, enterprise low-code and citizen-dev. Each serves different people with different failure modes, and AI makes each segment more capable without dissolving the boundaries between them.
  • The tools diverge while the protocols converge. MCP (Model Context Protocol), ACP (Agent Client Protocol) and A2A (Agent-to-Agent) standardize the infrastructure underneath, so your editor is becoming a preference, like your shell theme.
  • The governance gap is real and growing: 89% of enterprise organizations have had an AI-related production incident (Qodo/Censuswide, 500 US IT engineers, March 2026). The tools that build governance into their architecture, where others add it as a checkbox, will capture enterprise adoption.

Pro-dev, enterprise low-code and citizen-dev aren’t segments of one market. They’re three markets that happen to share the words “developer tool” and “AI”.

By vibe coding I mean describing software in natural language and iterating on the output without writing or reading code directly.

The table compares the three markets by who works in them, what AI does there and how each one fails:

Pro-devEnterprise low-codeCitizen-dev / vibe
WhoSoftware engineersBusiness engineers, IT in large organizationsNon-engineers building for themselves
Core jobWrite, review, orchestrate codeAssemble validated apps on governed platformsDescribe and iterate; never see code
AI roleAgent executes; human architectsAI guides within platform constraintsAI is the entire product
Failure modeHallucinated APIs, debt, verification bottleneckAgents know the platform’s DSL (domain-specific language) poorlyQuality ceiling, invisible security risks
ExamplesClaude Code, Cursor, Neovim with agentsMendix, OutSystems, SalesforceLovable, Bolt, v0

This article covers business application development: enterprise software, SaaS (software as a service), web, mobile and internal tools. System-level engineering, such as game engines, kernels, firmware and GPU (graphics processing unit) pipelines, works in a different paradigm where AI spreads more slowly, and it needs its own article.

Table of Contents

Part I: The Fragmentation

What AI Did to Pro-Dev Tools

Three years ago, my average day looked like this: I wrote code for about five hours, reviewed pull requests for one and spent the rest in meetings, Slack and architecture documents.

Now, on some days, I don’t write code at all. I spend hours discussing specs with the agent: clarifying intent, narrowing scope and defining what it mustn’t touch. I review agent output for two or three hours, and the rest is still meetings and Slack.

Teams that adopted agent workflows report that coding dropped from about 55% to about 20% of a senior developer’s day (multiple practitioner reports, 2026). The other 80% is review, architecture, orchestration and spec writing, so the job didn’t shrink; it shifted.

The shift changes what a tool has to be good at, because every IDE in history was designed for the version of the job where coding took 55% of the day. When writing code becomes the minority of the work, a tool optimized for writing code is optimized for the minority of the work.

How the editors responded

The old editor war between classical IDEs, VS Code and Vim produced no winner, because each camp holds values the others reject. AI didn’t change those values; it gave each camp a new dimension to compete on.

When we shipped LLM features into a production IDE, users didn’t first ask “can it write code?” They asked “does it understand my refactoring context?” They wanted the new capability to speak their tool’s language, because their way of working with the tool was already fixed.

Here is what happened next in each camp.

VS Code (v1.115 to v1.116, April 2026) added a Companion App, a separate window for agent sessions that run in parallel with the editor. A session can spawn child agents, and MCP bridging lets your terminal agent and your editor agent share tool access. VS Code is turning into an agent host that also edits code.

Cursor 3 rebuilt the product as an “agent-first workspace” with a multi-repo layout: agents fan out to the cloud, and their results flow back to the local machine. Cursor is still a VS Code fork, but it’s moving away from upstream fast, betting that an agent-native UX (user experience) requires breaking from the extension model entirely.

Zed went in a different direction with the Agent Client Protocol (ACP), an open standard that Zed created. Google, with Gemini CLI as the first integration, and JetBrains joined shortly after. ACP does for AI agents what LSP (Language Server Protocol) does for language tooling: any agent that speaks ACP works in any ACP-compatible editor. Thirty agents and ten editors support it, and the list keeps growing, so the protocol now decides more than any single product built on it.

Neovim and Emacs got ACP plugins: CodeCompanion for Neovim and agent-shell.el for Emacs. The gap between Neovim and VS Code collapsed, because both now host the same agents over the same protocol.

Underneath all of this, three protocols are converging: MCP for tool access, ACP for communication between agent and editor and A2A, from Google, for delegation between agents. The editor you use is becoming a UI (user interface) preference on top of shared infrastructure.

The terminal agent: a different way of working

A terminal agent is a different interaction model from an IDE, even one with its UI stripped out. You describe a task, the agent executes it, and you review the git diff, accept or reject it and move on.

You have no file tree to navigate and no tabs to manage, and no syntax highlighting tempts you into editing single lines when you should be reviewing architecture. The terminal agent makes the code the agent’s problem and the review yours.

Claude Code has become the reference implementation in this category, the tool other terminal agents are benchmarked against. Codex CLI (OpenAI, open source, May 2025) offers configurable approval modes and direct API billing: you pay per token, with no subscription. OpenCode is open source and can cost less, because it routes directly to the model’s API with no vendor margin on top.

Augment scored 51.80% on SWE-Bench Pro, above Cursor and Claude Code, with a “Context Engine” built for large enterprise codebases. Amazon Q Developer takes another angle and doesn’t try to be general-purpose. Q Developer Transform runs autonomous migrations from Java 8 to Java 17 and from Spring Boot 2 to Spring Boot 3, and Amazon has migrated thirty thousand internal apps with it. It costs $19 per user per month. It isn’t the best agent, but it knows enterprise Java and AWS (Amazon Web Services) deeply.

A new workflow is emerging: the editor is open on one side for reviewing diffs and navigating architecture, and the terminal agent runs on the other side. The developer sits between them, reading, deciding and steering, and types very little.

I made this switch in mid-2024. Zellij splits my terminal into panes: one for the agent session, one for the shell and one for test output. I keep Neovim open for when I need to read a file carefully or follow a call chain. The agents handle implementation, and I handle intent and verification.

The new way of working made sense to me while I reviewed a 400-line diff that the agent had produced for a service migration. I caught a subtle issue: the agent had used an eventually consistent read where the business logic required strong consistency. A bug like this passes every test and fails in production under load. I’d have made the same mistake myself, because the training data says that’s how you query that API. In review mode, though, I read the diff with fresh eyes and the domain constraints in my head, and I saw the bug immediately.

I call this the shift from writing to reviewing: AI writes the code, so I can spend my time on the part that requires judgment.

I now spend more time writing AGENTS.md files and task specs than writing code, and the work pays back directly. A well-written context file and a precise task spec let the agent produce correct output on the first pass, where it used to take three. I built a template system for this, a structured second brain that feeds context to AI agents. It holds project specs, architecture decisions, coding conventions and team context, all in plain Markdown and indexed for semantic search. When I start an agent session, the agent loads only the context it needs for the current task. The system is file organization with a purpose, and it needs nothing more advanced than that.

Classic IDEs: not dead, narrowing

Visual Studio and Eclipse built their advantage when writing code was the job. That job changed, and they’re becoming specialists. The reason is structural: a monolithic IDE invests in being a better code editor, while a lightweight editor with an agent invests in being a better agent host. The agent updates weekly and the IDE quarterly. The agent’s context is a 2-million-token window that RAG (retrieval-augmented generation) can extend, while the IDE’s context is whatever fits in heap memory. So the two architectures diverge, and so do the users they serve.

Visual Studio (the full IDE, as opposed to VS Code) shipped cloud agent sessions, custom agents defined in .agent.md and an enterprise MCP allowlist in April 2026. Its differentiator is a @debugger agent that reproduces bugs by driving live runtime execution, which is real debugging where other agents stop at static analysis. It also ships @profiler, @test and @modernize. This is the enterprise .NET and C++ story, and it pulls Visual Studio further away from VS Code.

Eclipse open-sourced its Copilot integration under the MIT license in May 2026. The eclipse-agents community project lets Claude Code and Gemini CLI drive Eclipse directly over ACP.

MCP is the common integration layer across all of them. The monolithic IDE becomes an agent host, so its unique value narrows to what can’t cross a protocol boundary: deep runtime debugging, profiling and language-specific refactoring in closed ecosystems.

That list gets shorter every year, slowly enough that it’s a direction and not a crisis.

Betting against your own product from inside the company that makes it is very hard. So the organizations best placed to build agent-first tools are those with no decade of editor investment to protect.

I haven’t opened a full IDE in two years. I didn’t decide to stop; I stopped needing to.

That’s the pro-dev market, one of three, and the other two took different paths.

What AI Did to Enterprise Low-Code

The low-code market made a counterintuitive move: the leading platforms opened up to external agents, where you’d expect them to compete, and reinforced the governance layer that external agents can’t replicate.

On a metamodel platform, the metamodel works as a ready-made spec layer. An agent operating on it can’t hallucinate an API that doesn’t exist in the model. The platform enforces the constraints in its architecture, so they hold even when the agent never sees the documentation.

The pattern across all three leaders

Mendix ships MCP Client and MCP Server modules. External agents, such as Claude Code, Codex, Cursor and whatever else you use, can call Mendix app logic over MCP, and Mendix apps can consume external MCP tools. mx-cli brings the platform to the terminal, where agents already work: you create, build and deploy Mendix apps from the command line. Maia, the built-in AI assistant, runs on the same foundation. Mendix bets that external agents complement the platform, and that the platform is the governed layer they operate through.

OutSystems announced Enterprise Context Graph in March 2026, with early access in Q2 2026. It’s a real-time map of every app, agent, workflow and data dependency in your organization. Claude Code, Codex and Cursor can all operate inside it, under its governance. The announcement puts it this way: “Without it, agents are just guessing.” The platform becomes the map the agent navigates by.

Salesforce shipped Hosted MCP Servers to general availability (GA) in April 2026. They expose org data, flows, Apex actions and queries to any MCP client. The existing permission model applies to agent access automatically, so Salesforce needed no new security model: CRUD (create, read, update, delete) permissions, field-level security and sharing rules. Agentforce Builder adds hybrid reasoning through Agent Script, which keeps deterministic logic explicitly separate from LLM prompts. Salesforce builds governance into the structure of the platform.

The structural advantage

The metamodel is the specification. Research shows that 41.8% of agent failures trace back to gaps in the specification (Part II gives the source). That failure rate nearly disappears when the platform encodes the domain structure, the valid operations and the data relationships. The agent can’t hallucinate an API that doesn’t exist in the model, and it can’t produce a data access pattern that violates the permission structure, because the architecture enforces the constraints.

The agent also has fewer files to navigate. Evidence suggests that reading code, more than writing it, is the central bottleneck for agents. A Mendix or OutSystems app has hundreds of model objects where a coded app has thousands of source files, and fewer nodes mean better traversal and fewer failures from lost context.

Finally, the vendor upgrades the platform, so the app doesn’t rot with its dependencies. Agent-generated code decays as libraries evolve: dependencies drift, new versions break the build and nobody applies the security patches. With a platform-managed app, much of that maintenance moves to the vendor.

The counterargument

External agents were trained on code in TypeScript, Python and Java, and they saw far less of Mendix’s MDL, OutSystems’ OML or Salesforce’s Apex. A Claude Code instance working on raw TypeScript has better model priors than one working on Mendix microflows, because the training corpus is asymmetric.

Platforms can close this gap with RAG over platform documentation, fine-tuning and few-shot scaffolding, and they’re working on all three. The gap is real today, though, and any argument for a structural advantage has to acknowledge it.

A second counterargument: the anecdotes in this section come from platforms that are succeeding. The median enterprise low-code deployment is understaffed, under-documented and two releases behind the current version. It gets less from AI agents, because the agents have less governed structure to work with. The structural advantage is real, but it doesn’t come automatically.

The de-platforming threat

Vendors don’t advertise this: the same AI capability that makes low-code platforms more productive also makes leaving legacy platforms economically viable for the first time.

The cost of leaving a custom internal platform or an aging vendor used to be prohibitive. No tool could translate large visual logic graphs or proprietary DSL definitions into a modern platform’s model automatically. So organizations stayed on end-of-life systems for years past their expiry date.

AI models change this. Translating a legacy internal workflow engine or an outdated vendor’s DSL into Mendix microflows is now a tractable problem. It isn’t trivial and the result isn’t guaranteed correct, but it’s tractable in a way it never was before. Migration tools, such as Amazon Q Developer Transform for Java and Claude Code for general-purpose rewrites, are the early form of this pattern.

The platforms that win enterprise customers in 2027 and 2028 will win them for two reasons. Their governance model, audit trail and metamodel validation are better, and AI-assisted migration finally makes moving to them feasible. The best platforms benefit from de-platforming, because they’re where organizations migrate to.

So AI coding tools aren’t disrupting enterprise low-code platforms; the platforms are integrating them as governed components. The governance layer, made of the metamodel, the permission model and the upgrade path, is what pro-dev tools don’t provide and can’t easily add. That layer is the platforms’ lasting advantage. It has to rest on value and not on the cost of leaving, because AI-assisted migration is lowering that cost now.

Citizen-Dev and Vibe Coding

The citizen-dev market confirmed a thesis the pro-dev community resisted for years: most people who need software don’t want to write code; they want outcomes. Lovable, Bolt and v0 proved that this is a market with real revenue and real business adoption. Vibe coding delivers business results with a time to value measured in hours, where a pro-dev team measures it in sprints.

The whole interface is the prompt and the preview, with no editor, no file tree and no terminal. AI isn’t a feature of these tools; it’s the whole tool.

What it’s good for

A marketing team needs a campaign landing page by Friday. A product manager wants to prototype a user flow before sprint planning. A department head needs an internal survey tool for a quarterly offsite. Each of these apps lives for days or weeks: someone generates it, uses it and discards it.

For these apps, technical debt never comes due, because nobody maintains an app after it’s thrown away. The right question isn’t whether an engineer would be proud of the code but whether the outcome justified the time spent. For disposable software, vibe coding often answers yes.

What it’s not good for

CVE-2025-48757 (Lovable, disclosed May 2025, CVSS (Common Vulnerability Scoring System) score 9.3, Critical) describes how Lovable-generated apps routinely shipped without Supabase Row Level Security (RLS) policies. The anon key, visible to anyone who opens the browser’s developer tools, gave unauthenticated attackers full read and write access to every row in every table.

A scan of 1,645 Lovable showcase apps found 170 projects (10.3%) with critical RLS gaps. Across 303 endpoints they exposed emails, phone numbers, payment details, API keys and developer credentials. The generated code looked correct, the app worked in the browser and the user saw nothing wrong. The security risk stayed invisible, because users never inspect database policies they didn’t write.

A reported incident in February 2026 allegedly exposed 18,697 user records, including those of 4,538 school students, from a Lovable-built app. Its AI-generated authentication logic was described as inverted: it blocked logged-in users and admitted anonymous visitors. (Source: a security community disclosure; no formal CVE has been assigned, and the vendor hadn’t confirmed the details at the time of writing.)

Any tool where the user never sees the code has this problem, because users can’t audit what they can’t see. And the platform’s position is that security is the customer’s responsibility.

This doesn’t make vibe coding tools wrong for their target segment. It means the segment ends at apps where the user can accept the security risk. Consumer prototypes, internal tools with no sensitive data and event pages fit inside it. Enterprise apps that handle PII (personally identifiable information), financial data or regulated workflows don’t.

The fusion team bridge

Gartner popularized “fusion teams”: 84% of large organizations already have them, and 63% of senior IT leaders call them “very effective” (Gartner, 2024).

In a fusion team, a principal engineer defines the domain constraints and writes the spec. Business engineers build within those constraints with the low-code or vibe coding tool they prefer. External agents handle migrations, testing and cross-cutting concerns through a CLI (command-line interface) or MCP. The metamodel or the spec is the shared contract between all three.

This is where the three markets meet: they divide the work between them. The pro-dev tool doesn’t replace the low-code platform, and the citizen-dev tool doesn’t replace the business engineer. Each market does what it does best, coordinated by a spec layer and a governance layer that the principal engineer owns.

A product that tries to serve all three audiences will serve none of them well, because each audience needs a different interface and a different governance model.

Part II: The Convergence

Three markets diverge at the user level, and shared infrastructure is forming underneath them.

The fusion team needs a coordination layer that none of the individual tools provides on its own. Someone has to govern what agents can see, what they can do and what happens when they fail. More and more often, that someone is a combination of specs, protocols and platforms, and no single person.

Spec-Driven Development

The shift from writing to reviewing works only if the agent knows what to build, because a faster executor with no brief produces noise faster. The industry learned this at the same time, from several directions.

A developer prompted Claude Code: “Add user authentication to this app.” The agent produced 400 lines of plausible authentication code with login forms, session management and token refresh logic. The tests passed, and the code looked right.

Three days later, a penetration test showed that the session tokens never expired. The code was correct by the standards of a generic tutorial and wrong by our security requirements, which lived on a Confluence page the agent had never seen.

The agent failed because nobody told it what “authentication” meant in this context, so it interpolated from its training data. The missing spec cost three days and a security incident.

The same thing happens everywhere, and research confirms it: 41.8% of agent failures trace back to gaps in the specification and not to model capability (via Tian Pan, 2026). Specs written up front raise implementation fidelity by 11.6% (SLUMP benchmark). The problem was never that AI can’t code; it’s that AI doesn’t know what you want.

Vibe coding shows this in its purest form: prompt, iterate and prompt again, with no spec. The output looks plausible, drifts further from the intent with every iteration and decays as the project grows. The cause is the missing specification, whatever the model’s quality, and the industry converged on the answer fast.

What spec-driven development is

Spec-driven development (SDD) means that before the agent writes any code, you give it a written document that defines what “correct” means for the task. A user story or a Jira ticket description is too vague for this. The specification lists the constraints, the boundaries, the expected behavior, the edge cases and what the code must NOT do.

The workflow has four steps:

  1. Specify: you write the document that defines the task, alone or with the agent. It covers inputs, outputs, invariants, security constraints and performance bounds, for example: “Sessions must expire after 30 minutes of inactivity. Refresh tokens rotate on every use. No token survives a password change.”
  2. Plan: the agent reads the spec and proposes an implementation plan, naming the files to touch, the architecture and the dependencies involved. You review the plan before any code exists.
  3. Implement: the agent writes code against the approved plan, and the spec is the acceptance criterion. When you review the diff, you check it against the spec and not against your sense of what looks right.
  4. Verify: the agent generates tests from the spec, independently of the implementation. If the spec says sessions expire after 30 minutes, a test creates a session, waits and asserts that it expired. The test proves that the code meets the spec, which says far more than that it compiles.

The spec lives as a file in the repository and persists across sessions. When a new engineer or a new model touches this code six months later, they read the spec first. They then know what “correct” means without reverse-engineering the implementation.

SDD isn’t requirements engineering under a new name. A requirements document describes what the business wants. An SDD spec describes what the agent must produce, in terms specific enough that both the agent and a reviewer can verify compliance. “Users should be able to log in” is a requirement. “POST /auth/login returns a 200 with a JWT containing user_id and role claims, expiring in 15 minutes, signed with RS256 using the key in VAULT_JWT_KEY” is a spec.

Everyone shipped the same idea

Every major AI coding tool now has its own version of SDD:

  • GitHub Spec Kit is an open-source, model-agnostic research framework, published as a paper and not shipped as a product. It runs the loop above as a CLI workflow: /specify, /plan, /tasks, /implement.
  • AWS Kiro keeps the spec, the plan, the tasks and the code in one agentic IDE workspace. AWS’s marketing claims an 18-month rearchitecture completed in 76 days; treat that as a vendor demo and not as a reproducible result. The direction is clear whatever the exact numbers.
  • Claude Code uses CLAUDE.md as a persistent context file. The agent reads it before every session, so your project context, constraints and conventions live in a file the agent consults the way a contractor checks the brief before starting work.
  • Cursor 3 combines Plan Mode with AGENTS.md, so the spec lives in the editor and needs no separate document.
  • Salesforce Agent Script is a DSL that keeps deterministic logic explicitly separate from LLM prompts. It applies the same principle to agent behavior that the other tools apply to code generation.

These companies don’t share roadmaps. They reached the same answer independently because the problem is universal: agents without specs produce plausible but wrong code.

That makes the spec more than documentation. It’s the artifact the agent works from, the thing the reviewer checks against and the thing that survives when you swap one model for another.

Context engineering as a discipline

Managing what information the agent holds across long sessions is becoming an explicit engineering skill. VS Code’s /compact command, Claude Code’s CLAUDE.md and Cursor’s AGENTS.md all answer the same need. The agent needs persistent context: a file that tells it how to behave in this project, which conventions to follow and which tools to use. That file isn’t the spec itself. It’s the operating environment the agent reads before it reads your spec.

The model provider lock-in risk

The spec also survives disruption at the model provider, and most teams underestimate how often such disruption happens. Anthropic deprecated Claude 3 Opus with six weeks’ notice. OpenAI’s price for GPT-4 dropped 90% in eighteen months, which changed every cost assumption built on the old rate. Google replaced Bard with Gemini and broke every integration that used the old API.

Teams that tied their workflow to one model (“we use Claude Sonnet for everything”) discovered the coupling when the model changed behavior after a minor version bump. A refactoring agent that produced clean, idiomatic code on Sonnet 3.5 started generating subtly different patterns on Sonnet 4.0. The tests still passed and the code was correct. But the drift in style made diffs harder to review and broke the team’s sense of what their codebase looks like.

A structural mitigation works where a contract can’t. Specs, context files and AGENTS.md don’t depend on any one model, because they describe the intent and leave the implementation to whichever model runs. A team with strong specs can swap providers in a day. A team with only prompt history and model-specific workarounds is locked in without knowing it, until the deprecation email arrives.

The spec is the convergence layer. It makes the fusion team possible, the platform engineering layer governable and the review loop on the SCM (source control management) platform meaningful. Without it, every other convergence mechanism operates on unverified output.

The SCM Platform Absorbs the Review Loop

A pull request merged at 03:14 on a Tuesday while the engineer who opened it was asleep in Berlin. The agent that wrote the code also reviewed the diff against the repository’s conventions, confirmed that CI (continuous integration) passed and triggered the merge. By the time the engineer’s alarm went off, the change was in production, and no human had touched it after the first prompt.

I’ve heard versions of this story from several teams running GitHub Copilot Enterprise. The details differ, and the pattern repeats.

While the editor debate dominated developer Twitter, GitHub and GitLab moved into territory that used to belong to separate code review tools. They absorbed the whole category.

GitHub: from feature to infrastructure

Copilot Code Review launched in April 2025 and grew tenfold in a year. By March 2026 it had run 60 million reviews, and more than 12,000 organizations ran it automatically on every pull request (PR).

In March 2026 the agentic architecture reached GA: the agent retrieves repository context, reads linked issues and plans its review strategy for long PRs. The agentic redesign alone raised positive feedback by 8.1% straight away. In 71% of reviews the agent surfaces actionable feedback, and in the other 29% it says nothing, on purpose, to keep its signal clean.

In May 2026 GitHub added “Fix with Copilot”, which turns review comments into delegated tasks: the coding agent implements the fixes, reviews its own work and updates the PR. On 2026-06-01 billing moved to Actions minutes, so the review loop is now literally part of CI.

The one-click fix for failing Actions (May 2026) lets the Copilot cloud agent investigate a failing CI job, push a fix to the branch and tag it for review. At that point a “code review tool” and a “CI bot” are the same thing.

GitLab: the full MR lifecycle as one agent

GitLab Code Review Flow (March 2026) costs a flat $0.25 per merge request (MR). It works in several agentic steps: it scans the diff, explores the repository context and checks the pipeline and the security findings. GitLab states its positioning openly: standalone tools charge $15-25 per review, and at $0.25 you stop rationing reviews and turn them on for everything.

In GitLab 19.0 (May 2026), Developer Flow covers the whole MR lifecycle: it addresses reviewer feedback, resolves merge conflicts and splits oversized MRs. One-click rebase-and-merge is in beta. GitLab also runs Claude Code as an external agent: you assign external agents to MRs with an @mention.

Code review times rose 91% on teams using AI coding tools. AI made writing code faster and reviewing it slower, because reviewers got much more code and none of it came with the author’s context. GitLab bets that the bottleneck disappears if the platform does the review.

The dedicated review bots: squeezed but not dead

CodeRabbit reports 2 million connected repositories, 13 million reviewed PRs and $40M in annual recurring revenue (self-reported, April 2026). It’s the most-installed AI app on both the GitHub and GitLab marketplaces.

Qodo Merge uses RAG over the whole codebase for context and defines review policy in YAML. The review enforces your team’s rules, where a generic bot applies generic best practices.

Greptile raised a $25M Series A (Benchmark, September 2025). It focuses on what platform reviewers can’t do: analyzing cross-file impact in monorepos for PRs that touch 500 or more files.

The survivors share one trait: each does something the platform reviewer can’t do by design. Greptile builds a full codebase graph that Copilot review doesn’t traverse. Qodo enforces YAML-defined policy against ticket requirements that Copilot review doesn’t know about. General-purpose bots whose only feature is “AI review” are losing ground, while specialized bots with deep features keep theirs.

Review at the merge button

Shipping faster and reviewing every PR used to pull against each other. They stop conflicting when the reviewer is a $0.25 CI job.

The SCM platforms keep absorbing review, CI and now the fix loop itself, and that pull is exactly why a counter-movement exists: not every team wants to live inside one vendor’s platform.

The Open-Source Undercurrent

A developer in São Paulo opens a terminal, types aider --model ollama/qwen2.5-coder:32b and starts refactoring a payment integration. The model runs on their M4 Max MacBook Pro, with no API key, no vendor and no data leaving the machine, so the session costs nothing.

Their colleague on the same team uses Claude Code at $0.12 per task. Both are productive, and the market has room for both; that coexistence is the subject of this section.

Not every team buys a SaaS seat. A parallel ecosystem has matured that most analyst reports miss, and it does three things at once. It keeps commercial prices competitive, it gives compliance-constrained enterprises a real alternative, and it brings open-weight models that are closing the quality gap with frontier models.

OpenClaw: the most-starred repo on GitHub

OpenClaw is the most visible example. Peter Steinberger, the founder of PSPDFKit, launched it in November 2025. It gained 60,000 stars in its first 72 hours and crossed 250,000 GitHub stars on 2026-03-03, passing React for the all-time record. It had 374,000 stars as of May 2026. Steinberger joined OpenAI in February 2026, and the project moved to a foundation to stay independent.

OpenClaw is a free, open-source autonomous AI agent that executes tasks through LLMs and uses messaging platforms as its main interface. It supports several providers (Anthropic, OpenAI and local Ollama models) and more than 20 channels, including WhatsApp, Telegram, Discord, Slack and iMessage. Skills are distributed through ClawHub, an npm-style marketplace for JavaScript plugins. SOUL.md is its identity file, the equivalent of CLAUDE.md for personality and context.

In the ClawHavoc incident (March 2026), three malicious skills on ClawHub were caught executing unauthorized code. The comparison to npm supply chain attacks is exact. An open marketplace for executable agent code carries the same trust risk as an open package registry, so the attackers needed no new technique.

OpenClaw and Claude Code make two different bets, more than they compete on capability. Claude Code bets on a stable Anthropic stack, coding first and the simplicity of a direct API. OpenClaw bets on general-purpose agent infrastructure that works across providers under a foundation’s governance. OpenClaw is a community-driven project and not a production-grade enterprise tool, and the ClawHavoc incident shows how far it still has to mature.

One mid-sized refactor session costs about $8 in Claude Sonnet tokens across several iterations. A typical agentic loop consumes 500,000 to 1 million tokens once you count the planning, implementation and self-correction passes. That isn’t cheap, and the cost is why the self-hosted path exists.

The self-hosted ecosystem

The self-hosted tools share one structural argument: if the model is a commodity, the value lies in the integration layer, and that layer shouldn’t tie you to a vendor. Each tool below bets on a different place for the integration layer:

  • Cline (VS Code) brings a Cursor-style agent flow to a stock editor and works with any provider. Its bet: the IDE is the integration layer, and the model is swappable.
  • Continue is an open-source Copilot replacement with inline autocomplete and chat. With Qwen 2.5 Coder 32B on local Ollama it reaches roughly 60-70% of frontier quality at zero marginal cost. Its bet: autocomplete is a solved problem, and paying $20 a month for it is a market inefficiency.
  • Aider is terminal-native and disciplined about git: it makes atomic commits with generated messages. It’s arguably the best tool for diff-aware refactors where you want every change in its own commit. Its bet: the integration layer is git itself, meaning diffs, commits and branches.
  • OpenHands (formerly OpenDevin) is a fully autonomous agent in a Docker sandbox with a browser, a terminal, an editor and a file system. It’s built for long-running delegated tasks you walk away from. Its bet: the integration layer is the whole OS (operating system), and you need no editor.

The four tools give four answers to the question of where the interface between human and agent lives: the editor, the prompt line, the git history or nowhere. This fragmentation is the market discovering that different workflows have different natural boundaries.

Here is what each costs per month. Cline with the Claude Sonnet API costs $15-60 depending on usage, Aider with the Claude Sonnet API $10-40, and Continue with local Ollama (Qwen 32B) nothing. Cursor Pro costs $20 or more, and GitHub Copilot Business $10-19 per seat.

The self-hosted path isn’t always cheaper in total, because setup and maintenance take engineering time. For teams with strict data residency requirements, air-gapped environments or specific compliance constraints, though, it’s the only viable path. For individual developers who own the right hardware, it’s often free.

The Chinese models enter the stack

Most Western analyst reports leave these models out, but they show up more and more in self-hosted and cost-sensitive environments:

  • Qwen Code (Alibaba) is a terminal agent and VS Code extension that supports MCP. Qwen 2.5 Max scored 80.4% on SWE-Bench Verified (May 2026), which puts it level with frontier models.
  • Kimi k2 (Moonshot AI) scored 80.2% on SWE-Bench Verified and is available through an API.
  • Trae (ByteDance) is a VS Code fork built as an AI-native IDE. Its free tier includes access to GPT-4o and Claude 3.5 Sonnet, and its Builder mode generates multi-file apps from descriptions. It has real traction in markets where Cursor’s $20 a month is a barrier.
  • DeepSeek V4 Pro scored 80.6% on SWE-Bench Verified and has open weights. It’s the highest-performing open model for coding tasks, and for teams running self-hosted inference it’s the one that closes the gap with Claude and GPT.

So the claim that open source is significantly worse no longer holds for routine coding tasks. The remaining gap is in long-horizon reasoning across many files and in architectural coherence. For most day-to-day implementation work, open models are viable.

For teams evaluating self-hosted paths, the compliance argument for local inference now has a quality argument behind it. You keep the capability and gain control; what you trade is a vendor invoice for a hardware budget.

The VRAM tax

Local AI inference has a physical constraint that vendor marketing plays down. Running Qwen 2.5 Coder 32B with useful quantization and a useful context window requires Apple Silicon with 64GB of unified memory or a high-end NVIDIA GPU with enough VRAM (video memory). That’s a hardware procurement decision, and no software setting changes it.

The self-hosted path turns build-versus-buy into a choice between capital and operating expenses (CAPEX and OPEX). The organization pays $20-60 per developer per month in SaaS fees and carries the compliance risk. Or it doubles the laptop budget for every developer who needs local inference, or the platform team builds and maintains an on-premise GPU cluster.

A compliance-constrained enterprise that reads this section and concludes “we’ll just self-host” has a hardware budget conversation ahead that isn’t in the IT plan. Calling self-hosting free is wrong, because the cost moved from the vendor invoice to the infrastructure budget and the platform team’s calendar.

The open-source ecosystem isn’t replacing commercial tools. It keeps commercial prices competitive and gives enterprises a real alternative for their most sensitive codebases.

The Platform Engineering Layer

An engineer at Uber submits a migration PR that updates a deprecated API call across 47 services. They didn’t write any of the code: they wrote one spec file describing the migration, pointed Minion at it and went to lunch. When they came back, the PR was open, CI was green, and the agent had left a summary of the decisions it made where the old API didn’t map cleanly onto the new one. The engineer spent twenty minutes reviewing those decisions. A migration that would have taken the team two sprints took one afternoon.

Individual developers barely see this trend, and it affects engineering organizations most. While the tool debates ran hot, large engineering organizations built something independent of them: a governed layer that every agent operates through, whichever tool it comes from.

What big tech built

All three of these systems run in production.

Uber Minion is a background agent platform that produces more than 11% of all merged PRs at Uber (Uber Engineering Blog, 2026). It’s built on DevPod (containerized development environments), Shepherd (migration orchestration across hundreds of millions of lines) and the Michelangelo AI platform. Thousands of internal agents run with Zero Trust identity: each agent gets a cryptographic identity, and every tool call is authorized and auditable. The A2A protocol handles delegation between agents and records the full chain of actors.

Netflix Data Bridge is a unified control plane for data movement that runs 20,000 distinct jobs and 300,000 executions a week. It has three interfaces: a web UI for non-technical users, a GraphQL API for programmatic access and YAML configuration as code for advanced use. It separates what the user intends from how the job runs and enforces governance centrally, so the tool on top is interchangeable and the control plane stays fixed.

Airbnb Skipper is an embedded workflow engine for durable execution. It needs no external runtime, because it uses the service’s own database, and it runs more than 15 production use cases. Its design principle is to govern through existing infrastructure with no new layer on top. MCP follows the same instinct: it connects agents to the systems that already exist.

None of these organizations asked which AI tool to standardize on. They asked what their platform exposes to agents and how to govern that access.

The commercial version

Internal developer platforms (IDPs) are turning from a service catalog with documentation into a control plane for agents:

  • Backstage, Port and Cortex provide the service catalog, golden paths and policy enforcement. They now expose these through MCP servers, so agents can query and act on them.
  • 73% of platform teams have integrated AI assistants into at least one workflow (Cloud Native Computing Foundation (CNCF) Platform Engineering Survey 2026).
  • Gartner projects that 80% of large engineering organizations will have platform teams by 2027, up from 45% in 2024.

The composable pattern wins: a portal (Backstage or Port), provisioning (Terraform or Crossplane), delivery (ArgoCD), observability (Grafana or Datadog) and an AI layer. Organizations assemble these parts themselves and don’t buy them as a bundle.

The reframe

For an individual developer, “which AI coding tool should I use?” is the right question: use the one that fits your way of thinking, your language ecosystem and your workflow.

For an engineering organization, it’s the wrong question. The right one is: what does our development platform expose to agents, and is it governed?

The tool is a detail and the platform is the investment, because every agent the organization adopts, whichever tool it comes from, works through the platform.

VS Code’s MCP server bridging and Uber’s Minion implement the same idea: the editor is interchangeable, and the governed context layer underneath it isn’t. The split into three markets (pro-dev, low-code and citizen-dev) stays stable precisely because each market’s platform layer differs by design. Governance for citizen-dev looks nothing like governance for enterprise low-code, which looks nothing like a pro-dev IDP. They aren’t one layer sold at three price points; they’re different architectures for different organizational needs.

The cost nobody budgeted for

The pricing model for AI coding tools is changing under everyone’s budgets, and flat-rate subscriptions are ending. Cursor moved to token-based billing above a usage cap. GitHub Copilot Code Review now charges against Actions minutes. Claude Code’s Max plan ($200 a month) has hard token ceilings that heavy users hit mid-month. The industry is moving to consumption-based pricing, and consumption grows with agent autonomy, whatever the headcount.

So the more autonomous the agent, the more tokens it burns. A multi-step agentic loop (plan, implement, test, fix, re-test) can consume 500,000 to 2 million tokens per task. Current API rates are $3-15 per million input tokens and $15-75 per million output tokens, depending on the model. At those rates a single complex refactoring session costs $5-30. Multiply that by a team of twenty running agents every day, and the monthly bill looks nothing like “Copilot at $19 a seat”.

Autonomous agents in multi-step loops raise the cost further. A review agent flags a test failure. A fix agent writes a patch and pushes it, CI runs, and another agent reads the failure log and retries with a different approach. The human who would have looked at the terminal and stopped the loop is asleep, and the agents keep going.

Agentic loops without a circuit breaker, where agents retry, revert and try again indefinitely, have produced overnight CI bills of $10,000-50,000 at early adopters. Platform engineers at several companies report this, though no public case study names an organization yet. Only 27% of organizations set hard limits on token usage (CloudBees, 2026), and the rest find out from the invoice.

Platform teams are answering with a new infrastructure discipline. It sets hard token quotas at the organization level and CI minute budgets per agent. It detects loops automatically, halting when the same diff hash arrives twice, and escalates to a human when the retry count passes a threshold. Platform teams building the agent control plane have to treat FinOps (cloud cost management) as a first-class requirement from the start.

AI coding tools were supposed to save engineering time, and they do, but they convert the saved time into infrastructure spend. The budget didn’t shrink; it moved from payroll to cloud invoices. Engineering leaders who sold the adoption internally on developer productivity now have to explain a line item that grows with every agent they deploy.

Specs standardize intent, protocols standardize communication and platforms standardize governance. Three markets still serve three kinds of people, but underneath them the infrastructure is shared and the control plane is forming. What stays ungoverned is the gap that Part III covers.

Part III: The Enterprise Reality

The tools improve fast, and the governance gap grows faster.

The three markets in Part I diverge by design, and the convergence layer in Part II forms underneath them. Neither addresses what happens when the agents fail, and they do fail.

The Governance Gap

A VP of Engineering sits in a board meeting. The CISO (chief information security officer) asks: “What percentage of our production code was written by AI, and how do we know it’s correct?” The VP knows roughly the answer to the first question and has no answer to the second. Nobody has that answer yet, because the governance framework was built for human developers who make traceable decisions, and agents don’t make them.

Vendor marketing promises faster delivery, happier developers and more output per engineer. The production data looks like this.

The incident rate

89% of enterprise engineering organizations have had at least one AI-related production incident (Qodo/Censuswide, 500 US IT engineers, March 2026). One in four has suffered a complete system outage caused directly by AI-generated code. At the largest enterprises, those with more than 10,000 employees, the outage rate reaches 40%.

81% of enterprise technology leaders report production failures tied to AI-generated code (CloudBees, 213 leaders, May 2026).

43% of AI-generated code changes need manual debugging in production even after passing QA (quality assurance) and staging (Lightrun, 200 SRE (site reliability engineering) and DevOps leaders, 2026).

These numbers describe the baseline, and none of them is an edge case.

The verification bottleneck

AI writes 42% of committed code today, and that share is projected to reach 65% by 2027. Yet 96% of developers don’t fully trust AI-generated code (Sonar, 1,100+ developers, January 2026), because it arrives without context. A human author can explain their reasoning. An agent can’t explain why it chose eventually consistent reads over strong consistency, so you find out in production.

Developers spend an average of 38% of their work week, roughly two full days, on debugging, verification and environment-specific troubleshooting linked to AI output (Lightrun).

AI coding tools made writing code faster and everything after writing code slower.

The testing tautology

When one AI agent writes an implementation and a second writes its tests, both share the same base model and therefore the same blind spots. The test suite goes green, coverage reads 90%, and the architectural flaw passes undetected.

False coverage is more dangerous than low coverage, because low coverage signals the risk and false coverage hides it. A test written by the same model that wrote the code can’t verify that code independently; it only reflects the code back.

The tools that will command a premium in 2027 are those that break this tautology:

  • TDD-first agents: Qodo’s Alpha Agent applies test-driven development (TDD). It generates tests from the spec before the implementation, then uses those tests as the acceptance gate for code generation, so the test and the code have different authors by design.
  • Formal property-based verification: Hypothesis (Python), fast-check (TypeScript) and jqwik (Java) generate thousands of random inputs against declared invariants, with no LLM heuristics involved. If the property holds, it holds however the code was written.
  • Mutation testing: Stryker, pitest and mutmut inject faults into the code and check whether the tests catch them. A suite with 90% coverage and a 40% mutation score misses most of the faults it should catch. Mutation score is the only metric that measures whether tests verify behavior.
  • Multi-model review: a different model, or a model from a different provider, reviews the code one model wrote; for example, Claude writes and GPT reviews. Their blind spots don’t overlap perfectly, so this improves on self-review structurally, though it guarantees nothing.

The technical debt no one wrote

A preprint study, not yet peer-reviewed, analyzed 302,600 verified AI-authored commits across 6,299 repositories and found 484,366 distinct issues they introduced. Code smells made up 89.3% of all issues. More than 15% of commits from every AI coding assistant introduce at least one issue. 22.7% of those issues survive to the latest revision, unfixed and accumulating.

This debt differs structurally from debt that humans write. Suppose agents wrote 65% of a codebase, and humans reviewed it at the architectural level without inspecting line 4052. The codebase then becomes progressively alien: correct, working, even well structured, and understood by nobody on the team. When that model version is deprecated and a new model modifies the same file, the new model may not understand the implicit decisions of the old one.

Design decisions that used to live in the team’s memory are being replaced by probabilistic artifacts that nobody can explain after the fact.

The secrets problem

64% of valid secrets found in 2022 were still unrevoked in 2026 (GitGuardian). AI coding speeds up the creation of secrets more than their revocation: developers paste credentials into prompts, and code suggestions reproduce API keys from training data. New secrets appear faster than governance can clean them up.

What this means

My read is that the governance gap is an organizational design problem, which tooling alone won’t solve. The teams that close it fastest treat spec discipline and review literacy as engineering competencies, where other teams see process overhead.

The governance gap differs across the three markets. Enterprise low-code platforms inherit governance layers refined over a decade: permission models, audit logs and deployment controls. Pro-dev tools are retrofitting governance: GitHub’s enterprise allowlists, GitLab’s audit chains and the concept of Cycode’s AI Bill of Materials (AIBOM). Citizen-dev platforms have almost none of it.

The market that turns governance into a product, where others treat it as a checkbox, wins the enterprise. You can add governance to a tool, but a platform has it by design.

The governance gap has a legal counterpart, and the legal counterpart has deadlines.

An engineering team in Amsterdam uses Cursor with individual-tier accounts on a codebase that processes EU customer data. Test fixtures contain real email addresses from staging. Every keystroke sends code context, including those emails, to Anthropic’s servers in the US, and no DPA (data processing agreement) covers this data flow. The team is violating the GDPR (General Data Protection Regulation) in real time, and nobody on it has noticed.

The cause isn’t malice but a gap between how engineers choose tools and how compliance works.

EU AI Act: what applies to engineering teams

The Act takes effect in phases, and the Digital Omnibus (provisional agreement, May 2026) reshuffled some of them:

DateWhat takes effect
2025-02-02Ban on prohibited practices; AI literacy obligation (already in force)
2025-08-02Obligations for GPAI (general-purpose AI) models: technical documentation, copyright, training summary (already in force)
2026-08-02Article 50 transparency; enforcement of GPAI fines (up to EUR 15M or 3% of global turnover); enforcement of AI literacy (confirmed, NOT delayed)
2027-12-02High-risk standalone systems (delayed from August 2026 by the Digital Omnibus)

For users of AI coding tools, meaning engineering teams, the tools fall in the minimal-risk tier. They carry no high-risk obligations unless you use the tool in hiring or credit decisions. The Article 50 transparency rule, which requires disclosing that output is AI-generated, applies from August 2026.

For GPAI providers (Anthropic, OpenAI, Google, Microsoft), fine enforcement starts in August 2026. The EU GPAI Code of Practice is final, and its signatories include the providers of current frontier models from OpenAI, Anthropic and Google.

53.8% of German enterprises had no AI compliance measures at all in early 2026 (Axis Intelligence). When I wrote this, the enforcement deadline in August 2026 was three months away.

GDPR is the more immediate risk

AI coding tools that process code containing EU personal data, such as names, emails and user IDs in test fixtures, are data processors under the GDPR, so you need a DPA.

GitHub Copilot Business and Enterprise include a DPA. Cursor Teams offers one, and Anthropic offers a DPA for the Claude Code API. Individual-tier tools from every vendor come without a DPA, so they aren’t compliant for work on enterprise codebases.

Most engineering teams don’t distinguish “I have a Copilot subscription” from “my Copilot subscription covers the data processing that happens during code completion”. The two statements have different answers.

US policy: deliberately the opposite direction

Executive Order 14179 (January 2025) revoked the Biden-era AI safety order and directed the removal of barriers to AI adoption. Executive Order 14365 (December 2025) created an AI Litigation Task Force to challenge state AI laws and called for a federal framework that preempts state-level regulation. In March 2026 the White House published its National AI Legislative Framework, which creates no new federal rulemaking body and preempts conflicting state laws.

The US treats AI regulation as a question of competitiveness, so global engineering organizations face two compliance regimes. Work that touches EU users or EU personal data falls under the EU AI Act and the GDPR. US-only work faces few federal constraints and a changing mix of state laws.

For engineering organizations with development in Amsterdam, Berlin, Warsaw or Stockholm, EU compliance is mandatory, because the most restrictive jurisdiction applies.

Doe v. GitHub (filed 2022) is a class action against GitHub, Microsoft and OpenAI. The court dismissed 20 of 22 claims, including the one under Section 1202 of the DMCA (Digital Millennium Copyright Act). Two claims survive, open-source license violation and breach of contract, and the case is active in 2026. The surviving claims don’t require proving exact reproduction; they require showing that license terms weren’t followed.

The real exposure lies in what the model outputs, more than in what it was trained on. Audit firms report that 30-40% of Copilot-generated code samples contain licensing irregularities. GPL-licensed code in a proprietary product can trigger copyleft obligations across the entire codebase.

Vendors indemnify their customers against IP (intellectual property) claims as follows:

  • Microsoft (Copilot Business and Enterprise) defends and indemnifies enterprise customers against third-party IP claims on output. It’s the only structural commitment on output IP from a major vendor.
  • OpenAI Enterprise covers claims arising from OpenAI’s services and explicitly excludes customer applications and combinations with third-party products.
  • Anthropic’s training-data settlement excludes claims based on output, and Anthropic offers API customers no indemnification for output IP.

Your vendor’s indemnification covers how the model was trained and doesn’t cover what the model generates; those are different legal questions with different answers.

Three Scenarios

I don’t predict the outcome; I map the possible ones. Each scenario has a falsifiable signal, something you can watch for that would confirm or weaken it.

Scenario A: Segmentation holds

This is the most likely outcome. The markets deepen their specialization: pro-dev tools become agent orchestration platforms, and enterprise low-code platforms become the governance layer for every agent working on enterprise data. Citizen-dev tools settle into their segment, useful for disposable software and limited by their security ceiling.

The evidence: 73% of developers use several tools, and the market is fragmenting into eight or more categories. Enterprise budget holders standardize on one or two tools within a segment and none across segments. And IDE history sets a precedent, because classical IDEs, VS Code and Vim still coexist after decades of supposed consolidation.

This scenario weakens if a single agent consistently outperforms specialized tools on their own benchmarks. The same agent would have to win SWE-Bench for pro-dev, metamodel traversal for low-code and no-config onboarding for citizen-dev, all three at once.

Scenario B: One agent captures all three

Claude Code or an equivalent expands to the terminal, the IDE, the desktop, the web and mobile and starts serving non-coders, so one tool serves all users.

The current evidence against it is the gap in cognitive style between the terminal-native developer, the visual builder and the person who says “I just want an outcome”. That gap is a fundamental difference in how people relate to software, which a better UX won’t close. The gap survives even when the same tool is available to all three audiences.

The falsifiable signal: a non-engineer, such as a product manager, a designer or a business analyst, completes a production-grade deployment using only a terminal agent, with nobody helping. If this happens at scale, revisit the entire thesis.

A more likely forcing function is enterprise procurement that mandates one AI tool across the organization as a licensing condition, because IT enforces it whatever the users prefer. Every earlier attempt at this produced shadow tooling and developer attrition, for example Eclipse RCP mandates in the 2000s and VS-only shops in the 2010s. A mandate can reduce the diversity you see, but it has never removed the diversity people practice.

Scenario C: Platforms become the layer

Internal developer platforms become control planes for agents. Developers interact with the platform, and the specific tool becomes interchangeable.

This doesn’t collapse the three markets; it adds a governed infrastructure layer above all of them. The markets diverge at the user level and converge at the infrastructure level.

Evidence already in production: Uber Minion, through which more than 11% of merged PRs pass, and Netflix Data Bridge, with 300,000 executions a week. The commercial IDP market follows big tech by 12-24 months.

The falsifiable signal: Backstage, Port or Harness IDP ships MCP routing as a default, first-class feature in a GA release. It has to appear in the core product changelog, and a plugin or community extension doesn’t count. At that moment the platform layer stops being a pattern that only big tech uses.

My read is that A and C will happen together: the markets diverge at the user level while the infrastructure converges at the platform level, and each movement reinforces the other.

A fourth scenario sits outside the A/B/C frame. A, B and C are market outcomes, and the fourth is a technological condition that changes the probability of all three.

Scenario D: On-device AI collapses the cost structure

AI inference moves to the edge: Apple Silicon with 128GB or more of unified memory, dedicated NPUs (neural processing units) and next-generation laptop GPUs. The model runs where the developer sits, with no API call, no vendor and no network latency.

Apple’s M4 Ultra already ships with 192GB of unified memory. If Apple keeps its pace, the next generation will likely reach 256GB. That’s enough to run a 70B-parameter model at full precision with a 200,000-token context window, and at that point the VRAM tax disappears for developers whose employers buy top-spec hardware.

If frontier-competitive inference becomes a one-time hardware purchase amortized over three years, the SaaS subscription model loses pricing power. The compliance argument becomes trivial, because no data leaves the machine. Governance gets simpler, because the organization controls the model, the weights and the guardrails.

The current evidence against it: on-device models today (32B parameters) still lag frontier models (400B or more) on long-horizon reasoning across many files. DeepSeek V4 Pro, at 80.6% on SWE-Bench Verified, has open weights, but the gap is closing and hasn’t closed. Reasoning at the architecture level and coherence across a codebase still favor models at datacenter scale.

The falsifiable signal: a 70B+ open-weight model running on consumer hardware (a machine under $5,000) comes within 3 percentage points of the Claude and GPT frontier models on SWE-Bench Verified. When that happens, cheap local hardware threatens the subscription model itself.

Scenario D doesn’t remove the need for governance, specs and platform engineering, which stay necessary wherever inference runs. A local model without a spec produces the same plausible but wrong code as a cloud model without one. The tool layer gets cheaper, and the discipline layer keeps its price, which is human attention.

What to Watch

Each signal below would update a scenario, so you have something to track and can test the conclusion yourself:

SignalWhat it updates
ACP adoption reaches all major editorsProtocol convergence confirmed; choice of editor is purely a UX preference
A non-engineer deploys to production through a terminal agent, unassistedScenario B becomes more likely
Enterprise procurement enforces a single AI tool across the organizationScenario B through forced consolidation
Agent swarms reach >80% task completion at enterprise scaleOne developer can do much more alone
Backstage, Port or Harness ships MCP routing as a GA defaultThe platform layer becomes a commercial default
A big tech company publishes its agent platform architecture openlyIDP vendors accelerate; the advantage of building in-house shrinks
A major observability vendor ships tooling for an AI audit planeMulti-agent debugging moves from custom builds to products
An agentic loop incident costing five figures becomes public, naming the organizationFinOps reaches the board; hard token quotas become standard
A major vibe coding platform ships a governance tier with audit logsCitizen-dev moves toward enterprise
OutSystems Context Graph reaches 10%+ customer adoptionPlatform openness confirmed at scale; the structural advantage moves from claim to data
Mitigations for MCP overhead close the cost gap between CLI and MCP to <2xThe cost advantage of the CLI disappears; the governance premium of MCP is justified
A 70B+ open-weight model on consumer hardware comes within 3% of the frontier on SWE-BenchScenario D: the subscription model comes under heavy pressure; self-hosting becomes the default

In 2026 a principal engineer’s job has two parts. The first is to choose a tooling architecture that works when writing code is the minority of the job. The data points to a platform-first architecture: governed context, spec discipline and interoperability at the protocol level. The second part is to protect enough unstructured thinking time to stay the person who builds what agents can’t yet imagine.

The first part is a market question, and the second is yours alone.

Protecting that thinking time is harder than it sounds and more necessary. LLMs are extraordinary interpolators: they assemble any application that resembles something in their training corpus. They couldn’t have invented React in 2013, or Kafka, or the relational model. A paradigm shift starts when someone recognizes that the existing abstraction is wrong, and LLMs are trained to reproduce existing abstractions. If the shift from writing to reviewing uses up every engineer’s spare attention on review and orchestration, who builds the next paradigm?

An engineer who keeps asking that question is worth more than any tool, because no tool can ask it.

References

Data and Research

  • Ivern AI, “State of AI Agents in Development” (n=312 developers, April 2026): ivern.ai
  • Qodo and Censuswide, “The AI Coding Paradox” (n=500 US IT engineers, March 2026): qodo.ai/resources/the-ai-coding-paradox
  • Sonar, “State of Code Developer Survey” (n=1,100+ developers, January 2026): sonarsource.com
  • Lightrun, “State of AI-Powered Engineering” (n=200 SRE and DevOps leaders, 2026): venturebeat.com
  • CloudBees, “State of Code Abundance” (n=213 enterprise technology leaders, May 2026): cloudbees.com/newsroom
  • Study of technical debt introduced by AI (302,600 commits, 6,299 repositories; preprint, not yet peer-reviewed): arxiv.org/abs/2603.28592
  • Tian Pan, “The Agent Specification Gap” (2026; cites the 41.8% failure rate from specification gaps and the SLUMP benchmark): tianpan.co
  • GitGuardian, data on secret revocation (64% unrevoked since 2022): csoonline.com
  • SWE-Bench Verified leaderboard (May 2026): swebench.com
  • CNCF Platform Engineering Survey (73% of platform teams have integrated AI, 2026): via leanopstech.com
  • Gartner: 80% of large organizations with platform teams by 2027; 84% of organizations with fusion teams (2024)

Products and Announcements