Six weeks.
The gap between Composer 1.5 and Composer 2 was six weeks. Six weeks for Cursor to throw out their February model, ship a new one in March, and reset the whole conversation about which AI coding tool is "best." Six weeks for any team standardised on the old one to be told, gently, they were already behind.
If you measure your AI advantage in tool choice, you're standing on a cliff eroding a little more every quarter.
The release cadence has gone feral
I've been writing software for over thirty years. I have lived through the move from C to Java, from monoliths to microservices, from on-prem to cloud. None of those shifts moved this fast.
Look at what shipped in the last six months alone. Cursor put Composer into production on October 29, 2025. They shipped Composer 1.5 on February 9. They shipped Composer 2 on March 19. Anthropic dropped Claude Opus 4.7 on April 16. OpenAI shipped GPT-5.2-Codex. Google shipped Antigravity. Cursor, Claude Code, and Codex started merging into a composable stack where teams use them together instead of picking one.
Every time you finish onboarding your team to a new tool, the next one is already in beta. The gap between "this is amazing" and "wait, this is slower than what we had" keeps shrinking.
Why tool choice stopped being a moat
Here's what tripped me up at first. In every previous tech wave, the right tool was the moat. If your competitor was on Oracle and you were on Postgres, the cost-of-switching alone bought you a lead. If your team was fluent in Kubernetes and theirs wasn't, you shipped faster for years.
The logic broke. Quietly.
Three reasons.
One. The tools share most of their substrate. Cursor lets you pick between OpenAI, Anthropic, Gemini, xAI, and its own Composer model from the same dropdown. If you don't like one, you swap. The router doesn't care.
Two. Switching cost is no longer measured in weeks of retraining. It's measured in hours. A senior engineer already fluent in Claude Code becomes productive in Cursor by lunch. The tooling is convergent on purpose. Vendors know they're competing for fluid users, not captives.
Three. Roughly 70% of developers now use two to four AI tools at once. They route by task. They pay for the best plan in three apps and rotate based on context limits, cost, and which model behaves better today. Your "tool choice" isn't a choice anymore. It's a portfolio you rebalance weekly.
So if you bet your edge on the tool, you didn't build a moat. You bought a season ticket.
The productivity lie
Here's the part to make you nervous.
METR ran a randomised controlled trial with 16 experienced open-source developers on 246 real issues. The developers predicted AI tools would make them 24% faster. They were in fact 19% slower. And even after the slowdown happened to them, with timing data in front of them, they still believed AI had sped them up by 20%.
Read it again. They felt faster. They were slower. They had no idea.
I have seen this in my own work. I will spend two hours pair-programming with Claude on something I would have written in forty minutes alone, and walk away feeling productive because I typed less. The dopamine hit of watching code appear on the screen is not the same as the dot on a delivery chart. The two have decoupled.
Sonar's State of Code report says 96% of developers don't fully trust AI-generated code, and only 48% always check it before committing. Which means roughly half of all AI-generated code is going into repos unverified, by people who don't trust it, who feel faster while being slower.
Not a moat. Debt with extra steps.
So what is the actual moat?
It is not the tool. It is the rate at which your team absorbs a new tool, finds its real edges, and changes their habits.
I'll say it again because I think it matters.
The moat is your team's learning velocity.
If Cursor ships Composer 3 in July, the question is not whether your team will adopt it. The question is how many days pass between "released" and "the average engineer on our team has changed how they prompt." If the gap is three weeks for you and one day for your competitor, they will out-ship you on every problem where the new model is meaningfully better. By the time you catch up, model four is out.
Learning velocity comes from three places, and none of them are in the IDE.
One: psychological safety
If an engineer fears saying "I tried Composer 2 on the auth refactor and it kept hallucinating our middleware names" without being told they prompted it wrong, you will never hear what is broken. You will hear marketing copy from your own team. The data you need to make tool decisions will be filtered through fear.
I wrote about this on Step It Up HR for a different reason, but the dynamic is identical. Bad bosses kill information flow. In an environment where models change monthly, the cost of bad information flow is now measured in lost ships, not only lost morale.
Two: feedback loops firing weekly, not yearly
The annual review fails to keep up with the AI wave. Neither does the quarterly retro. If your team is meaningfully changing tools four times a year, you need a feedback loop running at the same pace. Otherwise you are reviewing March's habits in October, by which point March's tools are extinct.
I built Step Up 2 BAT around the idea a healthy team needs short, frequent, honest feedback. It used to be a nice-to-have. With AI tooling churning this fast, it is operational infrastructure.
Three: a written record of what worked and what didn't
Most teams have no shared memory of why they made a tool decision six months ago. They re-evaluate from scratch every cycle. The teams pulling ahead keep a running log. "We tried X for refactors. It worked on Y. It failed on Z. We dropped it on date W because of regression in the Q tests." Boring. Devastatingly effective.
When the next tool ships, you don't argue from opinion. You argue from your own data.
What I tell founders
If you're a founder watching engineers debate Cursor versus Claude Code versus Codex like it's a religious war, you are watching the wrong fight. The tool will be different in ninety days. So pick one which works, ship, and put your real energy into the meta-skill: how fast does this team adapt?
Three practical moves.
- Cap the tool debate at one week per quarter. Anything beyond it is procrastination dressed as strategy.
- Run a monthly "what did we learn about our tools" thirty-minute meeting. Not a retro. A learning meeting. What broke. What surprised us. What we want to try next.
- Stop measuring engineer productivity in lines of code or PRs merged. A 2019 metric. Measure adaptation. How long from "new tool exists" to "average engineer uses it well." Your moat lives in the number.
The honest closing
The barrier to writing code has collapsed. The cost of switching tools has collapsed. The lifespan of any given AI advantage has collapsed. None of these are the interesting story.
The interesting story: the only thing left to last is how your people work together. Trust. Feedback. Shared learning. The boring, human stuff some of us have been talking about for years and nobody wanted to fund because it wasn't a product.
It is now the product. It is the only thing the AI wave has not commoditised, and as far as I see, the only thing it cannot.
So what's your team's learning velocity? If you don't know, make it your first project this quarter.