The AI Velocity Report: Q2 2026

This is our third AI Velocity Report, the running account of how AI changes the way software gets built in production. The numbers sit alongside the practice set out in our AI-augmented development pillar guide, which covers the definition, the lifecycle, and the governance model behind the figures.

Our earlier reports led with speed and cost: AI-authored code climbing from 51% to 84%, delivery 40-50% faster, a public-API tender won at roughly half the conventional price. Those numbers still hold. They are no longer the most interesting thing happening, though, and this issue is built around saying why.

The speed and the saving are real. The immediate consequence is a hard, genuinely unsolved problem: when productivity keeps compounding, how do you put a confident number on a piece of work before you have built it? That estimation challenge runs through this issue, and we have written it as it actually is rather than as a solved case study. But the saving is not the interesting part. The interesting part is what it buys: the headroom to do work properly that was previously too expensive to attempt, turning cheaper software into better software.

Why did AI-authored code move from 83% to 91.6%?

In our last Between Reports issue we noted that the AI-authored figure had settled at around 83%, that it had held there for a couple of months, and that the plateau was a more interesting data point than continued growth. We said we would unpack it. Here it is.

The plateau was never a technical ceiling. It was a human one, and a deliberate one. People adopt at different speeds, and we let them get comfortable rather than forcing the pace. A team pushed ahead of its own confidence is a quality risk, and quality is the thing we are least willing to trade. The 83% reflected an adoption curve, not a limit of the tools.

This quarter the figure moved to 91.6% across live production work. Two things moved it: further adoption across the team as more engineers reached that point of comfort, and a portfolio that has shifted toward projects in early phases, where AI-authored code runs close to 100%. The headline is sensitive to the mix of work in flight, which is worth stating rather than hiding behind a single clean number.

The spread underneath is the honest signal:

• Integration projects: 100%. Well-defined contracts and deterministic behaviour, the kind of work the models are now genuinely excellent at, with senior engineers reviewing rather than writing.
• Mobile apps: 88.6%, our lowest. Mobile carries platform-specific behaviour and a class of problems where the models do not yet have the depth our senior mobile engineers have. More of the work stays with people, and the figure says so.
• Pre-live work: typically 100%. Greenfield projects built AI-natively, before they carry the constraints of a production system.

Every line, on every project, still goes through senior engineer review, ISTQB-qualified QA, and our ISO 27001 framework. The percentage measures where the first draft comes from, not what ships unread.

Why is the work so much cheaper? The harness

Everything in this issue rests on one thing, and it is not the model. It is the harness: the governed scaffolding built around the model so that AI-produced code is consistent, reviewable, and held to the standard a senior engineer would be held to.

In practice that is a small set of things applied relentlessly:

• Architecture rules written as code the model reads before it writes.
• A golden-path instruction layer encoding the non-negotiables: use existing primitives before inventing new ones, design tokens rather than magic numbers, route copy through internationalisation, gate permissions through a proper layer.
• Reusable skills for the motions a team repeats, so ‘build a consistent screen’ is one reliable instruction rather than a fresh negotiation.
• Tiered automated gates: cheap checks on every change, heavier suites on promotion, full regression nightly, with requirement-to-test traceability that fails the build when an acceptance criterion has no test covering it.

None of this is new thinking dressed up for AI. The harness is the AI-first re-imagining of Codenative, an internal tool we have run for around four years. Codenative was model-driven rather than AI-driven: it encoded our delivery, technical, and engineering best practice, drawn from real project experience, and used it to scaffold and accelerate builds consistently. When AI coding matured we did not start from a blank page. We re-expressed that body of knowledge as the rules and skills a model reads before it writes. The hard part was never the syntax; it was the accumulated judgement about how we build well, and that already existed.

We promised in Q1 to evolve our accelerator library and our cross-project learning. Both turned out to be the harness seen from different angles. An accelerator is the harness made portable, a starting point a new project inherits rather than rebuilds. Cross-project learning is what happens when a pattern proven on one engagement becomes a skill the next one gets for free. The effect compounds: the more the harness encodes, the faster and more consistent each subsequent project, because the model inherits the context at no cost.

Codenative is also the basis of our accelerators, and there are two tiers to them. The harness accelerates any build, because every project inherits the same encoded standards. On top of it sit more fully formed accelerators, with starter modules, in the domains where we have specific expertise. Those take a new project well past scaffolding before its first line is written.

In practice this is showing up at the proposal stage. Recent proposals for large, business-critical, greenfield cloud-native Azure builds are landing at 28 to 34% of what the same work would have cost before AI, at the same quality or better. Put as a saving, that is 66 to 72% off the pre-AI cost, up from the roughly 45% saving we reported last quarter on the public-API tender that came in at 55% of conventional cost. The trend is steady, compounding improvement as our accelerator and harness usage deepens, not a sudden step change.

A recent enterprise operations platform, delivered with full enterprise-grade security, accessibility, and test coverage, came in lower still, at roughly 23% of a conventional build’s cost. The rigour was not sacrificed for speed; it was encoded once and applied automatically.

Two things are worth being precise about, because a number like that invites the wrong conclusion. First, it is largely a function of the accelerators and the harness, not just raw AI gains. The models improved, but the leverage is four years of encoded standards and the domain accelerators that sit on top of them. Second, humans are still a large part of the loop, and this is emphatically not vibe coding. Vibe coding can quote a similar cost reduction, but it gets there by skipping the team and the quality process and hoping the output holds. We get there with full teams and proven quality processes, with AI accelerating and improving established, proven practice toward a known outcome. AI did not replace engineering rigour, it industrialised it. The headline can look the same as the vibe-coded one; what stands behind it could not be more different.

The stakes are the point. These are enterprise systems deployed on day one as the primary system of a high-traffic, demanding business, not a startup that can afford to make mistakes and defer scaling until later. Vibe coding’s ‘ship it and fix what breaks’ is a reasonable bet when there is room to fail. It is not a bet you can take when the build is the business from the day it goes live.

Not every project starts on an accelerator. A good deal of our work is in-flight on existing systems, and there the headline economics do not apply on day one. We still introduce the harness, but with no accelerator to inherit it from, it has to be built bespoke to the project. That works best as an evolutionary effort rather than a one-off: the harness grows with the codebase, encoding each pattern as it proves itself, rather than being imposed up front. Even then, that work sees ever-increasing improvement from AI acceleration as the bespoke harness fills out. The gains compound either way; they simply start sooner when an accelerator is already carrying them.

The catch, and the reason the longest section of this issue is about estimation, is that a harness which keeps improving is exactly what makes a piece of work hard to price. We go much deeper on how the harness is built in an upcoming Between Reports issue, and our harness engineering guide covers the mechanics for teams who want to adopt the same approach.

How do you estimate for a rapidly more productive world?

Estimation is one of the most important and least glamorous skills a software team has, and it is one we have spent years getting good at. It is worth explaining how, because it is the part of our practice that AI disrupted most, and the part where we have had to work hardest to stay honest.

We estimate at four stages, and we have always tracked the variance between them as part of our weekly metrics.

Tracking the variance across those four stages, every week, is how we know whether we are estimating well rather than merely estimating. For years the answer was that we were good at it. The entire point of the discipline is to make Stage 1 trustworthy, because a confident, accurate Stage 1 is what lets a client plan, budget, and commit. In our experience clients value that as much as almost anything else we do.

Then AI arrived and broke the calibration. Teams that had been reliably accurate watched their Stage 1 to Stage 4 variance widen, because years of hard-won estimating instinct were built on productivity assumptions that were suddenly wrong. The goal did not change: accuracy, predictability, and value for money. Not undercooking an estimate, which erodes trust the moment a project overruns. Not sandbagging it, which is overcharging with extra steps. The challenge was to re-establish genuine accuracy against a baseline that now moves every quarter.

Why ‘just ask the AI to estimate’ is misleading

The obvious shortcut does not work. Ask a language model to estimate the work and, out of the box, it estimates badly, and it silently assumes pre-AI delivery methods. Push it to assume AI-accelerated delivery and, in our experience, it stays inaccurate. The model has no calibration against your team’s actual, compounding productivity; it pattern-matches to a world that no longer exists. Estimation turns out to be one of the places where ‘just ask the AI’ is actively misleading.

What actually works

What works is narrower and more deliberate. We build a project-specific estimation model rather than relying on a generic one, and we dovetail it with plan mode, where the model produces a structured work breakdown before any code is written. That breakdown is made to mimic the decomposition a senior estimator does in their head: split the work down, mark what is already covered by an accelerator or the harness, isolate the genuinely novel parts, and price each accordingly. The same model that produced four useless guesses out of the box becomes useful once it is grounded in this project, this codebase, and our own delivery history.

Around that sit the disciplines we apply everywhere:

• Coverage before effort. Work that maps onto an existing accelerator and our codified rules starts close to scaffolded; work in unfamiliar territory does not. The accelerator library and cross-project skills are, in estimation terms, the difference between starting at 80% and starting at zero.
• Grounded in the codebase. For existing systems, we estimate against the real structure and integration surface, not an analogy to something that felt similar.
• Tokens as a line item. Assumed model, assumed volume, price per million, calibrated against our own metered consumption rather than guessed.
• Calibrated, but discounting the past. Our four-stage variance history feeds the model, weighted toward recent projects, with older actuals treated as a ceiling on effort rather than a forecast, because the baseline only moves one way.

Why we cap budgets rather than fix prices

The commercial model on top of this is deliberate, and it is not fixed price. We rarely work fixed-price and do not recommend it, because it pushes both sides into defending scope rather than improving the product. We work to fixed feature budget caps with shared responsibility instead. The four-stage variance tracking is what lets us set those caps with confidence, because we know our own accuracy and where it degrades. Both teams then work in partnership to the same caps and the same goal, which in our experience is what actually delivers.

It also has a quiet upside. As our AI gains keep improving, they open up more headroom inside those budgets as a project progresses. That headroom can only benefit the client, whether as more delivered for the same cap or as budget that is never spent.

And increasingly, that headroom is spent on making the solution better, not just cheaper. This is the shift worth naming, and the through-line of the whole issue. A saving is the easy thing to talk about. The more valuable thing AI buys is the room to do the work properly: design for every device, harden the system for day-one load, and build proactive maintenance in from the start. Work a tighter budget would once have forced us to cut now fits inside the cap. Cheaper is the headline; better is the point.

We are not going to claim this is solved. We are measurably better at it than a year ago and still wrong often enough to stay humble, and the projects where our variance is widest are predictably the ones with the largest human fraction: mobile, and anything genuinely novel. The public-API tender we won at roughly 55% of a conventional estimate, and the enterprise platform delivered for roughly 23% of a conventional build, both came in on estimates produced this way. That is evidence the approach holds across a whole project, not evidence that the per-line economics have stopped shifting.

If there is one transferable idea in this issue, it is this. When writing code is nearly free, estimating software stops being about construction and becomes about specification and verification, plus a token bill, plus a premium on the genuinely unknown. The teams who estimate well from here will be the ones who get good at pricing thinking and checking, not typing. There is more on the economics for buyers in our guide on AI-augmented development return on investment.

How is designing for every device suddenly affordable?

Design is the clearest example of that budget headroom going into a better product rather than just a cheaper one.

For more than a decade, responsive design has been the norm: one layout that adapts across screen sizes. Designing properly for each device, rather than stretching a single design to cover all of them, was a luxury most budgets could not justify. That has changed. When both the design and the automated tests that verify it are cheap and quick to produce, there is no longer a good reason to skip the device-specific work.

The route to it is a two-stage pipeline that any team could adopt:

1. Concepts with Claude Design. Generate several pre-code concepts and wireframes against design systems you have actually invested in, then take a single chosen concept forward.
2. Code-first prototyping. That concept is generated directly as real, typed, tokenised application code against a living design system, validated on the target device from day one.

Instead of building throwaway mockups that later have to be rebuilt, a successful prototype is most of the way to shippable, because there is no translation tax between the design that was agreed and the code that was built.

On a recent native mobile build, that produced a substantial, production-bound application over a three-month window, with throughput that compounded as the harness matured. Stakeholders reviewed working software on the target hardware rather than interpretations of it, which collapsed the feedback loop to the length of a single AI iteration. The transferable point is not the cadence. It is that exploring many design options and building the chosen one properly used to be a trade-off, and is no longer. Our guide on taking AI-built software from prototype to production covers what that prototype still needs before it ships.

What does ‘better while it runs’ look like?

The other place ‘better’ showed up this quarter is in support and maintenance. It is the development we are most interested in, so we are giving it the next Between Reports issue in full rather than compressing it here.

The short version: our maintenance practice has always rested on knowing what good looks like across a wide range of systems, and we have now automated the analysis. A daily pipeline pulls operational telemetry from every client’s live services (application and database metrics, cluster health, uptime, and security signals) and has Claude read it as a senior platform engineer would. It returns a small, opinionated set of findings each morning, every one required to cite a real number and name the affected service. Each finding can become a tracked work item in one click and carries a lifecycle that reconciles itself against our work-item system, so the register stays honest without manual upkeep.

It is not a product, and it is not generic advisor-style insight. It is opinionated analysis grounded in best practice and in what we know good looks like. How we keep it cheap and safe to run is the subject of the next issue.

Are the AI tools starting to stabilise?

A quieter observation runs underneath this quarter, and it is worth stating because it is new. For the first time since we started publishing these reports, the work has felt like consolidation rather than evaluation. The 3-month review cycle still runs, but it surfaced far less churn this time. We are settling onto a smaller set of tools we trust, largely Anthropic’s, instead of constantly benchmarking the next thing.

That is not us declaring the frontier settled. It is a small, real sense of stabilisation after a genuinely unstable year. Anthropic was part of that instability: the degraded Claude Code month we wrote about in April was one example, and there were others. Over the last few weeks it has settled, and the platform has felt dependable in a way it did not for parts of the spring.

The move from Cursor towards Claude Code is the clearest expression of this consolidation. We began it for ownership reasons, after the proposed SpaceX acquisition of Cursor, and Claude Team Premium seats have since gone a long way to reducing our cost per engineer, trading usage-based charges we could not predict for seats we can.

One honest caveat, because it matters to anyone planning around the same economics. Those Premium seats are currently benefiting from generous allowances and, over the past few weeks, a number of usage resets triggered by service issues. Some of the cost advantage we are seeing right now is a temporary by-product of a bumpy period, not a settled price. We are not banking on it holding as allowances normalise, and we would caution anyone else against doing so.

What models and tools changed this quarter?

The model line-up is now three tiers. Claude Opus 4.8 handles deep reasoning, plan mode, estimation, and the hardest problems. Claude Sonnet 4.6 is the primary execution model for coding and test authoring. Claude Haiku 4.5 handles high-volume work, including the daily maintenance analysis pipeline. For our own work we call Anthropic’s API directly rather than routing through Azure AI Foundry. Foundry remains a strong choice, and we still recommend it where it fits, but the additional latency it introduces is increasingly tipping our solution recommendations toward the Anthropic API as well. Our continued evaluation of Foundry is primarily aimed at closing that latency gap. The narrower model selection is not a constraint in practice, because we mostly run Haiku for high-volume work and Opus for hard problems.

One short-lived exception is worth a candid note. We also used Fable for the few days it was available, before it was banned. In our hands it read as an Opus-level step up rather than the revolutionary risk the ban implies, though a few days is not long enough to judge that fairly. We would welcome the chance to evaluate it properly if and when the situation is resolved.

The bigger change is the platform underneath the models. We consolidated the whole business on Claude Team, after moving through GitHub Copilot and then ChatGPT Team. Satisfaction is much higher across engineering, business analysis, QA, marketing, and compliance, largely because it integrates with our own data and knowledgebase.

For engineering specifically, the move from Cursor to Claude Code, described above, is now most of the way there. To be precise about naming, because it is easy to get wrong: Claude Code is included in our Claude Team Premium seats, and the individual Max plan is a separate thing.

Two pieces of our own infrastructure do the quiet work behind the numbers:

• AI usage metering. A daily workflow pulls token and cost data from Anthropic, Cursor, and GitHub Copilot into our Azure data lake, surfaced on an internal usage page. This is what makes token-cost estimation calibrated against real consumption rather than notional.
• TTD Delivery MCP and plugin. Our Talk Think Do Delivery Model Context Protocol (MCP) server fronts Azure DevOps and Jira Service Desk and is opinionated about the fields and process we use. A Talk Think Do Delivery plugin gives the firm org-wide skills for creating work items in house style. Most of our Azure DevOps interaction now happens through Claude chat, with skills giving consistency and the MCP enforcing validity.

What we dropped

• OpenSpec. Retired in favour of our own delivery infrastructure. We kept the planning and change discipline; the artefacts moved from files in the repository to Azure DevOps tasks linked to work items. The full reasoning is in Why we’ve moved away from OpenSpec. Spec-driven delivery is not waterfall, and we still run it.
• Cursor as the primary IDE. Engineering work moved primarily to Claude Code for the ownership and cost reasons above. We keep our thinking portable, so this was a swap, not a rebuild.
• ChatGPT Team and GitHub Copilot. Both retired from delivery once Claude Team proved itself across the business. Copilot is now metered only so it stays in our cost comparison.

What’s Next

Two Between Reports issues before the next quarterly:

1. Proactive maintenance and support, in full. The daily pipeline that reads operational telemetry like a senior platform engineer, and how we keep it cheap and safe to run.
2. A deeper look at the harness itself. Rules as code, the golden path, reusable skills, tiered enforcement gates, and requirement-to-test traceability, going well past this issue’s summary.

For the wider practice behind these figures, browse the Talk Think Do guides hub.