Both Are True: What Copilot's Churn Really Means

GitHub Copilot crossed 4.7 million paid subscribers recently. The adoption numbers are stunning: 95% of developers report using AI tools weekly. Enterprise adoption is growing 75% year-over-year. And yet.

In conversations with engineering leaders, the same question keeps coming up: "Our team uses Copilot, but half of them want to turn it off."

This isn't a complaint about Copilot being bad. It's something stranger. It's the sound of a category proving its market viability while simultaneously proving it hasn't solved the actual problem. Adoption and churn coexist. Both are true. And understanding why might matter more than choosing sides.

Twenty-five years ago, the CASE tools market grew from $4.8 billion to $12.1 billion in five years. Every vendor promised 10x productivity gains. By 1993, the Department of Defense reviewed their CASE tool investments and concluded: "There is little evidence yet that CASE tools can improve software quality or productivity."

What happened? 73.5% of companies never adopted them. Of those that did, a third abandoned them within two years.

The category had proven real demand. But demand for something and demand for what was actually built are different things.

Today's AI coding tools are following a similar arc. The demand is genuinely there, teams want better productivity. But the tools solving "generate code faster" aren't solving "help teams understand and maintain the code they build."

GitClear's 2025 analysis found something telling: code churn has doubled since pre-AI days. 7.9% of newly written code is being revised within two weeks, up from 3.1% in 2020. Copy-pasted code blocks rose from 8.3% to 12.3%, while refactoring (the careful rethinking of existing code) dropped from 25% to less than 10%.

In other words, we're generating code faster and understanding it slower.

The instinct is to blame the tool. Build a better Copilot. Add more context. Improve the model. Train developers better.

Some of this helps. Teams with structured training and executive sponsorship see real wins, 85% confidence gains, 84% increases in successful builds. So why doesn't this scale?

Because the problem isn't actually a training or capability gap. It's architectural.

Here's what I keep seeing: Copilot is autocomplete packaged as intelligence.

That's not an insult. Autocomplete is genuinely useful. It's fast, it's convenient, it handles tedious repetition. But autocomplete solves the mechanical problem of typing. It doesn't solve the thinking problem of software architecture.

Software engineering happens at three levels:

File-level. Single functions, small blocks of logic. This is where Copilot excels. It can generate a sorting algorithm, a validation function, boilerplate code. Developers accept these suggestions about 40% of the time.

System-level. How files connect, how data flows, how components depend on each other, how failures cascade. This is where engineering actually happens. This is where Copilot falls apart.

Specification-level. What to build in the first place, the thinking problem that precedes code. CASE tools couldn't solve this. Neither can Copilot.

Developers know this instinctively. Only 33% of Copilot suggestions get accepted. The ones that don't? Mostly the ones where context matters. "I can see what this function does, but I don't know if it fits the rest of the system."

This is the trust problem hiding inside the adoption numbers.

A team of six product managers started using Prodini (our PRD copilot) alongside Copilot. Within weeks, they noticed: when Copilot helped them understand their codebase through structured discovery, they made faster architectural decisions. When Copilot just generated spec text, they spent more time editing than writing. The speed gain evaporated. But when context was managed centrally (not file-by-file), clarity multiplied.

An engineering team reported that PR review time increased after rolling out Copilot broadly. Why? Because every suggestion needed verification. A developer had to spend 10 minutes understanding "why did Copilot suggest this?" for every 2 minutes saved by not writing it. On Day 0, you gain speed. On Day 2, you lose it to debt.

When one technical leader dug into their git history, they found that 12% of code generated by Copilot was revised within two weeks. Hand-written code? 4%. The difference isn't quality, it's understanding. Code you write forces you to think through implications. Code you accept without thinking forces you to think later, under deadline pressure, in production.

This is why we built Prodini around context-aware architecture, not code generation speed.

At Prodini, we watched PMs and engineers use Copilot for PRD generation. Same pattern: real demand, real adoption, real churn. So we designed differently. Instead of "generate a complete PRD instantly," we built "help teams think through requirements systematically." It's slower on Day 0. It's dramatically faster on Day 2, because the thinking is already captured.

We're not anti-AI. We're pro-context. Every feature we build asks: "Will this help teams understand their product decisions, or just output them faster?"

Copilot proved something important: developers desperately want AI assistance. But what they want isn't faster code generation. It's clearer thinking.

The tools that win this category won't be the ones that generate the most code. They'll be the ones that make system-level thinking transparent. That solve the context problem, not the typing problem.

The next inflection point in AI for software engineering isn't about better models. It's about better architecture for how those models integrate with how software teams actually work, at the level of decisions, not keystrokes.