
ISSUE 006
AI helps juniors most. Juniors are the ones not getting hired.
Two entries ago this pillar carried a finding that young workers in AI-exposed jobs are falling behind on employment. This one carries a finding from a completely different research group that AI helps the least experienced workers most. Both look solid. Put together they describe a situation I haven't seen anyone name directly.
An idea worth thinking about
The gains go to the people who know least
The pattern repeats across studies in different kinds of work. In the developer experiments, less experienced developers had both higher adoption rates and greater productivity gains. In customer support, a study documented around a 14 percent increase in issues resolved per hour, with larger impacts for lower-skilled than for highly skilled workers. A review of this literature reads the pattern as AI reducing frictions for early-career workers, which undermines the claim that these tools mainly amplify top performers.
That's a levelling effect, and it makes intuitive sense. Much of what separates a five-year employee from a five-month employee is accumulated reference knowledge — how this is usually done, what the standard phrasing is, where the gotcha lives. A tool that supplies exactly that closes part of the gap.
For a small business this is a genuinely useful reframe. The common instinct is to give AI tools to your most senior person because they'll use them best. The evidence points the other way: the return is largest on the newest person, because they had the furthest to come.
A tool I disappeared into
An annotated bibliography of nearly every AI productivity study
Somebody did the tedious job of assembling the empirical literature on AI and productivity into a single review with an annotated bibliography, and it is free. Each entry says what the study did, how big it was, and what it found, which means you can find out whether a claim you've been handed rests on a randomised trial with thousands of participants or on a lab task with forty undergraduates.
The reason this is a tool rather than a reading is that it lets you triangulate. The productivity findings in this field range enormously — roughly 14 percent in customer support, 26 percent in the developer experiments, upwards of 50 percent in an earlier developer study. Those aren't contradictions so much as different tasks, different tools, different measures of output. Having them in one place with their methods attached is what makes the range interpretable instead of alarming.
It's published by a policy centre, so read the framing with the same eye you'd bring to any advocacy-adjacent organisation. The bibliography itself is just citations and descriptions, and the underlying papers are linked.
Learn something
What makes these studies different from every vendor case study
The developer research is a randomised controlled trial, and the design is worth understanding because it's the thing missing from every AI case study you'll be sent. A random subset of developers was given access to the tool and the rest weren't. Because assignment was random, the two groups are on average alike in everything else — skill, motivation, the projects they happened to be on — so a difference in output can be attributed to the tool.
Compare that to the standard claim, which is that a company adopted a tool and output rose. Companies that adopt new tools early differ from companies that don't, in ways that also affect output. The same is true of individual employees who volunteer. Without randomisation you cannot separate the tool from the kind of person or firm that reaches for it.
These particular experiments were run by the firms themselves in the ordinary course of business — Microsoft, Accenture and an unnamed Fortune 100 company — with one of the tools being a Microsoft product. That's a real consideration and I'd rather state it than not. It's mitigated by the study being peer-reviewed in Management Science and by the authors publishing results noisy enough to be inconvenient, which is not what a marketing exercise produces.
What we’re seeing
26 percent more tasks completed, give or take twenty points
Cui and colleagues combined three randomised controlled trials covering 4,867 software developers and found a 26.08 percent increase in completed tasks among those given access to an AI coding assistant. That is a large effect on a large sample, published in Management Science.
Now the number next to it, which almost never travels with the headline: the standard error is 10.3 percent. Roughly, that puts the plausible range somewhere around 6 percent to 46 percent. The authors say plainly that each experiment is noisy and results vary across the three. A 26 percent point estimate with that much spread tells you the direction is real and the magnitude is genuinely unsettled.
It also describes software developers at very large firms using a code completion tool. Carrying it over to a bookkeeper in Perryville using a chatbot is a leap, and I'd rather flag that than let the number do work it can't support.
Here is what I actually want you to sit with, though, and it comes from putting this next to an earlier entry in this pillar. This research says the productivity gains concentrate among the least experienced workers. The Stanford payroll research says employment for 22-to-25-year-olds in AI-exposed occupations is running 19 percent behind their less-exposed peers, through reduced hiring rather than layoffs.
Both findings are credible and they come from different research groups using different data. Together they describe a situation where the tool that most helps a junior employee do the job is also implicated in the junior job not being posted. I don't have a resolution for that and I'm suspicious of anyone who offers one quickly. But for a small employer it does suggest something concrete: if the gains really are largest on your newest person, then hiring one and equipping them well is a strategy that the larger firms in your labour market are currently declining to run.
One question
Who in your business uses AI the most?
Your most experienced person or your newest? Reply with which — the research says it should be the newest and I suspect it usually isn't.
More in this pillar as it's written.
— Shana
Sources link to the original publisher, never to a summary.
