GitHub Copilot is now used across roughly 90% of Fortune 100 organisations, with 4.7 million paid subscribers as of early 2026 — 75% year-over-year growth. Cursor has crossed $2B in annual recurring revenue on over a million paying users, and claims 64% of Fortune 500 companies as customers. JetBrains' January 2026 developer survey found 74% of developers worldwide have adopted a specialised AI coding tool at work. The adoption question is largely settled. The question every IT leader actually needs answered is different: what changes structurally when a meaningful share of code in production was written, reviewed, or refactored by a model rather than a person — and what does responsible delivery-team governance look like once that's true.

This post continues directly from Application Modernisation. AI-assisted development is, among other things, becoming one of the fastest ways to work through a legacy backlog — but the tooling landscape and the governance questions it raises are distinct enough to earn their own post.

Assistant Versus Agentic — A Real Distinction, Not a Marketing Line

Most enterprise AI coding conversations still default to the "autocomplete" mental model: a tool that suggests the next line or function while a developer drives. That model describes Copilot's original product well. It does not describe where the category has moved.

Agentic coding tools — Claude Code, Cursor's agent mode, Copilot's newly-added Plan mode and custom agents — operate over multi-step tasks with much less continuous human steering: given a ticket or a bug report, the tool can read the relevant parts of a codebase, plan an approach, write the change across multiple files, run tests, and iterate on failures before presenting a result for review. The difference isn't speed, it's scope of delegation. An assistant makes a developer faster at driving. An agentic tool takes the wheel for a bounded stretch and asks for review at the end.

This distinction matters for adoption strategy because the two categories carry genuinely different risk profiles and need different guardrails — treating an agentic tool's output with autocomplete-level scrutiny is where quiet quality problems start.

Why Enterprises and Startups Are Choosing Differently

JetBrains' 2026 survey data shows a clear split by company size, and it isn't random. Startups lean heavily toward Claude Code — roughly 75% adoption — for agentic, multi-step work, prioritising raw capability and satisfaction (Claude Code led JetBrains' April 2026 "most loved" ranking at 46%, against Cursor at 19% and Copilot at 9%). Enterprises with 10,000+ employees lean toward GitHub Copilot at 56% adoption, prioritising distribution: it ships inside the GitHub environment engineering already lives in, inherits existing enterprise licensing and security review, and requires no new vendor relationship to stand up.

Neither preference is "wrong." A startup optimising for a small team's raw output per engineer and an enterprise optimising for governed rollout across thousands of developers are solving different problems, and the tool that wins each context reflects that rather than a simple capability gap.

The Governance Question Most Rollouts Skip

The rollout decision most organisations get right is which tool to license. The one most skip is what changes in code review, testing, and accountability once a meaningful share of pull requests originate from an agent rather than a person typing every line.

Three questions define whether a rollout is actually governed or just deployed:

Attribution and review depth. Does your code review process treat an AI-generated pull request identically to a human-authored one, or does "the AI wrote it" quietly lower the bar for scrutiny? The organisations having quality incidents with AI-assisted code are consistently the ones where review depth dropped because the change looked complete and well-formatted — AI output is disproportionately good at looking finished while still being wrong.

Secrets, licensing, and IP exposure. Agentic tools with repository-wide context and multi-file write access are a materially larger exposure surface than an autocomplete suggestion box. Does your rollout include the same secret-scanning and dependency-licensing discipline this series covered under DevSecOps, applied specifically to AI-generated changes?

Skill atrophy in the team that has to own the result. If a junior engineer accepts an agent's multi-file change without being able to explain what it does, the organisation has shipped code nobody on the team can maintain when the agent isn't available or the change breaks in a way the agent didn't anticipate. The rollouts holding up well are pairing AI-assisted velocity with an explicit expectation that the human reviewer can explain the change, not just approve it.

What This Means for Every IT Leader

1. Does your organisation have a stated policy for what level of human review an AI-generated change requires, or is that decision being made ad hoc by individual reviewers? Absence of a policy doesn't mean no risk — it means inconsistent risk, which is harder to reason about after an incident than a policy you can point to and revise.

2. Are you measuring AI coding tool ROI as raw output (lines, PRs, velocity) or as outcomes (defect rate, time to production incident, maintainability)? The first metric is easy to show a board and easy to game. The second is what actually determines whether the investment paid off.

3. If your primary AI coding tool vendor changed pricing or was acquired tomorrow, how exposed is your delivery pipeline? This category is moving fast enough that vendor lock-in risk deserves the same scrutiny applied to any other core delivery-chain dependency.

The Bottom Line

The adoption argument is over — most enterprise developers now use some form of AI coding assistance, and the tools genuinely capable of agentic, multi-step delegation are no longer a research preview. The open argument is governance: whether review depth, security scanning, and team ownership scale with the amount of code an agent is trusted to write, or whether they quietly stay calibrated for a world where every line had a human typing it. That gap, not the adoption number, is what will separate the organisations that get a real productivity gain from the ones that get a slow-motion quality problem.

The next post closes out the Software & Development phase with a look at the toolchain underneath all of this: GitLab, GitHub, and Azure DevOps, and which platform actually fits which organisation.

Sources: GetPanto — Copilot Statistics, GetPanto — Cursor Statistics, Konabayev — AI Code Assistant Statistics 2026.