90% productivity gains. That number keeps showing up in conversations about AI coding tools, and after spending real time with them on actual codebases, the percentage isn't as absurd as it sounds - for certain types of work.
The catch is in that qualifier. The productivity story splits cleanly into two buckets, and most of the debate around AI replacing developers ignores this split entirely.
Where the Gains Are Real
Boilerplate code, library integrations, build tooling, refactoring across large files - this is where AI coding assistants genuinely compress hours into minutes. The pattern is consistent: any task where the "right answer" is well-established and the work is mostly mechanical translation, AI handles it fast and accurately.
Tools like Claude Code, Cursor, and GitHub Copilot have gotten remarkably good at this category. You describe what you want, review the diff, and move on. The stuff that used to eat entire afternoons - writing test scaffolding, migrating API versions, reformatting data structures - now takes a fraction of the time.
Anyone who has tried pointing these tools at an old repository and asking for a modernization pass knows the feeling. It is genuinely impressive for the tedious work that developers have always hated doing.
Where the 90% Claim Falls Apart
Complex legacy enterprise systems with years of accumulated business logic, undocumented edge cases, and architectural debt? AI coding tools still struggle here. They can suggest plausible-looking code that misses critical context. They confidently refactor functions without understanding why a particular workaround exists.
The developer's job was never just typing code. It was understanding systems, making tradeoffs, and knowing which corners you absolutely cannot cut. AI has eaten the typing part. It hasn't eaten the understanding part.
This means the actual productivity gain for a senior developer working on complex systems is probably closer to 20-40%, not 90%. Still significant. But not "replace half the team" significant.
The Strategic Fork
Companies looking at these gains face a real decision, and their answer reveals a lot about how they think.
Option A: Cut headcount. Take the productivity gain as cost savings. A team of 10 becomes a team of 5 producing the same output. This is the MBA spreadsheet answer, and some companies will absolutely do it.
Option B: Ship more. Keep the team, use the freed-up time to build features that were perpetually stuck in the backlog. Fix the technical debt nobody ever had time for. Actually write documentation. Build the things customers have been requesting for years.
Option A looks smart in the next quarterly earnings call. Option B compounds over time. The companies that treat AI productivity as a capacity multiplier rather than a headcount reducer will end up with better products, faster iteration cycles, and engineers who actually want to work there.
There is also a practical reality that the "fire half the team" crowd ignores: someone still needs to review AI-generated code, maintain the systems, and handle the 60% of work where AI assistance is marginal. Cutting too deep creates a team that can generate code fast but cannot evaluate whether that code should exist.
The developers who should worry are the ones whose entire job was already the mechanical part. The ones who thrive on system design, debugging production incidents, and understanding customer problems have a different future - one where they spend less time on the boring parts and more time on the work that actually requires human judgment.