Why Haven't We Improved with AI After Two Years?

We've had language models capable of writing, analyzing, debugging code, and synthesizing documents at a speed that any professional from 2020 would have deemed impossible for at least two years now. And yet, the question posed by the Financial Times in this article remains without a satisfying answer: why aren't we collectively better at what we do?

It's not an empty rhetorical question. It's the kind of uncomfortable one that deserves some genuine attention, especially for those of us working near the Claude ecosystem or any other generative AI system.

The Gap Between Access and Competence

The pattern is familiar: organizations buy licenses, individuals create accounts, someone delivers an impressive demo in a meeting, and then... usage stabilizes around low-value tasks. Drafting email templates, generating summaries no one reads in full, getting explanations of concepts never actually applied.

This isn't a model problem. Claude Opus 4.7 with a million token context window can ingest entire contracts, complete codebases, or months of conversation history. Sonnet 4.6 and Haiku 4.5 offer enough speed and cost to integrate into real workflows. Technical capability isn't the bottleneck.

The problem seems to be elsewhere: most people haven't developed the mental habit of systematically delegating cognitive work. We use AI as a faster search engine, not as a collaborator worth investing time in instructing properly.

The Hidden Cost of the Learning Curve

Learning to use an AI tool well requires initial effort that's often underestimated. It's not just about knowing how to write prompts, but understanding which tasks merit delegation, how to structure context, when to verify output, and when to trust it.

In professional environments, that experimentation time is rarely budgeted. Teams reach Friday without having tried anything new, and managers measure productivity in direct outputs, not in tool-learning investment. The result is that deep adoption remains reserved for those with personal curiosity and their own time to experiment, which isn't everyone.

This creates a growing divergence: a minority of professionals are becoming significantly more productive, while most remain where they were eighteen months ago.

The Problem of Measuring What Improves

Another complicating factor is the difficulty of measuring cognitive productivity gains. If a designer finishes iterations twice as fast because she uses Claude to generate variations quickly, that saved time rarely appears in any business metric. It gets absorbed into other tasks, meetings, emails. The improvement exists, but it's invisible on dashboards.

Organizations actually seeing measurable results are those that made structural decisions: integrating tools like Claude Code into development workflows with hooks and subagents specific to their processes, building MCP servers connected to their internal data sources, or defining reusable skills that standardize how the team interacts with the model. It's not magic, it's process engineering applied to new tools.

Who Has Most to Gain from This Reflection

The FT article targets a general audience, but the question resonates especially with three profiles. First, those responsible for technology adoption in mid-sized companies who need to justify investments without clear metrics. Second, individual developers who've had access to powerful tools for months but haven't substantially changed how they work. Third, internal training teams who've organized prompting workshops without connecting them to actual business use cases.

For all of them, the FT's question is a good starting point for an honest conversation that's still not happening in many workplaces.

---

Here at ClaudeWave, we believe the narrative of "untapped potential" has served too long as an excuse for not doing the hard work of integrating these tools into real processes. The technology exists. The next step isn't waiting for the next model: it's taking seriously the learning part nobody wants to do.