The 40% Layoff Is a Confession, Not a Strategy

A software company in Australia just laid off 40% of its engineering staff and told the press that AI made them do it. The CEO said something about shifting priorities, the usual corporate euphemisms. But the part that actually matters — the part every engineering leader should be paying attention to — is what a move like this actually confesses about the organization.

Because here is the thing nobody wants to say out loud: if you can fire 40% of your engineers and the product keeps working, you had a people problem long before you had an AI solution.

The Headcount Was the Product

I have been building software for 14 years across every kind of team — startups where three people built everything, enterprises where thirty people maintained a login page, and everything in between. The pattern I have seen over and over is that engineering organizations grow headcount not because the product demands it, but because the org chart demands it.

Managers need reports. Directors need managers. VPs need directors. Every layer needs enough people underneath it to justify its existence. Before you know it, you have a 200-person engineering department where maybe 40 of them are actually building things that users touch. The rest are in meetings about meetings, writing documents about documents, and maintaining internal tools that exist to manage the complexity created by having too many people.

This is not an AI story. This is a Pareto principle story dressed up in AI clothing. The 40% who got cut were probably not the ones writing the code that matters. They were likely the coordination tax — the human middleware that exists in every bloated org to shuttle information between the people who actually build things.

AI Is the Excuse, Not the Cause

Let me be precise about what AI coding tools actually do well right now. They are excellent at generating boilerplate. They are good at translating well-specified requirements into code. They can write tests if you tell them exactly what to test. They are increasingly capable at refactoring and pattern application.

What they cannot do — and this matters — is understand why a system was built the way it was. They cannot navigate the political landscape of a codebase where module A exists because the team that owned module B refused to add an endpoint three years ago. They cannot look at a performance problem and realize it exists because the original architect optimized for a usage pattern the business pivoted away from in 2024.

When a CEO stands up and says AI let us cut 40% of engineering, what I hear is: we had 40% of our engineers doing work that required no institutional knowledge, no architectural judgment, and no creative problem-solving. We were paying senior salaries for junior-level ticket completion. And rather than fix our engineering culture, we replaced the warm bodies with a cheaper alternative.

What Actually Happens After the Cut

I have seen this movie before, just with different villains. In 2008 it was offshoring. In 2015 it was microservices making teams smaller. In 2020 it was the pandemic efficiency narrative. Every time, the script is the same:

I am not speculating here. We at Fordel work with companies as external engineering partners, and some of our best client relationships started exactly at month 7 of this cycle. A company cuts aggressively, realizes they lost more than they planned, and brings in external teams to fill the gap. The irony is that they often end up spending more on contractors and consultants than they saved on the layoffs.

The Engineers Who Should Worry (and the Ones Who Should Not)

Here is my honest read on who is actually at risk and who is not, based on what I see in the market right now:

At risk: Engineers whose primary value is translating Jira tickets into code. If your job is to take a well-specified requirement and produce a pull request, AI tools are coming for that workflow. Not because the AI is better than you — it is often worse — but because it is cheaper and faster for the 80% case. The economics are brutal.

Not at risk: Engineers who understand systems. If you can look at a production incident and trace it back through three services to a race condition that only manifests under specific load patterns, no AI is replacing you. If you can sit in a product discussion and explain why the proposed feature will break the billing system assumptions, you are safe. If you can make architectural decisions that account for where the business is going, not just where it is today — you are the person companies will fight to keep.

This is the same thing I wrote about in my piece on the death of implementation as a moat. The moat was never the code. The moat was always the thinking that informed the code. AI just made that distinction impossible to ignore.

The Real Efficiency Play Nobody Talks About

Want to know what actually makes engineering teams more efficient? It is not firing people and replacing them with Copilot. It is fixing the things that made your team slow in the first place.

In my experience working across dozens of codebases, the biggest engineering bottlenecks are never typing speed. They are:

AI tools help with exactly none of these. You know what helps? Smaller teams with clear ownership. Fewer meetings. Better tooling. Empowered engineers who can make decisions without three layers of approval. The boring stuff that requires organizational discipline rather than a shiny new technology.

The companies I have seen get the most out of AI tools are the ones that were already well-organized. They had clean codebases, clear APIs between services, good documentation, and engineers who understood the business domain. For those teams, AI is a genuine force multiplier. For dysfunctional teams, AI just generates dysfunction faster.

The Consulting Industry Smells Blood

IBM just published a piece about how the old consulting playbook no longer works in the age of AI. And they are right — but not for the reasons they think.

The old consulting playbook was: fly in expensive people, assess the situation, produce a deck, recommend a transformation, staff it with junior consultants, bill for 18 months, leave. The AI version of this playbook is identical except now the deck includes the word agentic and the junior consultants have GitHub Copilot licenses.

What actually needs to change is the engagement model. Companies do not need another firm telling them to adopt AI. They need engineering partners who can actually build things, who understand the difference between a demo and a production system, and who will tell them the truth about what AI can and cannot do for their specific situation.

What I Would Do Instead

If I were running a 200-person engineering org and genuinely wanted to get more efficient with AI, here is what I would do instead of a mass layoff:

First, I would audit what my engineers actually spend time on. Not what Jira says. What they actually do hour by hour. In every org I have examined, at least 30% of engineering time goes to coordination overhead, context switching, and fighting tooling. Fix those first.

Second, I would invest in AI tooling for my existing team. Give every engineer access to the best AI coding tools available. Train them properly — not a lunch-and-learn, real training on how to use these tools effectively for your specific codebase and workflows.

Third, I would restructure around ownership, not headcount. Small teams that own entire features end-to-end, with the authority to make decisions and ship. Two engineers who own a service are worth more than ten who share responsibility for it.

Fourth, I would let natural attrition do the work. People leave. They always do. When they leave, evaluate whether you need to backfill or whether AI tools have genuinely absorbed that capacity. This is slower than a dramatic layoff but it does not destroy your culture or your knowledge base.

Finally, I would be honest with my team. Tell them the industry is changing. Tell them what you expect them to learn. Give them a path to evolve rather than a pink slip. The engineers who survive the AI transition will be the ones who chose to level up, and they will remember which companies gave them the chance to do it.

The Confession

A 40% layoff is not a strategy. It is a confession. It says: we built an organization where nearly half the work was low-judgment implementation that a text prediction model can approximate. We hired for headcount instead of capability. We confused activity with output. And rather than fix the organizational problems that led to this bloat, we are going to fire a bunch of people and call it innovation.

The companies that will actually win the AI transition are not the ones making the biggest cuts. They are the ones that never got bloated in the first place. They are the ones with engineers who think, not just type. They are the ones investing in their people rather than replacing them.

And if you are an engineer reading this and wondering if you are next — stop worrying about whether AI can write your code. Start worrying about whether you can do the things AI cannot. Understand systems. Understand the business. Make judgment calls under uncertainty. Navigate ambiguity. Those are the skills that will matter in 2027, 2030, and probably 2040.

The typing was never the hard part. It just took a robot to make everyone finally admit it.