McKinsey surveyed 1,719 executives across 97 countries this spring. Eighty percent of those who use AI in their own work say it made them more productive. Sixty-three percent of their organisations report no measurable earnings impact at all. Six percent attribute 5% or more of EBIT to AI.
Both halves are true. The gap between them is the whole subject.
I have spent the past year building with agentic coding tools — orchestrating parallel sessions, running rebuild benchmarks, and modelling the second- and third-order effects on employment. The individual gain is not in question. What I keep finding is that the gain gets absorbed before it reaches the P&L, and that the absorption is structural rather than a tooling problem.
Not coding speed. The measure worth watching is how long a task an agent can finish end to end. METR’s benchmark puts the frontier at roughly five hours of human-equivalent work at 50% success, doubling every seven months across the full 2019–2025 run and every three months since 2024.
That trajectory does not primarily make developers faster. It changes who can build software at all. Today, an analyst in finance who spots an inefficiency writes a proposal, quantifies ROI, and queues behind IT. Three years out, they build it themselves in an afternoon. The addressable automation set changes by an order of magnitude rather than a percentage — and it changes in every function at once, not just in engineering.
That is the thing to plan around.
Three areas, on cost and revenue optimisation. Growth is too industry-specific to generalise, so I leave it out.
1. Time to market in product development. The least contentious place to start. Measure it as end-to-end lead time from decision to production, not as coding throughput. If coding is 20% of your cycle, a 10x on coding buys you 1.2x. Amdahl does not care how good the model is.
2. Operational efficiency. The largest pool: automation of internal processes, AI assistance in knowledge work, agent-executed workflows, and service quality. This is where self-service either happens or does not.
3. Decision quality. Risk, pricing, targeting, issue detection. Hardest to measure, longest to compound.
Put approximate magnitudes at the area level, not per team. Per-constituency percentage targets invite the honest answer: “that is unrealistic and I will not own it.”
Self-service. The proposal → business case → IT queue path is the real tax. Removing it is worth more than any model upgrade.
Verification capacity. When generation is nearly free, the constraint moves to review, test and control. Almost nobody budgets for this. It is the bottleneck that arrives in year two.
Platform, with data inside it. The platform’s job is to minimise the barrier to entry and usage. Data belongs in it, not beside it.
Federated supply. Core platforms, product IT, engineering practice and tooling, data, AI components and model risk. Bundling these under a single CTO line is a planning error, not an org-chart preference.
Change management, cross-cutting. Training, mindset, depth of adoption. It touches every constituency, which is exactly why it ends up orphaned.
One variable does most of the work in that survey. Seventy-three percent of the high performers fundamentally redesigned workflows. About a quarter of everyone else did. Seats bought, licences deployed, adoption dashboards green — none of that discriminates. Redesign does.
Three things follow.
Name an owner. Shared ownership of a workstream means nobody answers for underdelivery.
Redesign one workflow before scaling seats. It is the cheapest way to find out whether your gain is absorbable at all.
Watch the entry level. Stanford’s payroll data has workers aged 22–25 in the most AI-exposed occupations sitting about 19% below where they would be tracking their less-exposed peers, up from 15% a year earlier — with no comparable effect on experienced workers and no economy-wide displacement. The aggregate is quiet. The margin is not, and the margin moves first.
Agentic journey is my working record of building products with Claude and Codex as a non-programmer: experiments, benchmarks and missteps, written up as they happen. It isn’t a how-to. Where the numbers come from someone else, they’re linked.