Stop Scaling Engineering With Headcount

Why the next generation of product teams will scale delivery through AI, not just more developers

For years, the response to a shortage of engineering capacity has been relatively predictable. "We need to deliver more, so we need more engineers"

That might mean recruiting permanent staff, increasing offshore capacity, bringing in contractors or asking a delivery partner to provide another squad. AI gives us an opportunity to challenge that assumption. The question organisations should increasingly be asking is not "How many more engineers do we need?" but

"How much more engineering capacity do we need — and how should we create it?"



Those are no longer necessarily the same question.

Engineering capacity is becoming different from engineering headcount

AI is already capable of performing a growing range of engineering activities. It can write code, create tests, analyse existing applications, produce documentation, refactor software, build integrations, investigate defects and help turn an idea into working software.

That does not mean organisations suddenly no longer need engineers. It means something more interesting is beginning to happen. Increasing engineering headcount is no longer the only way to increase engineering capacity.

That creates a significant opportunity for organisations that have historically relied on recruitment, offshore development or third-party delivery partners to scale. Rather than continually adding people around the edges of the organisation, they can invest more heavily in the Product and Engineering capability they want to retain internally — and progressively give those people AI capacity around them.

The strategic shift is simple:

Invest in internal capability. Scale engineering capacity with AI.

But don't start with AI

There is an important prerequisite. Before an organisation can effectively orchestrate AI delivery, Product and Engineering need to be able to work effectively together themselves. This is where Product Engineering becomes important.

In many organisations, there is still a significant handoff between Product and Engineering.

  • Product defines the requirement.
  • Engineering receives it.
  • Engineering asks for more detail.
  • Eventually it gets estimated.
  • Then it gets built.

A stronger Product Engineering model looks different.

Product and Engineering understand the problem together, shape the solution together, estimate together, deliver together and learn together.

That does not mean removing accountability. Product remains accountable for the what and why — the problem, value, desired outcome and priority. Engineering remains accountable for the how and how much — technical approach, engineering implications, sizing and delivery. But the solution is shaped collaboratively.

That matters today.It will matter even more in an AI-enabled delivery model.

Product Engineering is the foundation, not the destination

Once Product and Engineering are operating effectively as one team, another possibility opens up.
Instead of asking "How many additional developers should we add to this team? we can ask

"What if we increased this team's engineering capacity with AI instead?"

That should not be answered theoretically. It should be tested.

Take a real area of engineering demand. Give the existing Product and Engineering team access to appropriate AI delivery capability. Change the way they work. Measure what happens.

  • Can the team deliver more?
  • Does lead time reduce?
  • What happens to quality?
  • How much human engineering effort is still required?
  • Where does AI perform well?
  • Where does it struggle?
  • What new skills do our people need?

That is a much more useful experiment than trying to predict how many engineering roles AI might replace.

Don't apply the same model everywhere

One of the biggest mistakes organisations could make is assuming there will be one future operating model for engineering. There won't be.

AI capability varies significantly depending on the work being performed. So does the amount of engineering judgement required. Some areas are relatively well understood, bounded and easy to validate. Others involve significant architecture, complex integrations, legacy technology, security implications or high operational risk. The right question is therefore:

"How much human engineering oversight does this work require?"



That leads to several possible delivery models.

Product-led AI Delivery

For well understood, lower-risk work where AI can perform much of the engineering activity reliably, the human team could become predominantly Product-led. Product defines the outcome and orchestrates an AI delivery capability, within established engineering standards and controls.

Human engineering support may still exist, but it does not necessarily need to be embedded full-time in every team.

Product Engineering + AI

For more complex work, Product and Engineering remain closely paired. They jointly orchestrate AI agents while Engineering provides the architecture, technical judgement and quality oversight required.

AI increases the team's capacity rather than replacing the Engineering role.

Human-led Engineering

Some work will continue to require significant human engineering involvement.
Highly novel, complex, sensitive or high-risk environments may remain predominantly human-led, with AI providing augmentation rather than becoming the primary delivery capability.

The important point is that these models can coexist. The organisation does not have to choose one.

Start where AI is strongest

This suggests a different approach to AI transformation. Don't begin by trying to redesign the entire technology organisation.

  • Start by looking at the engineering portfolio
  • Identify areas where AI is already capable enough to make a meaningful contribution
  • Look for work that is well understood, based on established technologies, easy to test, relatively bounded and supported by good engineering practices.

Then ask:

  • Could we increase engineering capacity here without increasing engineering headcount?
  • Run the experiment
  • Measure the results
  • Build the skills of the existing team.

Then expand.

The principle should be:

Put AI capacity where AI is strongest today — and expand the boundary as its capability grows.

The role of people becomes more important, not less

There is an understandable tendency to frame AI engineering primarily as a workforce reduction discussion. That misses a much bigger opportunity.

The scarce capability of the future will not simply be the ability to produce code. It will be the ability to understand a customer problem, make good product decisions, understand a technology estate, make sound engineering judgements and effectively orchestrate increasingly capable AI systems. Those are capabilities worth owning internally.

An organisation that continually outsources engineering capacity also continually exports some of the learning generated by delivering its products. AI potentially allows organisations to change that equation.

  • Invest in permanent people who understand the customer, business and technology
  • Develop their Product Engineering capability
  • Teach them how to work with and orchestrate AI
  • Then surround them with scalable AI delivery capacity.

A different question for technology leaders

The change will not happen overnight. Nor should every engineering team immediately become an AI delivery team. But the direction creates an important question for CIOs, CTOs and Product leaders.
The next time a part of the organisation says it needs more engineering capacity, before approving another recruitment request, contractor or offshore team, ask:

"Is adding more people really the best way to create that capacity?"

Sometimes the answer will still be yes. Increasingly, it may not be.

The organisations that learn how to distinguish engineering capacity from engineering headcount — and build the internal capability to orchestrate both human and AI delivery — will develop a significant advantage.

The future engineering organisation will not be defined by how many engineers sit in each squad.
It will be defined by how effectively its people can turn customer and business intent into working technology.

Invest in internal capability. Scale engineering capacity with AI.

Where could AI increase your engineering capacity?

Not every team or every type of engineering work is ready for the same level of AI-enabled delivery.

We can help you identify where AI could create meaningful additional capacity today, where human engineering oversight still matters, and where to start experimenting safely.

Let's find you a place to start.