If AI proficiency is valuable, why not push everyone to the top?

Most AI adoption conversations I am part of eventually arrive at the same picture: ten people working alongside ten AI agents, everyone operating at the frontier, the whole organization fluent.

It is an appealing image. I am not sure it is the right target.

At Enouvo we describe AI proficiency in four levels:

The first two levels we treat as baselines. Everyone should reach the first. Every delivery role should reach the second. But the third we are targeting at roughly ten percent of engineers, and the fourth at a small cadre — one per business unit as a minimum. 

I should be clear that this is the ratio we are working toward, not a state we have already reached. We are publishing it because the reasoning behind the numbers seems more useful to other engineering leaders than the numbers themselves. 

Look at that shape, though. It is a pyramid, not a staircase everyone is expected to climb. And I think that is the part most adoption strategies get wrong. 

What actually changes when everyone has the tools? 

Less than people expect. 

Tool access is already close to universal. Any engineer who wants a capable model has one. If access were the constraint, we would have seen the productivity story resolve itself by now, and mostly we have not. 

What has not become universal is judgment. Knowing when an AI-generated answer is wrong in a way that matters. Knowing which parts of a workflow should be redesigned around a model rather than merely accelerated by one. Being the person who is accountable when the AI layer produces something plausible and incorrect. 

That is a different kind of capability, and it does not distribute the way tool literacy does. 

Why doesn’t advanced proficiency spread evenly? 

Three reasons, in my experience. 

The first is that the upper levels are a judgment function rather than a skill tier. Designing AI into a workflow, and owning the guardrails around it, draws on the same underlying capability as technical leadership — system-level thinking about tradeoffs, failure modes and when a design needs to change. Treating L3 as “L2 plus more training hours” misdiagnoses what the capability actually is. 

The second is that advanced proficiency decays without use. It requires sustained, high-frequency exposure to hold. If we spread the same training investment across an entire engineering population, we produce a large group that briefly touches advanced workflows and then returns to routine AI-assisted work, because routine AI-assisted work is what their role actually requires. The capability lapses. The budget is spent either way. 

The third reason is the one I think gets least attention. Uniform elevation removes accountability rather than adding it. If everyone is advanced, no one is distinctly responsible for the quality of the AI layer, and no one owns the guardrails when something goes wrong. The small L4 cadre is not a leftover of an incomplete rollout. It is the mechanism that makes broad adoption safe to run at scale. 

What does a delivery squad actually need? 

Take four engineers. 

That squad does not need four people independently designing AI workflows. It needs one person accountable for how AI is used across the squad’s work — what gets automated, what requires review, where the guardrails sit — and three engineers executing reliably inside that design. 

Push all four toward workflow design and the squad does not ship more. It ships roughly the same amount, with four people negotiating the design instead of one person making it. 

This has a practical implication for how we define roles. L3 and L4 should be a defined function within a squad, with explicit review and ownership responsibilities attached, not a proficiency badge available to whoever completes enough training. 

Isn’t a narrow top bad for our own people? 

There is a real counterargument here, and I do not want to move past it quickly. 

Concentrating advanced investment in ten percent of engineers narrows who has a visible path to a distinctive skill. That matters for retention and internal mobility. A flatter model — more people trained further, even at some cost to depth — can function as a retention lever independently of what it does for AI capability. If we ignore that, we solve a capability problem and create a people problem. 

My view is that the cost is real but smaller than it first appears, for two reasons. 

The upper cohort is meant to rotate rather than calcify. It is a role assignment tied to current workflow-design need, not a permanent tier, which means the path into it stays open. A fixed cadre with no rotation would be a genuine retention risk, and I would not defend that version of the model. 

The baseline is also not static. As the tools improve, L2 absorbs more of what used to require L3 judgment. Engineers get real capability growth without needing a formal designation to have it. 

I would still say to anyone adopting this shape: treat rotation as a deliberate mechanism, not an afterthought. It is the part most likely to be neglected, and the part that determines whether the model is sustainable. 

What this means for us at Enouvo 

This is not an abstract question for us. We have been building software for fifteen years and we are now running AI adoption across roughly a hundred and fifty engineers, which is enough scale that a wrong allocation of training budget is expensive. 

The conclusion we have reached is that measuring adoption maturity by average proficiency across the workforce tells us very little. A rising average with a thin expert layer does not indicate maturity. It indicates broad but ungoverned adoption, which is a harder problem to detect and a more expensive one to correct. 

The measures we find more useful are narrower. Does every business unit have a real L4 owner, or a nominal one? Is the L3 cohort sized to the workflow-design load it actually carries, or to a training completion target? Is there a defined mechanism by which L4 owners review and correct the output of everyone else, or are we relying on individual conscientiousness? 

We are still working this out. I do not think anyone has fully solved what an AI-native engineering organization looks like, and I would be suspicious of a company claiming otherwise this early. 

Where does this go in five years? 

The shape holds. The floor moves. 

I expect today’s L2 — AI as a routine part of one workflow — to become tomorrow’s baseline, because the tools get easier and the bar for safe unsupervised use drops. I expect today’s workflow-design work to become ordinary senior-engineer competence. The whole ladder shifts upward. 

But it does not flatten, because the scarce input is not tool access. Tool access is already commoditized and becoming more so. The scarce input is judgment, and accountability for the consequences of judgment, and I see no trajectory on which those become evenly distributed. 

So the strategic question for the next five years is not how much of the workforce we can raise to advanced proficiency. 

It is whether the right ten percent are doing the design work, and whether someone in every business unit is genuinely accountable for the AI layer. 

Get that ratio right and the baseline mostly takes care of itself. 

Get it wrong — flatten everyone to the same level and call it maturity — and you have spent a great deal of training budget building an organization where no one is clearly responsible for whether the AI is any good.