I spent a chunk of last month getting good with one agentic coding tool. Properly good. I learned its quirks, built my habits around it, wired it into my workflow. Then a competitor shipped something better. Within weeks, the edge I'd built had thinned out to almost nothing.
Here's the trap nobody warns you about. In AI tooling, your advantage doesn't compound. It expires.

The 90-day cliff
Here's the pattern I keep seeing. A team picks the hot AI coding tool. They invest weeks learning it. They get a real lift in speed. Leadership writes it up as a win. Everyone relaxes.
Then the ground shifts. OpenAI ships an agentic coding tool to catch up with Claude Code, and WIRED runs a whole piece on the race (Inside OpenAI's Race to Catch Up to Claude Code). Anthropic answers weeks later. The tool you mastered is no longer the best tool. The specific tricks you learned are no longer the best tricks.
Your moat was never the tool. It was a sandcastle, and the tide comes in roughly every quarter.
I call it the 90-day cliff. You climb the learning curve, you reach the top, you plant your flag... and the edge crumbles under you because the whole mountain moved. If your competitive advantage is "we know Tool X inside out," you've built your house on a fault line.
The productivity number nobody mentions
Before you assume more AI automatically means more output, sit with this one.
In July 2025, the research nonprofit METR ran a randomized controlled trial on experienced open-source developers. Real engineers, working on their own large repositories... projects averaging over 22,000 stars and a million-plus lines of code. They completed 246 tasks, some with AI tools allowed, some without. The AI group mostly used Cursor Pro with Claude 3.5 and 3.7 Sonnet.
The developers predicted AI would make them 24% faster.
They came out 19% slower (METR's full write-up is here).
Read it again. Not 19% faster than they expected. 19% slower than working without the tool at all.
And here's the detail to keep you up at night. Even after finishing, having lived through the slowdown, they still believed AI had sped them up by 20%. The tool felt fast while making them slow. A 39-point gap between perception and reality, and most teams are making budget and hiring decisions based entirely on the perception.

Why faster tools don't make faster teams
So why does the shiny tool make people slower while feeling faster?
Because the tool is the easy part. You install the best agentic coder in the world this afternoon. So does your competitor. So does the team down the road who started this morning. The tool confers no lasting edge precisely because it's available to everyone at the same price on the same day.
The hard part is everything around the tool. Knowing which tasks to hand it and which to keep. Reviewing what it produces without rubber-stamping a plausible-looking mistake. Rebuilding your habits when the tool changes under you, then doing it again three months later. Keeping the team aligned when half of them live in the new workflow and half are still skeptical.
None of this ships in the install. All of it lives in your people.
The moat is how fast your team learns
Here's where I land, and it's not a comfortable place for anyone hoping to buy their way out.
The durable advantage in AI isn't which tool you pick. It's how fast your team picks up a new one, gets value from it, and drops it without drama when the next thing lands. It's not a procurement decision. It's a culture decision.
A team adapting in a week beats a team adapting in a quarter, every single time, regardless of which tools either of them chose. And a team adapts fast only when a few human things are already in place.
They need to feel safe saying "I tried the new tool and it made my work worse." If admitting it earns you a raised eyebrow from your boss, nobody admits it, and your whole team keeps using a tool quietly slowing them down... exactly like those METR developers who couldn't feel their own slowdown.
They need to share what they learn instead of hoarding it. The engineer who figures out the new workflow has to want to teach the other nine, not sit on the advantage.
They need leaders who reward results, not the appearance of being busy with the latest thing. Plenty of teams adopt tools for the press release, not the outcome.

What this looks like on Monday morning
Theory is cheap, so here's the practical version.
Measure the slowdown, not the vibe. The METR developers felt fast and were slow. Don't trust the feeling. Pick a handful of real tasks, time them with the tool and without, and look at the numbers before you roll anything out to the whole team.
Run a one-week trial, not a one-year contract. Treat every new tool as disposable from the start. Give a small group a week, a clear question, and permission to say it was rubbish. You learn more from one honest week than from a quarter of polite adoption.
Build a habit of sharing. After each trial, whoever ran it writes up what worked and what didn't, in plain language, where the rest of the team reads it. The point isn't the document. The point is making "here's what I learned" a normal thing to say out loud.
Reward the switch, not the loyalty. The person who drops a tool they spent two weeks mastering, because a better one arrived, did the right thing. Praise it publicly. Otherwise people cling to sunk costs and the cliff takes them down with it.
This is a people problem wearing a tech costume
I've spent years arguing the things making or breaking a team are human, not technical. Trust. Psychological safety. Honest feedback. The same stuff I bang on about over at StepUp2Bat. I used to think the AI wave might finally make the argument obsolete... the tooling itself becoming the differentiator.
It did the opposite. The faster the tools change, the more the human system underneath decides who wins. When the tool advantage lasts weeks, the adaptation advantage is the only one left standing.
The companies thriving over the next few years won't be the ones with the best AI tools. They cannot be... everyone has access to the same tools within days of release. They'll be the ones whose people absorb a new tool, judge it honestly, and move on, over and over, without it turning into a fight.
So stop asking "which AI tool should we standardise on?" It's the wrong question, and whatever you answer will be wrong in 90 days anyway.
Ask this instead. When the tool we picked gets beaten next quarter, how fast does my team switch, and do they trust each other enough to tell the truth about what's working?
Your answer there is your real moat. And no vendor will ever sell it to you.