AI Efficiency or Just Plain Cost Cutting?

Posted by & filed under , .

A chessboard on a wooden desk with a laptop playing the black pieces and a model of a human brain playing the white pieces.Another week, another round of job cuts with AI in the press release. On Thursday Barclays said it would cut around 5,000 roles (about 5% of its staff) as part of a push for AI-driven efficiency, with roughly 60% of the cuts in support functions, developers included (CNBC has the story). This in the same quarter its pre-tax profit went up 12%. Earlier in the month HubSpot announced it was cutting nearly 660 jobs (about 7%) as it reorganises around AI, while its CEO wrote that the cuts are “not driven by AI-related efficiencies”. And eBay announced a 9% reduction this week without mentioning AI at all.

So depending on who you ask, AI is the reason, isn’t the reason, or isn’t worth a mention. Go figure. LinkedIn this week seemed split right down the middle in between “this is the future, adapt or die” and “AI is just the excuse for cost cutting”. I think both camps are missing the more useful question, which is the one I’d ask if I were the CTO in those rooms: show me the numbers.

Efficiency You’ve Measured, or Efficiency You’ve Been Promised?

Here’s the thing: there’s a big difference between “we’ve measured that AI does this work, so we need fewer people” and “we expect AI to do this work, so we’ll cut the people first”. The first one is a normal (if painful) business decision, the same as automating a factory line. The second one is a bet, and the people who lose their jobs are the stake.

And the evidence on the second one is a lot shakier than the press releases make it sound. Engineering leaders in surveys report big productivity gains from AI, but when you look at what actually ships, the picture gets murkier. LinearB’s 2026 benchmarks, for example, found that pull requests written by autonomous agents waited 17.6 hours to be picked up for review, against 3.4 hours for unassisted work, and got merged less often. In other words, the code got faster to write and the bottleneck moved to the people reviewing and releasing it. Cut those people and, quite likely, you’ve made the bottleneck worse, not better.

Now you can argue that a bank cutting support functions isn’t the same as cutting a product engineering team, and that’s fair. A lot of support work is repetitive, and some of it really is a good fit for automation. But “developers” being on that list is what caught my eye, because I keep seeing what happens when you take people out of a system before the replacement is proven: the work doesn’t disappear, it lands on whoever is left, and the knowledge of why things are the way they are walks out with the people who leave.

The Bit Nobody Puts in the Press Release

Anyone who has led an engineering team through a reduction knows the cut itself is only half the story; the other half is what happens to the team afterwards. Every reduction sends a message to the people who stay, and right now the message a lot of engineers are hearing is “the better you get at using AI, the sooner we’ll replace you”. That’s a terrible incentive! The people you most need to figure out how AI fits into your engineering process are the ones who now have every reason to keep their productivity gains to themselves.

The other cost is the one that shows up in 3 to 5 years. Cuts made in the name of AI tend to aim at junior and support roles (60% of Barclays’ are in support functions), because that’s where AI looks most capable on paper. But that’s also where your future senior engineers come from. If nobody hires juniors because “the AI does that now”, then in a few years there won’t be anyone around who learnt the system well enough to supervise the AI. I’d argue that’s the biggest risk in all of this, and it’s one no quarterly report will flag.

What I’d Ask

If I were sitting on the leadership side of one of these decisions, these are the questions I’d want answered before anyone signed off:

  • Which specific work is AI doing today, measured in production, not in a pilot or a vendor deck?
  • Where does that work go next? Who reviews it, who’s on call for it, who fixes it when it’s wrong?
  • What happens to the team’s workload and knowledge if the AI turns out to be 30% less capable than planned?
  • What are we telling the people who stay about how AI gains will be shared, and is it true?
  • How does our junior pipeline look in 3 years?

Don’t get me wrong, I’m not saying companies should never reduce headcount because of AI. If the efficiency is real and measured, it would be odd not to act on it, and pretending otherwise isn’t doing anyone any favours. But measured comes first and the cuts come second, not the other way around.

Bottom line: AI can be a very good reason to change how a team works. It’s a lousy excuse for not knowing how your team works in the first place.