Your Developers Aren’t Slow With AI. They’re Still Learning It.

Companies Are Deploying AI Faster Than They Are Learning to Use It

You can give every developer an AI coding agent tomorrow, but that does not mean your organization knows how to use it.

Too many companies still treat AI adoption as a tooling problem. Buy the licenses. Give developers access. Track adoption and usage. Then wait for productivity to improve. However, access to a capability and the ability to use that capability are not the same thing. Using AI effectively must be learned.

This matters because software development is knowledge work. A developer completes a task by closing the gap between what they already know and what they need to know to finish it i.e. the Knowledge to Be Discovered. Introduce an unfamiliar AI coding agent and, at least initially, you can make that gap larger. The developer must still discover what needs to change in the software, but now must also discover how to instruct the agent, what context it needs, when to trust it, how to constrain it, and how to recognize when it is confidently heading in the wrong direction.

That additional knowledge does not appear automatically because someone has used ChatGPT before. Working effectively with an agent inside a real codebase is its own skill. Like any skill, it develops through practice: people learn which tasks to delegate, how to structure context, how to decompose work, how to verify output, and when direct intervention is faster. The first months of using an agent is therefore not a fair representation of what an experienced human–agent system can eventually do.

Developer proficiency is only the first learning curve. An experienced engineer carries years of implicit knowledge about the system: architecture, conventions, business rules, previous decisions, dangerous areas, and the countless small reasons why the software looks the way it does. An AI agent does not automatically share that knowledge. If it cannot discover what the organization already knows, it must guess or rediscover it. Your own organizational knowledge is valuable only when it is accessible and relevant to the people and agents that need it.

This is why effective AI adoption requires learning at three levels. Developers must learn how to work with agents. Organizations must learn how to make their knowledge accessible to agents. Software systems must evolve so future humans and agents can understand and modify them without repeatedly reconstructing the same context. Specifications, architecture decisions, tests, business rules, engineering standards, and developer guides increasingly become part of the engineering system itself: they tell an agent what should happen, why it matters, how the system should change, and what must not break.

The mistake is to call this whole process “AI adoption.” Adoption is the easy part.

You adopt AI when you buy the tools. You build AI capability when your organization learns how to use them.

Measuring the Learning Curve as Productivity Can Kill the Investment

If you measure AI before your organization has learned how to use it, you risk measuring the cost of learning and calling it the value of AI.

The early stages of AI adoption impose a real cost. Developers are doing their normal knowledge work while simultaneously learning a new way of doing that work. They are discovering which tasks agents handle well, what context produces useful results, how much autonomy to allow, how to verify output, and where human judgment must take over. Until that knowledge accumulates, AI can make work slower rather than faster.

That is what makes early productivity measurements dangerous. A developer who is slower during the first weeks of using an unfamiliar coding agent may tell you very little about the productivity of that same developer after months of deliberate practice. Studies of AI-assisted development illustrate precisely this difficulty: participants can be experienced software developers while still being inexperienced with the particular AI tools and workflows being evaluated. The experiment may accurately measure what happened during the study while still leaving a much bigger management question unanswered: what happens after people learn?

Organizations can make the same mistake at scale. Give developers AI tools, expect immediate acceleration, observe mixed results, and leadership may conclude that the investment is failing. The AI transformation budget gets reduced just when people are beginning to acquire the knowledge required to make the technology useful. What looked like disciplined ROI management has actually terminated the experiment during its learning phase.

The opposite mistake is just as dangerous. Prompt counts, generated lines of code, acceptance rates, license utilization, and other activity measures can make an AI transformation look successful simply because people are using the tools. More AI activity does not necessarily mean better software, faster delivery, less rework, or greater engineering efficiency. Measuring individual developers also creates incentives to optimize visible AI usage rather than improve the system around them.

The better principle is simple: measure the system, not the developer. Adoption matters, but it should sit alongside delivery, quality, and efficiency measures. Over time, the deeper test is whether the organization is creating an environment in which humans and agents can discover, preserve, and apply the knowledge required to deliver good software with less waste and less rediscovery.

AI therefore creates an unusual investment problem. Measure too early and you can mistake learning costs for permanent inefficiency. Measure the wrong things and you can mistake activity for progress.

Do not mistake the cost of becoming good at AI for evidence that AI is bad at the job.

Build the Capability to Learn AI

You should treat AI adoption as an organizational learning investment, not a software rollout.

The simplest approach is to give developers access to AI coding agents and let them learn independently. That will produce some exceptional users, particularly among people already motivated to experiment. The result is that every developer then pays much of the same learning cost independently, successful practices spread by accident, and capability varies widely between teams. You have provided the technology without building the organizational capability to use it.

A better approach is deliberate learning. Give people protected time to use AI on real engineering work. Provide hands-on training, coaching, shared patterns, and learning pods where teams can experiment, compare approaches, and turn successful discoveries into reusable practices. The objective is not to teach everyone a collection of prompts; it is to shorten the learning curve by ensuring that what one person discovers can become knowledge available to everyone else.

But even that is not enough. Developers can become excellent AI users and still spend enormous effort repeatedly explaining their organization to an agent. The agent needs to know what the product should do, how the system is designed, which constraints matter, what decisions have already been made, what good engineering looks like here, and what must not change. If that knowledge exists only in people's heads, scattered documents, old conversations, or conventions that “everyone knows,” every new agent starts with a knowledge deficit.

The strongest approach is therefore to improve the knowledge environment at the same time as you improve people's AI skills. Product specifications make intent explicit. Tests encode expected behavior. Architecture decisions preserve why important choices were made. Business rules, engineering standards, decision schemas, paved paths, and agent instructions turn implicit expectations into knowledge that humans and agents can find and apply. Where possible, deterministic tools and quality gates should enforce constraints rather than relying on either a human or an AI to remember them.

This changes what “making the codebase accessible to AI” means. It is not a documentation project designed to help a machine read more text. It is the continuous work of making important knowledge explicit, structured, accessible, reusable, and, where possible, executable. The payoff extends beyond AI: the next developer joining the team also has less to rediscover.

These three investments reinforce one another. Developers learn how to work with agents. Teams turn individual discoveries into shared practices. The organization redesigns its engineering environment so humans and agents begin future work with more prior knowledge and less Knowledge to Be Discovered. As models and tools change, the specific practices will change too. The learning system remains.

Do not just teach developers today's AI tools. Build an organization that keeps getting better at learning how to use AI.

The Competitive Advantage Is Learning Faster Than AI Changes

The lasting AI advantage will not come from adopting each new model first; it will come from learning how to turn new AI capabilities into better engineering faster than your competitors.

Do nothing beyond providing the tools and the first consequence is wasted investment. Developers individually discover how to use AI, repeat one another's mistakes, and develop wildly different levels of proficiency. Some become highly effective. Others conclude that AI creates more work than it removes. You pay for the same technology across the organization but get very different returns from it.

The second consequence is more dangerous: you can learn the wrong lesson. Early productivity struggles become evidence that AI “doesn't work,” while high prompt counts or generated-code volumes become evidence that it does. Leadership oscillates between disappointment and enthusiasm because it is measuring snapshots of an immature capability rather than whether the engineering system is becoming better at using AI. The organization can abandon valuable approaches too early while scaling ineffective ones because they produce more visible activity.

Over time, this becomes a knowledge problem. A few developers accumulate sophisticated ways of working with agents, but much of what they discover remains with them. Agents repeatedly reconstruct architecture, product intent, conventions, and constraints because the organization has not made that knowledge accessible. Teams keep paying to rediscover what somebody elsewhere has already learned. The Information Loss Rate shows up operationally as rework: knowledge is acquired, lost, and then acquired again.

Act now and the dynamic reverses. Developers still have to learn, but their discoveries become shared practices. Those practices influence training, specifications, tests, architecture, standards, paved paths, agent instructions, and the tools surrounding delivery. Each improvement gives the next human or agent more useful prior knowledge, reducing the Knowledge to Be Discovered before productive work can begin. The organization does not eliminate learning; it becomes better at accumulating the results of learning.

That distinction compounds because AI itself will not stand still. Today's preferred model, coding agent, prompting technique, or workflow will be replaced. If your AI capability consists mainly of knowing how to operate today's tools, every major technology change pushes you back toward the beginning of another learning curve. If you have built an organizational learning system, new capabilities become inputs to a process you already know how to run: experiment, learn, evaluate, preserve what works, redesign the environment, and repeat.

Your competitors may have access to exactly the same models. What they may not have is the same capacity to learn from them.

The durable AI advantage is not knowing how to use today's AI. It is becoming an organization that learns how to use tomorrow's AI faster than everyone else.

Next Step

Stop asking whether your developers are using AI enough. Decide how you will build an organization that learns how to use AI better with every project, every team, and every generation of the technology and start by giving your people the time, training, and knowledge environment required to learn.