The second-order AI multiplier
How much faster are we with AI? The answer to this question can often be a number.
"2-x. 3-xā¦ more?"
Then, the number gets applied to an estimate. The estimate goes into a plan. Everyone moves on.
The problem with these estimates is that a single multiplier assumes all work is the same kind of work.
Contents
- 2-3x is a defensible figure
- We must consider constraints
- The new arithmetic
- Capacity doesn't just evaporate
- Which implies a strategy, not just a heuristic
- What this means for sizing
- The bigger question
2-3x is a defensible figure
There's some work where we know that AI acceleration is genuine. This is work that is already well understood, well defined, and mechanically tedious.
Some examples of this are:
- Endpoint creation
- Component scaffolding
- CRUD layers
- Like-for-like ports from one stack to another
- Test harnesses
- Migration scripts
- Glue
With each of these examples, it's completely reasonable for throughput gains to be of 10x or more. Especially if their starting baseline was poor.
If we blend it back into a real team doing a real mix of work, something like 2-3x is the defensible figure. That's roughly where the emerging research lands too.
But we must look carefully at what's actually been claimed. We are adding multipliers to already well-defined, table-stakes portions of the job.
We must consider constraints
The other category is work that is architecturally significant.
Such as:
š Decisions that are expensive to reverse.
š Problems that are badly defined at the moment someone asks for an estimate.
š Choices where the penalty for a bad design is paid down over years.
Here, AI acceleration is close to irrelevant because the work is constrained by consensus.
A good example of this is the arguments leaders have about which direction is least wrong. Or the slow business of getting a group of people to agree on something they can all live with.
It's these decisions, problems and choices that get flattened.
The new arithmetic
If all of a team's work were table-stakes, that work would be low value. Commodity work is, almost by definition, work that doesn't differentiate you. It's also usually the minority of what good engineers spend their time on.
So I propose that the direct AI gain should be this: a 2-3x acceleration of the least valuable portion of the work.
A large percentage of a small value is still a small value. It is progress. But it isn't the transformation the multiplier implies, and it's a thin foundation for a business case.
Which is why the direct multiplier is the boring answer.
The second-order effect is the more interesting one.
Capacity doesn't just evaporate
AI can reliably compress commodity work. For example, a team that previously spent forty percent of its time on scaffolding, plumbing and ports can get time back. But the time they gain back should be spent on the hard problems that were being starved of attention.
They should be able to spend time supporting work they never get around to, which happens indirectly because of "2-3x gains".
Nobody ever typed their way to a better domain model.
Deep work improves through the number of times you can afford to be wrong before you commit.
Consider what changes when a prototype costs a day instead of three weeks:
- You build three competing architectures and run them into a wall, instead of debating.
- You spike the risky integration before it's on the critical path, not after.
- You put something in front of a user in week one and discover the requirement was wrong while it's still cheap to be wrong.
- You genuinely throw work away, because the sunk cost is small enough to ignore.
That one changes behaviour more than all the others combined.
By claiming back the necessary time to iterate:
ā You are able to test-and-learn.
ā Decision quality goes up.
That's the second-order effect.
Which implies a strategy, not just a heuristic
If that's right, you should look at what the organisation builds repeatedly. Deliberately push this down the value stream. An example of this could be as simple as consolidating all the different ways your software communicates with one another. For example, extracting out an opinionated HTTP SDK, with standardised error handling and telemetry: it should move from a one-off build a team does from scratch, to a shared tool the whole company can reuse, to infrastructure nobody thinks about at all.
You do this by standardising the work, templatising it and turning it into a shared platform, or an internal library.
If you industrialise work this way, you open capacity up so teams can be redirected towards the things only they can do. The team's multiplier rises as a second-order effect of AI rather than a direct one.
The benefit of this second-order effect is that it compounds, rather than a one-off step change.
What this means for sizing
Decompose before you multiply when someone asks for the AI-augmented estimates.
Split the estimate into:
a. Commodity work
b. Genuinely novel work
Apply an aggressive multiplier to the first and approximately none to the second. The resulting blend is the honest number, and it will be different for every project.
Identify the real bottleneck.
If it's typing, AI helps enormously. If it's deciding, aligning, or discovering what the customer actually needs, AI helps at the margins, and pretending otherwise just relocates the failure to later.
Check the team, not just the tooling.
The multiplier is a property of the people. Engineers who know how to work with AI go fast; engineers who don't, go slower with it and produce worse code. And they have to be permitted to go fast! A 3x team dies in a three-week approval queue.
Account for the tax.
Most organisations are simultaneously broadening what they expect engineers to own: product breakdown, UX prototyping and QA. That's more ground per person, and it eats the observed multiplier. Some of the gain is spent before it ever reaches a delivery date.
Know the complicating factors.
What separates a 1.5x product from a 3x one is thin regression coverage, gnarly legacy surface area, unclear requirements and a high blast radius.
Be honest about the bill.
Funding for any product peaks early and declines. Accelerating today carries a maintenance commitment that requires comprehension and ownership of a largely AI-authored codebase. It also requires tolerance for its quality characteristics and the ongoing cost of inference.
The bigger question
If engineering is becoming less of a complexity bottleneck, how much is estimation still worth?
When mechanical work compresses toward zero and the remaining constraint is knowing what to build, arguing about effort is just arguing about the cheap part.
The scarce resource stops being delivery capacity and instead becomes a judgement about what is worth building at all.
It's probably still worth answering the "how much faster with AI?" question. But the better one to ask immediately afterwards is: now that the boring work is cheap, what harder problem are we finally free to go and solve properly?
