You bought the AI tools. Why aren't you faster?

I’ve had some version of the same conversation a dozen times in the past year.

A technical leader tells me their team has AI tools like Copilot, Claude, or Cursor. The team has access. Some people are using them. And yet, when they look at what’s shipping, they’re not seeing the speed-up they anticipated.

“We bought the tools,” they say. “Why isn’t anything different?”

It’s a fair question, and the answer is almost always the same.

You didn’t change the process

When I ask, “Has the way your team works changed?” most people pause. Then they say something like, “I don’t know.”

They equipped their team and assumed the output would follow. That’s reasonable if you think about AI tools the way you think about a faster computer: add hardware, get more throughput. Software teams don’t work that way. They’re more like a factory floor.

In a factory, you’re always limited by your slowest work center. You can make one station dramatically faster, but if the rest of the line can’t keep up, you haven’t improved overall output. You’ve moved the bottleneck.

AI tools do the same thing to software teams. They speed up implementation, often dramatically. But your process was designed around implementation being the bottleneck. When implementation gets fast, the bottleneck moves upstream to definition. From there, one of two things happens. Sometimes the build blocks, waiting on decisions, just like a starved station on a factory line. More often it charges ahead and produces work that was never fully defined. That work piles up in front of review as WIP nobody can trust or absorb. Either way, the way the team works has to change, too.

Most teams don’t notice this problem. They see a few individuals getting faster, call it a win, and move on. They’re not wrong that something sped up. They just haven’t looked for the new constraint.

The two patterns I keep seeing

That fork describes what happens to the line. The patterns below are about the people. So what does a team look like when the bottleneck has moved and nobody’s noticed? Two patterns show up again and again.

The first is what I call the “Rogue Star.” One or two developers master the tools and produce extraordinary work, independently. Their output is impressive. It’s also nearly impossible for the rest of the team to integrate. They’ve run away from the development system.

The second is the “Half-hearted Adopter.” The bulk of the development team bell curve lives here. These team members are using AI tools because they were told to. They see marginal gains. They haven’t changed how they work. Using AI and changing your process are not the same thing.

What neither pattern includes is a change to how the team works. That’s why both end in the same place: real effort, lackluster results.

The output multiplied. The definition work didn’t.

When AI tools matured, one developer could suddenly produce what three or four developers produced before. I’ve seen this firsthand on our own teams. In this respect, the hype is earned.

But that output runs on a steady supply of requirements, clarity, direction, and decisions. What we call definition work. Definition kept up before because implementation was slow. It doesn’t keep up now.

The fix is a shift in where people spend their time, not a new org chart. Said as simply as possible, someone on your team needs to dedicate more of their time to definition. That’s it.

Why process change has to come first

I push teams toward process change before anything else because process is a forcing function. Change the process and adoption becomes unavoidable. Keep the old process and you’re asking people to voluntarily change how they work — which most people won’t do, at least not consistently.

The data bears this out. McKinsey found that high-performing teams using AI with structured process saw 16–30% productivity gains and 31–45% quality improvements. Faros AI tracked DORA metrics across 1,255 teams using AI tools without process change and found no measurable improvement in delivery.

Same tools. Different outcomes. Process is the variable.

There’s something else in that data worth paying attention to: teams with strong process see quality go up alongside speed. Teams without it see quality go down. If you’re shipping faster but breaking more things, you’re not ahead.

How to know if it’s working

Don’t wait for velocity data. There’s an earlier signal: collaboration.

Are your developers working more closely together? Are the strongest people on your team pulling others along, or running ahead of them? If the team says they’re using the new process but you’re seeing more of the same, they probably aren’t.

Collaboration is the process change made visible.

2026 is not the year to keep watching

I was on a panel recently where someone described 2026 as “the year of experimentation.” I held back, but I disagreed.

2024 was for exploration. 2025 was ramp-up. Teams with real adoption are pulling ahead now in ways that compound over time. Waiting for the dust to settle is a choice. It just may not feel like one.

If you’ve given your team the tools and you’re not seeing results, ask whether the way your team works has actually changed. If the answer is “I don’t know,” start there.

The tools are the easy part. The process is the work.

‍