Blog
Insights on email-native learning, productivity, and skill development
AI Made Us Busier. It Was Supposed to Make Us Faster.

Somewhere in your company right now, a team is producing more output than it ever has. Documents drafted in minutes. Code appearing faster than anyone can review it. Reports, summaries, prototypes, decks — a volume of work that would have been unthinkable two years ago, arriving on time, every time, in quantities that look fantastic on a dashboard.
The AI rollout was a success. Everyone agreed. There was a launch email, a training webinar nobody quite remembers, and a licence count that keeps creeping upward. By every measure the tools are being used. By every measure the team is busy.
And underneath all of it, a quieter question nobody wants to ask out loud: is any of this actually shipping faster?
A major consultancy's latest technology report just answered that question in a way the AI keynote circuit won't enjoy. After tracking how companies have absorbed the new generation of AI tools, it found that in nearly a third of them — about 30% — productivity didn't rise after adoption. It fell.
The Busy-Productive Illusion
The headline finding is uncomfortable enough. The detail underneath it is worse — and more familiar than most managers will admit. In one study cited in the report, AI tools increased coding activity by 180%. Output nearly tripled. But shipped releases — the thing a software team is actually for — rose by only 30%.
Read that gap again, because it's the entire story of AI at work right now in miniature. The activity went vertical. The outcome barely moved. More was produced; not much more was delivered. The difference between those two words is where a third of companies are currently bleeding time.
It isn't confined to engineering. The same pattern shows up anywhere a fast tool was dropped into a slow process. Marketing teams generating forty draft variants and reviewing none of them properly. Analysts producing longer reports that answer fewer questions. Everyone surrounded by more text, more code, more options — and spending the recovered hours wading through the surplus. The machine makes volume for free. Somebody still has to be paid to find the value in it.
This is the part that doesn't show up in any vendor demo: AI doesn't remove the checking, it multiplies the checking. Every unit of generated work arrives with a hidden tax — someone has to read it, verify it, correct the confident errors, and take responsibility for it going out the door. When that tax isn't planned for, it doesn't disappear. It just lands on whoever is conscientious enough to carry it, invisible and unbudgeted, until they're doing their old job plus a second job reviewing a machine's output — and wondering why "the productivity tool" made them slower. We've covered the worker's side of that trap elsewhere; the McKinsey numbers are what it looks like from the company's side.
Same Tools, Divergent Results
Here's the fact that should kill the easy conclusion — "the technology isn't ready" — before it takes root: the tools underperforming in one third of companies are the same tools working elsewhere. Same vendors, same models, same licence fees. Roughly a quarter of companies report meaningful acceleration in how they develop and ship products. The divergence isn't in the software. It's in what surrounded the software.
The report's own diagnosis is almost offensively simple: the companies that lost productivity deployed the tools without changing how work gets done. They bought capability and bolted it onto a workflow designed for a world where the tool didn't exist. Nobody decided what the AI was actually for inside each process — which step it owned, who checked its output, what "good" looked like on the other side. So it did what any powerful thing does when nobody gives it a job: it made everything louder, faster and busier, and let the humans sort out the rest.
There's a name circulating for the failure mode — "vibe working", after the vibe-coding trend the report singles out: pointing an autonomous tool at a task and hoping the output is fine, because checking it would take as long as doing it yourself. Nearly half of professional developers now say they distrust the accuracy of what these tools produce — the people closest to the technology trust it least, because they're the ones cleaning up after it.
And here's the managerial irony baked into all of this: the dashboards look better than ever. Activity metrics — drafts written, code committed, tasks touched — are the numbers that get reported upward, and they're all pointing the wrong way. A leader reading the activity reports sees acceleration everywhere. A leader reading the outcomes sees the truth a quarter later, when the release schedule hasn't moved and the budget request for more licences lands on their desk anyway.
Why the Fix Isn't More AI
The predictable corporate response to "our AI isn't delivering" is already underway: upgrade the tools, expand the licences, buy the newer model. Most enterprises are now overshooting their AI budgets on exactly this logic — treating a deployment problem as a procurement problem. It's the corporate equivalent of buying a faster treadmill for someone whose running form is injuring them. The injury arrives quicker.
The deeper reason this keeps happening is that buying the tool is the easy decision — a signature, a line item, an announcement that makes leadership look responsive. Redesigning the work is the hard decision: slower, unglamorous, impossible to announce in a press release. It requires admitting that the expensive software everyone just rolled out doesn't work the way it was rolled out — and in most organisations, the person who approved the rollout is also the person who'd have to admit that. So the licences expand and the workflow stays broken.
What the more productive share of companies did differently wasn't buying better AI. It was slower and less glamorous: they redesigned the work first. They decided which tasks the tools would own and which they wouldn't touch. They built checking into the process instead of leaving it to individual conscience. And they invested in the thing the tool vendors never mention in the demo — people who actually understand what they're working with, who can direct it precisely and judge the output honestly rather than hopefully.
That combination — workflow designed around the tool, people trained to run it — is the unglamorous dividing line between the 30% that went backwards and everyone else. It was never about the AI. It was always about the approach.
Notice what this means for the honest answer to "does AI actually save time at work". Yes — and no — and the difference isn't luck. It saves time for the team that decided what it was for before switching it on. It costs time for the team that treated installation as implementation. The same hour a fluent team spends directing and verifying, a dabbling team spends untangling and re-doing — both are "using AI", and only one of them would do it again if they could take it back.
The Systematic Version
The frustrating part for anyone inside the unproductive third is that none of this is exotic knowledge. It's the same lesson every productivity technology has ever taught: the tool doesn't reorganise the work — you do, or the gains get eaten by the chaos. Electricity did it to factories. Spreadsheets did it to finance teams. AI is doing it to everyone at once, faster.
Our AI Automation course is built around that dividing line — not how the tools work in a demo, but how work gets redesigned so they actually pay. It arrives as short daily email lessons, built for people running real workflows rather than collecting certificates, and it's grounded in the systematic approach the data keeps pointing at: deciding what to automate, putting the right checks around it, and building skills your team can stand behind. What you walk away with is a way of thinking about AI and work that survives the next model release — because it was never about the model.
In other words: the difference between the 30% and the 70% isn't a better tool, a bigger budget, or a luckier industry. It's a skill set — and unlike the tools themselves, a skill set can't be purchased in a licence agreement. It has to be learned.
And if your team's problem is less about workflow design and more about getting reliable output from the tools at all — the prompting skill gap underneath the distrust — our Prompt Engineering for Professionals course covers that half of the equation.
The McKinsey number will get quoted everywhere this week as a scepticism story — proof the AI wave overpromised. Read properly, it's the opposite: proof that the gains are real, available, and currently being captured by the companies and people who did the boring structural work. The tools didn't decide which side of the 30% a company landed on. The approach did.
Keep Reading
Explore more practical guides and insights to stay ahead of contract review best practices.


