Agentic Coding Tools in 2035: Four Scenarios, Their Signals, and What Would Falsify Them

Forecast the category, not the product

Nine years is long enough for “Claude Code” to have broadened, renamed, or been absorbed into something that shares little with the 2026 command-line tool beyond the underlying idea. The useful object to forecast is therefore not a product but a category: an agentic coding tool is a model-mediated system that reads a repository, edits files, runs commands, receives feedback from what it ran, and returns a change plus evidence for a person or an organization to accept. Claude Code, OpenAI’s Codex, and GitHub Copilot’s coding agent are the 2026 instances of that category. By 2035 the instances will likely have different names; the category, and the questions that determine what it is good for, will still be recognizable.

A forecast about that category has to keep four kinds of claim separate, and this article tries to hold the line throughout. Measured facts are numbers tied to a specific study, tool version, and date. Vendor claims describe what a company says its product does, including internal usage statistics it chooses to publish. Analysis derives consequences from mechanisms — queues, evidence, incentives. Predictions state a future outcome and must be capable of being wrong. The scenarios that follow are not predictions in themselves; they are structured combinations of two variables, each given its own horizon, assumptions, observable indicators, and an explicit condition that would kill it.

The two variables are introduced properly below, but the shape of the argument can be stated now. The first is whether an organization’s capacity to check, test, and dispose of agent-produced changes grows as fast as the rate at which agents produce them. The second is whether the permission and trust apparatus that governs what an agent may do — and what evidence is sufficient to let its output through without a human re-checking it — converges on a shared standard across tools, or stays locked to each vendor’s own sandbox and format. Crossing them gives four scenarios, none of which this article picks as the favorite.

The August 2026 baseline

What a permission model looks like today

Every agentic coding tool shipping in 2026 already answers the same underlying question — what is this agent allowed to do without asking first — and each has converged on a strikingly similar shape while keeping the mechanism proprietary.

Claude Code’s default posture is strict read-only access: file edits, command execution, and MCP tool calls all require explicit approval unless the user has pre-approved them, with a small built-in allowlist of genuinely read-only commands such as ls and git status running without a prompt ^[1]. On top of that default, Anthropic has shipped a sandboxed bash tool that isolates filesystem and network access at the operating-system level and, according to the company’s own internal usage data, reduces permission prompts by 84 percent without removing the isolation boundary — the engineering post announcing it is framed explicitly as moving “beyond permission prompts” toward autonomy that does not require constant human gatekeeping ^[2]. A separate auto mode adds a second model as classifier, reviewing each proposed action and blocking only what looks like scope escalation, unfamiliar infrastructure, or an instruction that appears to originate from hostile content rather than the user ^[3].

OpenAI’s Codex answers the same question with a different mechanism: three named sandbox tiers — read-only, workspace-write (the default, which edits and runs commands automatically inside the working directory but asks before touching anything outside it or the network), and a “danger-full-access” tier the documentation explicitly discourages for untrusted code. Network access is disabled by default, with domain allowlisting available and local or private destinations blocked to guard against DNS rebinding ^[7]. GitHub’s Copilot coding agent takes a third route: it works asynchronously in a GitHub Actions sandbox on a delegated issue, opens a draft pull request, and requires an administrator to enable it for an organization in the first place; a human review is required before any CI/CD workflow runs against the result ^[9].

Read side by side, the three systems already share a structure — graduated autonomy, a default that asks before acting outside a bounded space, isolated execution, and a human checkpoint before anything downstream runs — while implementing it as three separate, non-interoperable pieces of engineering. That gap between shared shape and separate substance is most of what Scenario One through Scenario Four below actually disagree about.

What a verification loop looks like today

Anthropic’s own guidance for using Claude Code is built around a single mechanical idea: an agent that has no check to run stops when the work merely looks done, and every mistake then waits for a human to notice it. Giving the agent something that returns a pass or fail — a test suite, a build, a screenshot diff — closes the loop so the agent can iterate on its own, and the documentation recommends going one step further by using a verification subagent: a fresh model instance that reviews only the diff and the stated criteria, not the reasoning that produced the change, “so the agent doing the work isn’t the one grading it” ^[3]. The same document is candid about the failure mode this guards against, naming it directly: “the trust-then-verify gap,” where a plausible-looking implementation quietly fails to handle an edge case.

That instinct — that generation and evaluation should not share a grader — is not new to agentic tools; it is the same reason a benchmark like SWE-bench exists as a separate artifact from the model being scored. When SWE-bench was introduced, resolving real, unedited GitHub issues against a repository’s actual test suite, the best-performing model of the time resolved just 1.96 percent of the 2,294 issues in the set ^[13]. The benchmark’s difficulty was not an accident; it was evidence that an evaluation harness capable of actually disposing of a candidate change — running it, checking it against ground truth, not merely reading it — is itself nontrivial infrastructure, built and maintained separately from the thing it measures. Verification capacity, in other words, has always been a distinct line item from generation capacity, even before the tools got fast.

What the numbers say about where the work already goes

A study Anthropic published on how Claude Code is actually used gives the clearest existing picture of where a developer’s attention already sits relative to an agent’s. Writing, fixing, and testing code together make up about 56 percent of sessions; operating software accounts for 17 percent; planning and exploration for 14 percent; analysis and documentation for 13 percent. More tellingly, users make roughly 70 percent of the planning decisions — what to build — but only about 20 percent of the execution decisions — how to build it ^[4]. That split is already most of the way toward the reviewing-not-writing role this article’s scenarios argue about; the open question is not whether the split exists in 2026, but whether it deepens, stalls, or reverses.

The same study reports that outcomes are far from uniform across users. Novice sessions reach independently verified success about 15 percent of the time; intermediate and expert sessions reach 28 to 33 percent, with expert sessions running roughly twice as many tool actions and producing about five times as much output per turn as novice ones ^[4]. Skill at directing and checking an agent, in other words, is currently a large, measured, individual-level variable — not yet an organizational capability that travels between people or between tools.

Set beside that internal picture, independent researchers studying frontier agent capability generally have found a rapidly rising ceiling on what these systems can attempt. METR’s time-horizon research defines a task’s horizon as the amount of human time associated with work a model completes with 50 percent reliability, and reports that this horizon has been doubling roughly every seven months since 2019, possibly accelerating in 2024, with frontier models at the time of the study reaching around fifty minutes ^[10]. Extrapolated forward — and METR is explicit that the extrapolation’s external validity is uncertain — that trend implies systems capable of attempting month-long tasks within a handful of years. Nothing about that trend, on its own, says whether the checking side of the loop grows to match it.

Independent evidence on that second question already exists, and it is less comfortable. GitClear’s 2026 analysis of 623 million code changes made between 2023 and 2026 found block-level code duplication up 81 percent, copy-pasted code up 41 percent, two-week code churn up 15 percent, refactoring activity down 70 percent, and cross-file function reuse down 35 percent over the period, concluding that “the throughput is real, but so is the debt it accrues” ^[12]. DORA’s 2025 research program frames the same tension at the organizational level: across a large multi-year study, DORA’s central finding is that “AI’s primary role is as an amplifier, magnifying an organization’s existing strengths and weaknesses,” with the greatest returns coming from investment in the surrounding system rather than the generation tool itself ^[11]. Read together, these three sources are not contradictory — capability is rising, usage is shifting toward review, and maintainability signals are simultaneously eroding in measured code — but they are evidence that Axis One below is genuinely open rather than settled.

What “standardized” already looks like

The clearest existing evidence of cross-vendor convergence is at the wire-protocol layer, not the trust layer. Anthropic open-sourced the Model Context Protocol in November 2024 as a standard for connecting AI systems to external tools and data sources, explicitly to replace bespoke integrations built separately for each pairing of model and tool, and launched it with early adopters including Block and Apollo alongside development-tool partners Zed, Replit, Codeium, and Sourcegraph ^[5]. OpenAI adopted MCP across its Agents SDK in March 2025; its own documentation now describes the protocol in the vendor’s own words as something that “standardises how applications expose tools and context to language models,” comparing it to “a USB-C port for AI applications,” while separately warning developers to connect only to servers they trust and to use least-privilege credentials ^[6].

That is real, working standardization — but it standardizes how a tool call is shaped, not what evidence is sufficient to trust its result. Claude Code’s own security documentation is explicit about the limit of this: Anthropic reviews MCP connectors against listing criteria before adding them to a directory, but states plainly that it does not security-audit or manage the servers themselves, and treats “first-time codebase runs and new MCP servers” as requiring separate trust verification regardless of protocol compliance ^[1]. A protocol for calling a tool and a protocol for trusting what the tool reports back are different problems, and only the first has been solved industry-wide so far. Two existing frameworks show what solving the second might extend from: NIST’s Secure Software Development Framework already establishes a shared vocabulary of security practices across the software lifecycle for producers and purchasers to communicate against ^[14], and the Linux Foundation’s SLSA specification already defines graduated levels of build and source provenance as a cross-industry standard, independent of any single vendor ^[15]. Neither was written with agent-authored change in mind, but both are exactly the kind of substrate a trust-standardization scenario would need to extend rather than invent from nothing.

Two axes, and why they resist being pulled apart

Axis One — verification capacity relative to generation rate. At one end, an organization’s ability to specify, test, evaluate, and dispose of candidate changes scales with the rate at which agents propose them. At the other, generation continues to accelerate while the checking side lags, and the gap shows up as exactly the kind of erosion GitClear’s data already documents ^[12].

Axis Two — whether trust standardizes. At one end, permission scopes and the evidence an agent attaches to a change become portable: a change vetted under one tool’s policy carries evidence a different tool, or a different organization’s gate, can act on without repeating the check from scratch. At the other, each vendor’s sandbox, evidence format, and audit trail stays its own, as Claude Code’s, Codex’s, and Copilot’s currently are ^{[1, 7, 9]}.

The two axes are not independent, and the coupling matters more than either axis alone. Picture agent-produced candidate changes arriving at an organization’s review-and-merge gate at rate $\lambda$, while the organization’s verification stage — tests, evaluators, human reviewers — disposes of them at rate $\mu$. Treated as a simple queue, it is stable only while

Parallel agent sessions raise $\lambda$ directly; that part is already happening, as the “agent teams” and fan-out patterns in Claude Code’s own documentation for running many sessions at once make explicit ^[3]. What raises $\mu$ is the less obvious half, and it is exactly where the two axes touch: if evidence generated under one tool’s verification pass has to be regenerated from scratch every time a change crosses a tool or organizational boundary, the effective $\mu$ available at any single gate is lower than the organization’s raw checking capacity, because part of that capacity is spent re-proving what was already proven elsewhere. A portable, standardized evidence format — the kind SLSA-style attestations already provide for build provenance ^[15] — would let a downstream gate trust upstream verification instead of repeating it, raising effective $\mu$ without adding a single reviewer. Standardizing trust, in this framing, is not a separate story from verification capacity; it is one of the few available ways to increase $\mu$ without linearly increasing headcount or compute spent on checking.

The reverse coupling holds too: an organization with weak verification has a rational reason to resist portable trust, because accepting another party’s evidence is only safe if that evidence is trustworthy, and a security team cannot currently audit a stranger’s harness the way it can audit its own. That is why the axes are drawn as partly independent rather than orthogonal — knowing where an organization sits on one narrows, but does not fix, where it sits on the other.

Scenario One — Shared Custody

Condition: verification capacity scales with generation, and permission and trust models converge on a shared, portable standard.

Evidence formats extend today’s protocol-level convergence — MCP for tool calls, SLSA-style attestations for provenance, an SSDF-derived vocabulary for what was checked — into something that also standardizes what counts as sufficient evidence to merge without a human re-check ^{[5, 15, 14]}. A change vetted under one tool’s policy carries a portable record a different tool or organization can act on directly. Review capacity effectively pools across the industry instead of being rebuilt separately by every team, which is what keeps $\mu$ rising in step with $\lambda$ even as agent fleets scale. The developer’s role shifts furthest in this world: closer to the 20-percent execution share Claude Code’s usage study already measures than to the 70-percent planning share ^[4], with most attention spent auditing evidence bundles rather than reading diffs line by line.

Horizon: by the end of 2031.

Assumptions: the wire-protocol convergence already visible in MCP’s adoption extends to evidence semantics, not just tool-calling syntax; at least one major vendor is willing to make its verification evidence legible to a gate it does not control; regulators and insurers reward portable audit trails rather than penalizing them for diffusing accountability.

Observable indicators (pre-2030):

• A cross-vendor schema for agent-change provenance — extending SLSA or SPDX-style attestations rather than replacing them — gets implemented by at least two of the three tools compared in this article.
• Published case studies describe a change generated and pre-verified under one tool’s policy being merged elsewhere without full re-verification.
• Insurance, procurement, or compliance requirements begin referencing a named cross-vendor evidence standard rather than “vendor X’s own logs.”

Disconfirmation: if, by 2031, no cross-vendor evidence or provenance standard has meaningful adoption across at least two major agentic coding tools, or if every attempt at portability has been abandoned in favor of proprietary formats, this scenario is dead.

Scenario Two — Walled Verification

Condition: verification capacity scales with generation, but permission and trust models stay locked to each vendor.

Each vendor keeps building genuinely strong internal verification — Claude Code’s adversarial-review subagents and Stop-hook gates, Codex’s tiered sandbox with explicit approval triggers, Copilot’s mandatory human review before CI/CD ^{[3, 7, 9]} — and within any one tool’s walled garden, $\mu$ genuinely keeps pace with $\lambda$. What does not travel is trust between gardens: an organization using more than one agentic tool re-verifies from scratch at every seam, and switching vendors means re-earning an audit history from zero. This is the highest-lock-in cell of the four. Review-at-scale becomes real, but it is real per vendor, and comparing two tools’ actual defect or rework rates stays nearly impossible from outside either company, echoing today’s gap in independently reproducible productivity results ^[11].

Horizon: by the end of 2030.

Assumptions: each vendor continues to have a commercial incentive to keep its evidence format proprietary; verification investment keeps outpacing raw generation growth within each silo; no external pressure (regulatory, insurance, customer) forces portability.

Observable indicators (pre-2030):

• Measured escaped-defect or rework rates improve within single-tool shops but no comparable improvement appears in organizations that mix tools.
• Vendors publish increasingly detailed internal verification methodology (as Claude Code’s and Codex’s documentation already does) while resisting or ignoring calls for a shared evidence schema.
• Switching cost between agentic coding tools, measured by re-audit or re-onboarding effort, rises rather than falls.

Disconfirmation: if switching cost between major agentic tools measurably falls, or if a shared evidence format achieves real cross-vendor adoption before 2030, this scenario collapses into Scenario One instead.

Scenario Three — Common Rails, Thin Brakes

Condition: permission and trust models standardize, but verification capacity does not keep pace with generation.

The wire-protocol convergence already underway — MCP’s cross-vendor adoption is the clearest existing case ^{[5, 6]} — extends into shared permission scopes and portable identity for agents, making it easy for an agent authenticated and scoped under one policy to act broadly across an organization’s tools. But the harnesses, evaluators, and human review capacity that would earn that broadened access do not scale at the same rate. This is the scenario GitClear’s 2026 data already gives the earliest legible signal for: rising churn, rising duplication, and falling refactoring activity are what “the rails are shared but the brakes are thin” looks like in measured code, ahead of any formal standard existing yet ^[12]. Portable permissions without portable evidence is a specifically dangerous combination — it is easier, not harder, for a weakly checked change to reach a wide surface, because the standardized rail was built for convenience, not for proof.

Horizon: by the end of 2029.

Assumptions: permission-scope standardization is technically and commercially easier to ship than evidence-quality standardization, so it arrives first; organizations under competitive pressure adopt the convenience of shared rails before building matching verification; the GitClear-documented trend continues rather than reversing.

Observable indicators (pre-2030):

• A cross-vendor permission-scope or agent-identity standard ships and sees adoption, while no comparable evidence-quality standard accompanies it.
• Code-quality signals of the kind GitClear already tracks — churn, duplication, refactoring share — continue worsening rather than stabilizing after permission standardization ships.
• Security incidents or high-profile defects are increasingly traced to changes that had valid, standardized permissions but inadequate verification, rather than to unauthorized access.

Disconfirmation: if permission standardization ships without a corresponding rise in incidents or maintainability decline — that is, if organizations voluntarily pair broadened access with proportionally stronger checks rather than outrunning them — this scenario is falsified in favor of Scenario One.

Scenario Four — Supervised Plateau

Condition: neither verification capacity nor trust standardization matures much beyond its 2026 shape.

Agentic coding tools keep improving on the axes that are cheapest to improve — raw capability, measured by trends like METR’s time-horizon curve ^[10] — without matching gains in either the checking infrastructure or the cross-vendor trust apparatus. Organizations respond rationally by keeping human review tight and scope narrow: something close to today’s default posture across all three tools compared here, where read-only is the default and broad autonomy is opt-in and heavily gated ^{[1, 7, 9]}. The developer’s role does not shift as far as the other three scenarios suggest; it looks recognizably like 2026, with agents handling a larger share of narrow, well-specified tasks and humans still close to the 70-percent planning share Claude Code’s usage study already measures ^[4], rather than ceding most of it.

Horizon: through 2032.

Assumptions: verification tooling investment fails to outpace generation growth industry-wide; no dominant cross-vendor trust standard emerges; organizations respond to that gap by capping autonomy rather than accepting rising risk.

Observable indicators (pre-2030):

• Default permission postures across major tools stay conservative — read-only or narrowly scoped by default — rather than shifting toward broad autonomy as the industry norm.
• The gap between novice and expert verified-success rates that Claude Code’s usage study measures (roughly 15 percent versus 28 to 33 percent) fails to narrow at re-measurement ^[4].
• No cross-vendor evidence or permission standard achieves adoption beyond the tool-calling layer MCP already standardizes.

Disconfirmation: if broad-autonomy defaults become the industry norm, or if a cross-vendor trust standard ships with real adoption, before 2030, this scenario is falsified in favor of one of the other three.

The convergence already visible

Set the four scenarios aside for a moment and look only at what has already shipped. Claude Code’s sandboxed bash tool, Codex’s workspace-write tier, and Copilot’s GitHub Actions sandbox are three independently engineered solutions to the identical problem — let an agent act broadly inside a bounded space without asking permission for every step — and all three land on the same shape: a default boundary, isolated execution, and a required human checkpoint before anything with wider consequences happens ^{[2, 7, 9]}. Codex’s cloud tasks run in isolated environments and present a diff and a summary for review before a pull request opens; Claude Code’s cloud sessions run in isolated, Anthropic-managed virtual machines with scoped, short-lived credentials and full audit logging ^{[8, 1]}. None of this convergence was coordinated. It happened because the underlying problem — bound an agent’s blast radius, then make its output legible enough to check quickly — has a small number of workable solutions, and three well-resourced engineering organizations independently found the same neighborhood.

What has not converged is everything one level up from execution: what a permission scope means across a tool boundary, what evidence format a reviewer can rely on without reading the vendor’s own documentation first, and whether a change vetted by one tool’s policy can shortcut a different tool’s gate. MCP is the one place the industry has genuinely standardized, and it standardizes the syntax of a tool call — how an agent asks a system to do something — not the semantics of trust — how much a downstream party should believe what came back ^{[5, 6]}. That is precisely the distinction the four scenarios above are scenarios about: whether the unsolved half of standardization gets solved at all, and whether it gets solved before or after verification capacity catches up with generation.

The developer’s role, reconsidered

The 70-to-20 split Claude Code’s usage study already measures — most planning decisions made by the person, most execution decisions made by the agent — is not a projection; it is a 2026 measurement, taken across real sessions ^[4]. What differs across the four scenarios is not whether that split exists, but what happens on either side of it as tools improve.

In Shared Custody, the split deepens because evidence itself becomes portable: a reviewer’s real object of attention becomes the attached record of what ran and what it proved, not the diff, and that record is legible regardless of which tool produced it. In Walled Verification, the same deepening happens, but the reviewer’s competence stays vendor-specific — expertise in reading one tool’s evidence format does not transfer to another’s, which is a subtler version of the lock-in problem large organizations already navigate with any proprietary tooling. In Common Rails, Thin Brakes, the split deepens for the wrong reason: broad, standardized access outruns the checking that would justify trusting it, and the reviewing that does happen increasingly looks like triage against a rising, GitClear-documented backlog of churn and duplication rather than confident sign-off ^[12]. In Supervised Plateau, the split barely moves, because neither the infrastructure nor the trust apparatus that would justify moving it further has arrived, and organizations rationally hold the line at something close to today’s balance.

None of the four scenarios describes developers being removed from the loop. All four describe the loop’s shape changing — sometimes toward auditing standardized evidence at scale, sometimes toward a narrower, more anxious kind of triage. The DORA finding that AI functions as an amplifier of existing organizational strengths and weaknesses applies here too: a team with strong specification and test discipline in 2026 is the team best positioned to land in Shared Custody rather than Common Rails, Thin Brakes, and that positioning is substantially a present-tense choice, not a future one ^[11].

Two predictions that cut across all four scenarios

These are separated from the scenario apparatus above because they hold regardless of which cell the industry lands in.

Prediction One. A cross-vendor standard for some piece of agent trust infrastructure — most likely permission scopes or provenance attestation, extending SLSA- or SSDF-style work rather than inventing new primitives — will achieve adoption across at least two major agentic coding tools by 2030, because the commercial pressure that produced MCP’s adoption (avoiding N-times-M bespoke integrations) applies with similar force to trust infrastructure once enough organizations run more than one agentic tool at once ^{[5, 15, 14]}. Disconfirmed if no cross-vendor trust standard beyond tool-calling syntax exists by 2030, or if every major vendor still requires organizations using multiple tools to maintain fully separate audit trails with zero interoperability.

Prediction Two. The gap between novice and expert verified-success rates that Claude Code’s usage study currently measures at roughly 15 percent versus 28 to 33 percent will narrow rather than widen by 2030, because the scarce skill — specifying work precisely enough for an agent to verify its own progress — is exactly the kind of skill that becomes teachable, codifiable organizational infrastructure (in CLAUDE.md-style project memory, in shared verification harnesses, in codified review checklists) rather than staying individually tacit ^{[4, 3]}. Disconfirmed if the gap holds steady or widens at re-measurement, which would indicate the scarce skill is resisting codification rather than yielding to it.

Reading the wall

None of the four cards on the wall this article opened with has reached the horizon rail yet, and that is the honest position rather than a hedge. The evidence available in August 2026 is genuinely split in the way that makes a scenario matrix informative rather than decorative: real, independently engineered convergence on permission-model shape across three vendors, sitting beside zero convergence on trust semantics; a capability curve that keeps climbing by METR’s measure, sitting beside a maintainability curve that keeps falling by GitClear’s; a documented shift in where developer attention already goes, sitting beside no evidence yet about whether that shift is sustainable at ten times the scale.

What would move the whole wall at once, rather than one card at a time, is the same coupling the queueing argument above made explicit: a real trust standard would raise effective verification capacity without adding reviewers, which is the one lever available to every one of the four scenarios simultaneously. Whether that lever gets pulled — and by whom, and how — is not yet visible in the data. Anyone reporting a confident single 2035 for agentic coding tools is reporting a preference, not a measurement. The useful work between now and then is watching which of the twelve indicators above moves first, and having said in advance, as this article has tried to, what each one would mean.