AI Made You 10% Faster. The 10x Hides in Your Workflow

Sixteen experienced open source developers sat down to do 246 real tasks on their own codebases. Some worked with an AI assistant. Some worked without. The researchers at METR published the results in July 2025 and found that the developers using the assistant finished 19 percent slower than the ones who didn't. The number that stuck wasn't the slowdown. It was the follow-up survey, where those same developers reported feeling roughly 20 percent faster.

That 39 point spread between the stopwatch and the self-assessment is the cleanest measurement problem in enterprise AI, and a year on it's still unresolved. Feeling fast isn't the same as being fast, and neither is the same as shipping anything. Any serious answer to the question of how to get ten times more out of these tools has to start by admitting that the numbers people quote describe different layers of the same job, and most teams are optimizing the wrong layer.

The Gap Between Ten Percent and Ten Times

Two studies published this year bracket the problem. DX ran a longitudinal analysis across 40 companies from November 2024 to February 2026 and found that AI usage rose by 65 percent while pull request throughput rose by 9.97 percent. LinearB's 2026 benchmarks, drawn from 2.7 million pull requests and 83,000 developers across 253 engineering organizations, tell a more flattering story: developers in the highest AI usage band merged code at 2.3 times their June 2025 rate by May 2026, while developers using no AI merged at roughly the same rate as a year earlier.

Those two findings look like a contradiction. They aren't, because they measure different artifacts and different populations. DX tracked the average company and counted what leaves a developer's hands, which is a pull request. LinearB tracked the heaviest adopters, a group that self-selected for changing how work moves, and their lead widened fastest after January. Heading into the fourth quarter of 2026, the evidence base is finally large enough to argue about.

Then there's the survey layer. Research from the London School of Economics' Inclusion Initiative, run with consulting firm Protiviti and covering nearly 3,000 workers and 240 executives, found that professionals using AI report saving 7.5 hours a week, worth about $18,000 per employee per year. That's an entire workday recovered, by self-report, which is a real number and also a soft one.

Why Bolting AI Onto an Old Workflow Ceiling-Scraps

Picture a nine step process where step four is writing a summary. Drop a model into step four and you've automated maybe a fifth of a person's afternoon, because the human is still holding every handoff: tracking which input goes where, remembering who signed off, deciding when the draft is good enough to release. That's the usual shape of AI adoption right now. The tool sits inside a workflow designed around a person's working memory, and the person stays the scheduler.

The arithmetic is unforgiving. If the automated step is 20 percent of elapsed time and you cut it to zero, you get a 20 percent ceiling on paper and something closer to 10 percent in practice once you account for reviewing the output and fixing what it got wrong. Both of the biggest studies this year landed near that number, which is not a coincidence. It's what you get when you automate a station on an assembly line while a person still walks the chassis between stations.

There's also a submission layer to prompting that nobody budgets for. Manual prompting is manual context assembly: you decide what the model gets to see, you paste the right documents, you re-explain the situation every session. Every prompt is a small tax on human attention, paid by the most expensive worker in the loop, and it doesn't compound the way software is supposed to.

The Interface Problem MCP Solved

Anthropic open sourced the Model Context Protocol in November 2024, and the reason it spread to OpenAI, Google, Microsoft and AWS is arithmetic rather than sentiment. Connecting 20 models to 20 enterprise systems the old way means as many as 400 custom connectors, each with its own authentication quirks and its own maintenance schedule. Build one server per system and the problem goes linear. As of a late May 2026 pull from the official registry, there were about 9,650 server records, and Anthropic has cited more than 97 million monthly SDK downloads.

In December 2025, Anthropic donated the protocol to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. Governance under a foundation matters for the same reason it mattered for TCP: enterprises won't route payroll through a connector whose rules can change with one vendor's roadmap. The old alternative was a drawer full of proprietary adapters, and every company that has ever owned that drawer knows what it costs.

What the protocol actually enables is a loop. The model proposes a tool call, the host executes it against a server, the result lands back in the model's context, and the model decides the next step. That loop is the difference between an assistant that answers and an agent that acts, and it's also why context, not prompt phrasing, becomes the scarce resource. Stacklok's 2026 software report found 41 percent of surveyed software organizations running MCP servers in limited or broad production, which is a lot for a two year old standard and still a minority of the market.

Redesign the Workflow So the Agent Holds the State

The clearest articulation of the mechanism comes from a peer reviewed paper in the Harvard Data Science Review's Winter 2026 issue, by Ulla Kruhse-Lehtonen and Dirk Hofmann of DAIN Studios. Their argument: layering generative AI onto human centric workflows produces marginal gains because the workflow itself remains the constraint. Gains in the 2 to 10 times band become available when work is redesigned for agent execution rather than merely assisted by it. The pair describe an Agent OS framework and an A.G.E.N.T. playbook, and they report a global industrial firm cutting audit reporting time by 92 percent. They also flag their own limitation plainly, noting that these are practitioner reported outcomes which still need systematic replication.

The steps that hold up under scrutiny are unglamorous. Map the workflow as it exists, including the parts nobody writes down, like the three emails that only exist because the system doesn't talk to the CRM. Mark every handoff between a person and a system, because each one is a place where state gets lost. Decide, step by step, whether judgment is genuinely required or merely customary. Then rebuild the process so the agent is the default actor and the human is the exception handler, which is a different job description from the one most knowledge workers hold today.

This is where the build versus buy question gets sharp. Teams that treated agent infrastructure as a product to purchase rather than a process to redesign ended up with the same old ceiling and a bigger invoice, a dynamic visible in the acquisition appetite across enterprise software where buying a team that already rebuilt its process beats rebuilding your own.

Exception handling is the part that requires new instruments, not new headcount. Someone has to own the queue of runs that stopped mid-flight, and that queue needs a dashboard, a triage rule, and a definition of done that a reviewer can apply in under two minutes. Without that, the redesign just relocates the human to a place where they have less context than before.

The Metric That Actually Moves

Hours saved is the metric most teams pick because it's easy to collect, and it's the one that most reliably misleads. A task that took four hours and now takes one looks like a 75 percent gain until you notice that the three hours were spent in meetings people were happy to attend, and that the output needed two rounds of correction. End to end cycle time, the share of runs requiring human rescue, and the rework rate on agent produced output are the three numbers that tell you whether the redesign worked. None of them are flattering in the first month.

The cheapest available lever sits in training, not tooling. The LSE and Protiviti research found that 68 percent of employees had received no AI training in the previous 12 months, and that the gap between trained and untrained users was wider than the gap between generations. Trained employees reported saving 11 hours a week versus 5 for untrained peers, and 93 percent of trained staff used AI at all compared with 57 percent of untrained staff. Dr Grace Lordan, founding director of the Inclusion Initiative at LSE, put the priority directly: "For business leaders, the priority is clear: closing the AI training gap is one of the fastest ways to unlock measurable returns."

The structural point underneath that finding is easy to miss. Training is where a workflow finally gets documented, because you can't teach someone to hand a process to an agent without first writing down what the process is. The training gap and the redesign gap are the same gap wearing two different names.

What Breaks on Step Seven of Twelve

A twelve step agent workflow works beautifully in a demo and degrades in production, and the failure usually isn't the model's reasoning. It's state. When a run touches a CRM, a spreadsheet and a ticketing system, the agent has to carry forward what it learned without either dropping context or drowning in it, and the current answer is some mix of retrieval, summarization and hope. Duplicate tool calls are the other open problem: if a step times out and retries, did the invoice go out twice? Idempotency keys solved that for payments, and there's no universal equivalent across the average agent stack.

Governance adds a second constraint, especially in regulated industries. An agent that makes a judgment at step seven needs to leave a trail a human can read at step twelve, and most observability tooling today records traces that are legible to engineers and opaque to auditors. That mismatch is why so many pilots stall at the boundary of the compliance team rather than the model vendor.

The handoff remains unsolved. A person who notices an agent has gone sideways at step seven has no standard way to pause the run, correct the state, and send it back with enough context for the agent to finish the job, which means most organizations currently resolve that situation by restarting from zero and paying for the same tokens twice. Building that restart mechanism is a real engineering problem with a measurable payoff, and it's the difference between the ten percent that shows up in the throughput data and the ten times that keeps showing up in the conference keynotes.