SAIme old story
On the journey through AI transformation
“We’re going to have to do more with less.”
If you’ve worked in technology long enough, you’ve heard this sentence. You may have said it. You’ve almost certainly had it said to you.
It accompanied the sonic boom of the dotcom crash, when companies discovered that continuing to raise venture capital might mean they had to be evil after all. It was the sound of the shutters coming down in 2008, when the financial crisis forced entire industries to find the people they could live without. It was the swoosh of the axe falling in 2022, when the pandemic hiring spree corrected itself and tech companies that had doubled their engineering headcount in two years cut tens of thousands of roles in a matter of months.
Each time, the language was different. The meaning underneath was the same. Fewer people. Same output.
Now it’s happening again. “AI-native workflows,” “productivity multipliers,” “agents.” The terminology varies. The meaning stays the same. Fewer people. More output.
There’s no question that AI is going to change software development irrevocably. There’s a strong argument that it already has. Beneath the promises of 10x productivity and podcast talking points, there are questions that every leader is struggling with.
What does our organisation of the future look like?
What does that mean for the people who work here?
When a leader sits down with her current org chart, and reviews the current team compositions and roles, what changes? What doesn’t? What do the people who work here do on Tuesday morning? What about the same Tuesday next year? What is she going to do with the promised productivity gains, assuming that they materialise?
One of the ways in which AI gains have been promised is that it will make engineers deliver more code, faster. But code generation is rarely the bottleneck in software delivery. More time is invested in system design, knowledge transfer, requirements clarification, and understanding the impact of changes on the existing system. AI can help with some of this, but without a strong documentation culture, organisations will continue to rely on engineers’ deep understanding of the business, the users, and the accumulated decisions that shaped the current system.
That’s before we get into the messy reality of workflows. Engineers waiting for designs to be signed off. The PM not available to confirm how something should work. Backend API development lagging behind the frontend. Changes handed off to QA once it’s “code complete.” Pipelines and approvals to navigate before anything reaches production.
AI puts those workflows up for grabs. A strong backend engineer can lean on AI to create React components and compensate for missing design. A strong frontend engineer can describe an API for AI to develop. With each model iteration, the case for siloed specialists weakens. AI drafts stories and handles reporting, so the product manager’s time shifts from administration to strategy. AI enables engineers to generate test cases against acceptance criteria, blurring the lines and reducing the need for dedicated QA. The bottlenecks around the team will surface more obviously, and they can start to address them.
If our engineering leader follows the logic through, a sense of a possible future emerges. If AI makes full-stack work viable, she needs fewer specialists per team. If QA is automated, she needs quality engineers, not testers. The shape of the team changes. If PM admin evaporates, a strategic PM can focus on product strategy and understanding customer needs. Understanding what to build and why becomes more valuable. When everyone is moving faster, the cost of building the wrong thing goes up.
An organisation with a hundred engineers in 14 teams of seven could be reorganised into 14 teams of five and save 30 positions. This is the path being very publicly taken by several organisations. Companies announce AI-driven redundancies, stock prices go up, and the remaining engineers are told to be grateful they still have a job until the models get better.
But the headlines are anticipating a future that hasn’t arrived yet. The productivity gains from AI to date have been around 10 per cent, and that’s roughly where they’ll stay if nothing else changes. This is the Solow paradox playing out in real time: you can see AI everywhere except in the productivity statistics.
The gains are modest because the bottlenecks aren’t inside the team; they’re in the system around it. Approvals, handoffs, coordination overhead, organisational friction. Cutting headcount doesn’t remove these constraints. Investing in AI-enabled teams, accelerating their ability to deliver surfaces those system-level bottlenecks, which forces the organisation to address them. The constraint moves from funnelling work through a team to enabling the whole system to deliver. That’s how the 10x multiples become possible.
The same hundred engineers could be reorganised into 20 teams of five. No positions eliminated. Same people. Better outcomes. The organisation doesn’t shrink; it multiplies its delivery capacity by 40 per cent, and each of those teams is AI-amplified on top of that.
There’s an obvious counter-argument: “what if there’s not enough work to go around?” Everywhere I’ve ever worked, the issue has been we couldn’t get all the things we wanted done. I’m not sure this would change even with the extra capacity. If it does, then reductions will at least be strategic rather than reactive.
None of which makes it easier for the backend Java engineer with eight years of experience who’s told he’s now full-stack. This is going to be a traumatic change, whichever path is chosen.
“I’m a backend Java engineer” is a sentence that carries the weight of years of career investment and hard-won expertise. Telling someone that the organisation no longer needs backend Java engineers, but does need full-stack engineers who work across the whole codebase with AI assistance, isn’t a job description change. It’s an identity disruption.
The same is true for the QA engineer whose role shifts from writing test cases to owning quality strategy, or the product manager who thinks the disappearing admin work is how they deliver value. The engineering manager who was dedicated to a single team now covers two or three, because smaller teams need less day-to-day coordination and more strategic support. And the leader herself, whose scope of responsibility shifts as parts of her job are automated and others are entirely new. Each of these is a genuine career transition. Losing a job is brutal, but at least it’s clear. Losing what your job meant, while learning a new version of it, is harder to grieve because nobody recognises the loss.
The organisations that navigate this future know this isn’t about role changes alone. This is change management writ large. The cultural shift from “I write code” to “I ship valuable software, and AI writes the code” will not happen easily. The destination isn’t fully visible yet, and it’s going to have to be managed carefully.
The companies cutting headcount are making a bet that smaller teams will deliver the same or more, and that the models will keep accelerating fast enough to justify the pain. I think this is misreading where we are in the J-curve. The productivity gains haven’t shown up yet because we’re still in the investment phase of the curve. The returns come after the redesign, not before it.
Cutting headcount is easy for a board to reason with. It looks like action. Redesigning the organisation so that the same people, in different configurations, can deliver on the promise of AI amplification is hard. And that’s where the rewards are.
We can do more. It just doesn’t have to be with less.
So well articulated! Am sharing with Developer friends