I manage QA across dev teams in 24 countries. So I hear a lot of the same complaint: "We gave everyone Copilot and nothing got faster."
A few months back I asked one of our developers, Yuri, a direct question. He had Copilot. He'd been using it for weeks. But his commit cadence hadn't changed. Same rhythm as before. I wanted to know why.
His answer reframed how I think about developer productivity.
The conversation that changed my mind
Yuri didn't hesitate. "I use Copilot constantly. But I still spend most of my time reading the codebase before I touch anything."
He wasn't being slow. He was doing what good engineers do: understanding the system before changing it. Copilot handled the typing. But the typing was never the bottleneck.
What actually ate his time:
- Reading through the module to understand how authentication state flowed between components
- Tracing a bug to figure out whether the fix would break something two levels down
- Writing the prompt carefully so Copilot would generate code that matched the existing patterns, not just technically correct code
"It's prompt engineering at that point," he told me. "I'm not asking it to write code. I'm asking it to write this specific change in this specific context."
That distinction matters more than most people realize.
What Copilot actually speeds up (and what it doesn't)
Copilot is genuinely good at a few things. Boilerplate. Repetitive patterns. Switching between languages when you know what you want but can't remember the syntax. It shaves minutes off tasks that used to take an hour.
But here's what it can't do. It can't read a PR from last week and understand why someone structured a module that way. It can't know that your payment service has a race condition when two requests hit within 50ms. It can't tell you that the "quick fix" you're about to apply will break the integration tests that run on a different branch.
Context is the bottleneck. It always was. Copilot just made it more obvious.
Before AI tools, slow commits looked like a developer problem. Now that the code-writing part is handled, the real time sinks are exposed: code review cycles, unclear requirements, context-switching between tickets, and the absence of anyone checking whether the change actually works end-to-end.
The code review trap
We see this constantly from the QA side. A developer pushes a PR in 20 minutes thanks to Copilot. Then it sits in review for three days. Or it gets approved without real scrutiny because the reviewer is juggling four other PRs and two standups.
Copilot made the writing faster. Nobody made the reading faster.
And the downstream effects are real. When reviews are rubber-stamped, bugs reach QA that should have been caught in the PR. When QA catches them, the developer has already moved on to a different ticket and has to reload all the context for the original one. That reload costs more than the original fix.
I've tracked this pattern across dozens of teams we work with. The ones who actually got faster after adopting Copilot weren't the ones with the best prompts. They were the ones who fixed their review process first.
Speed without validation is just faster failure
There's a version of this story that ends with "so just trust your developers and stop measuring velocity." That's not where I land.
What I've seen is that Copilot, and tools like it, amplify whatever process you already have. If your process includes structured QA, test coverage, and clear handoffs between dev and testing, then Copilot accelerates delivery. Genuinely.
If your process is "write code, push to main, hope for the best," then Copilot just helps you ship bugs faster.
One team we work with in Germany had a perfect example. Their sprint velocity went up 30% after adopting Copilot. Their defect rate also went up 30%. Same ratio. They were producing more, but the quality hadn't changed at all. The only thing that moved was volume.
They brought us in to add independent QA to their pipeline. Within two sprints, the defect rate dropped back down while velocity stayed high. The fix wasn't removing Copilot. The fix was adding a checkpoint that Copilot couldn't replace.
What actually makes teams faster
After watching this play out across enough teams, I have a short list of what actually correlates with faster delivery. None of these are about AI.
Smaller PRs. Code that takes 15 minutes to review gets reviewed the same day. Code that takes an hour gets reviewed "when I have time," which means Thursday.
Clear ticket scope. When a developer knows exactly what to build, they don't spend 40 minutes reading Slack threads and Confluence pages to figure out what the ticket actually means. Copilot can't fix ambiguous requirements.
Dedicated QA handoff. Not "QA will look at it eventually." A specific person, a specific checklist, a specific time. When developers know their code will be tested thoroughly, they write it differently. They think about edge cases because someone is going to check.
Fewer context switches. Every time a developer moves between tickets, they lose 15-20 minutes of loaded context. Three switches a day and you've lost an hour of productive work. Copilot doesn't help with that. Protecting focus time does.
The real question to ask your team
Next time a developer seems slow despite having AI tools, don't ask "why aren't you faster?" Ask instead: "What are you spending your time on that isn't writing code?"
The answer will almost always point to process problems, not tooling problems. Waiting for reviews. Clarifying requirements. Re-reading code they haven't touched in two weeks. Debugging something that should have been caught by tests that don't exist.
Copilot solved the easy part. The hard part, the part that actually determines how fast your team ships quality software, is everything around the code.
Yuri knew that intuitively. It took me a few more conversations to see it clearly. But once you see it, you can't unsee it: the bottleneck was never the typing speed.
We write about developer productivity and QA from the perspective of a team that works across hundreds of projects. More at betterqa.co/blog.
Top comments (0)