The Halving Question

Some time ago I started working in a codebase I had never seen. There was no colleague to ask, so I asked the agent. It answered the first question and the tenth with the same patience: why this module exists, where a request actually enters the system, which parts everything else depends on and which are old workarounds nobody ever cleaned up. Within days I was making changes I could defend. The same orientation used to cost me weeks.

Moments like that make a familiar question sound reasonable. Every conversation about bringing AI into an organization arrives at some version of it eventually. Will this cut the work in half? Halve the time, halve the cost, halve the learning curve.

I keep giving two different answers, and now I think there is something beyond the difference between them that is interesting.

Two answers

Where the bottleneck is access to knowledge, large jumps are real. Learning a system, getting oriented in a new domain, finding out how something actually behaves. The agent is available at any hour, never annoyed by the umpteenth question, and unbothered when the questions are basic. Asking a colleague again has a social cost. Asking the agent has none, so you ask until you actually understand.

Where the bottleneck is accountability, the arithmetic changes. A first draft that used to take me a day now exists in minutes. The day did not disappear. It moved into reading the draft critically, testing it, understanding it well enough to stand behind the result. Producing became fast. Standing behind something did not.

The rollout data matches this split. When Microsoft gave tens of thousands of its engineers AI coding agents, adopters merged roughly a quarter more pull requests, a gain that held steady over months. That gain is real, and it is nowhere near a halving. The authors add the honest caveat that a merged pull request is not the same as delivered value.

If that were the whole story, the halving question would only need a smaller number. Promise twenty percent instead of fifty and calibrate expectations accordingly. But the interesting effects start beyond the arithmetic.

The gain without a baseline

The larger effect of cheap execution is not that existing work speeds up. It is that work which could never justify its cost becomes reasonable. The backlog item that lost every prioritization for two years. The internal tool that serves five people. The audit nobody could spare a week for, now running quietly alongside the roadmap.

Notice what this does to measurement. None of that work shows up in a before-and-after comparison, because the before never existed. There is no baseline for work that was never going to be done. I suspect this is a good part of why the research keeps finding modest averages while practitioners report transformation. The studies measure the old work getting somewhat cheaper, and the practitioners are living through new work becoming possible. Both are looking at something real. They are not looking at the same thing.

It also means the halving promise fails twice. It disappoints on the old work, where gains are real but ordinary. And it aims all measurement at exactly that spot, so the larger gain never appears in any report. A leader who promises halving has chosen the one metric guaranteed to make the effort look like a failure.

The default nobody chooses

Expansion sounds like the ambitious scenario on a slide, the one you get to pick. It is the default. Compilers, object orientation, code generators: every earlier productivity wave was absorbed by demand for software nobody had previously dared to plan. The gains did not arrive as slack. They arrived as raised expectations. I notice it in my own standards, where work I would have proudly shipped two years ago now reads like a first pass.

So the choice leaders believe they have, between banking AI as cost reduction and investing it in ambition, is narrower than it looks. Expectations will move with the tools whether or not anyone plans for them. The real choice is between expansion that is selected and expansion that accumulates. Every newly affordable idea finds an advocate. Follow them all and attention spreads until everything is built halfway and owned by nobody. The desk-level version of this failure is skimming agent output. The organizational version is a roadmap that grows faster than anyone can care about it.

When execution is cheap, choosing what not to build becomes the real work of leading.

What to promise

A leader who introduces AI makes a promise whether they intend to or not. Mine would be sober on the near side and specific on the far side. Expect modest, honest gains on the work we already do, with a dip at the start while we learn, planned for instead of explained away. And expect a growing list of things we finally get to build, each one chosen, each one with an owner who wants to stand behind it.

One practice keeps that promise honest. The first automation worth doing is often not AI at all. A surprising share of any team’s work is mechanical, and deterministic automation, from scripts to static checks, handles it without surprises. It builds the thing an AI rollout will later spend, which is trust. And starting has become less risky. Automating a workflow used to be a bet that every step could be made deterministic; efforts died quietly when one step could not. Now the ambiguous remainder has somewhere to go, so you can commit with more confidence. Start at the predictable end, and let AI catch what resists it.

I will not pretend the selection part is easy. Refusing cheap work is harder than refusing expensive work, because the cost argument has left the room and someone always cares about the idea. I feel the pull of yes in my own backlog every week. But the halving question, useful as it is, asks only what gets cheaper. The question that decides how this goes asks what we will build now that we can, and what we will decline so the rest gets built well.