The one that should be pinned on the wall for every engineering leader rolling out AI is this: more adoptions fail due to explaining it rather than any technical problem ever will.
METR conducted a randomized controlled trial on experienced developers working on AI tools in 2025. The developers felt that they were about 24 % faster. When clocked, they were actually about 19% slower.
Both are true at once. The difference between how fast people feel and how fast they are, you know, that explains more of the adoption measures in AI than anything.
So what really happens when you throw in some AI
Naturally, you expect a straight line upward. A powerful tool given to skilled engineers leads to more output. That is not what happens, at least not in the beginning.
The first effect is disruption not acceleration, and this holds true when you bolt AI onto an existing workflow.
People stop to write prompts. They read the generated output and assess if it can be trusted. They correct it, then re-prompt. They flux between an authorial mind and a critical (reviewer) mindset. This entire overhead is so real and lands on the spot.
The gain is there as well, but comes much later; only after people have discovered what to delegate, and what never to turn over.
Buried between the upfront expense and postponed gain is a trough. The first thing that happens is productivity goes down, before it goes up. That is the J-curve.
Where most adoptions die
The dip is where most AI rollouts fail.
An expo team reaches the budgetary low point. The pace of everything and the frustration of it all seems slower than before. From their vantage point, certainly a reasonably place to be standing given the obvious challenges of progress in AI, they conclude that AI is indeed overhyped. They revert to the old method of functioning. They regress to first-generation autocomplete.
The eventual tools are peremptory set up and unused. The investment is written off. And the lesson learned by that organization is even the opposite: "we attempted AI, it did not work."
They were not incorrect regarding the slump. This was why - they shouldn't have tried to stop for it.
The strategy is to manage the dip
Its not a footnote to the strategy - it is the strategy, managing through that dip. There are few things that separate you, hoisting yourself out of this sinkhole, versus backsliding:
Protect experimentation time, explicitly. There is no slacker hours to climb the curve if every hour is booked against tickets, which means that this dip becomes a permanent feature on your landscape. It is a small fraction of reserved capacity that allows people to climb out of the trough at all.
Pair people through it. Your best teaching resource is the engineers that have already made it over the dip. Training on demand - human to human - wastes none of your time and easily eclipses a pre-recorded course.
Do not measure too early. The dip is when the team is the slowest - publish productivity numbers and they look bad. Those numbers go out to the people who see the chart, not the curve, and they come away with bad conclusions. Establish baselines now, but only report outcome statistics after the curve has turned.
The leadership test
Adoption is a tooling choice. AI adoption. It isn't. Regardless of what you choose, the tools are very much interchangeable and getting better every month.
By far the biggest difference between organizations that persevere and those that quit is leadership over the dip Those who did well knew the trough was coming, told their teams in advance that feeling slower was normal and temporary, held their nerve while the numbers looked bad, then protected the conditions for people to climb. That is leadership capability, not a technical one.
So if your team finds AI is making you slower in any way currently, before deciding the experiment has failed, ask a more useful question:
Is this a failure - or is it the bottom and our plan takes that into account?
No comments:
Post a Comment