More Software, Fewer Service Hours? The Innovator’s Dilemma in Software Engineering Services.

Around 2006, I first encountered Clayton Christensen’s theory of disruptive innovation. What stayed with me was not simply that new technologies can displace established companies. It was his explanation of why successful incumbents often react rationally to a disruptive development—and still lose their position.

The pattern feels increasingly relevant to the Software Engineering Services market.

AI is improving how software is designed, built, tested and maintained. Software Engineering Partners are introducing copilots, agents and AI-assisted delivery methods. Tech Buyers are doing the same inside their own organisations.

But the strategic question is not merely whether AI makes developers more productive. It is whether AI-native engineering changes the delivery model, the economics and ultimately the client’s need for external services.

The possible outcome sounds paradoxical:

Companies may create more software while purchasing fewer external engineering hours.

If this happens, the demand for software outcomes can continue to grow while the traditional market for selling development capacity comes under increasing pressure.

AI is not automatically a disruptive innovation

Christensen’s theory is frequently reduced to the idea that any important new technology is “disruptive”. That is not what the theory says.

Disruptive innovation describes a competitive process. A simpler, more accessible or more affordable offering initially serves people who could not use the established solution, or customers whose needs are overserved by it. The new offering may initially perform poorly against the established market’s traditional measures. It then improves and moves towards more demanding applications.

The Clayton Christensen Institute makes the same distinction specifically in relation to AI: AI is not inherently disruptive or sustaining. What matters is the business model in which it is used and the competitive effect it has on a particular product or service market.

This distinction matters for Software Engineering Services.

If an established provider gives its developers AI tools but continues selling similar teams through the same time-and-materials model, AI is primarily a sustaining or efficiency innovation. Delivery may become faster or more profitable, but the underlying customer proposition remains largely unchanged.

The more disruptive possibility appears when AI enables a different model:

• smaller teams can deliver outcomes that previously required much larger teams;
• business or technology teams can create some applications without outsourcing a conventional development project;
• previously uneconomic software needs become affordable;
• new providers can operate without the staffing pyramid and utilisation requirements of established service companies;
• software creation can be sold as an outcome, managed capability or accessible creation environment rather than as engineering hours.

In that scenario, AI is the technological enabler. The AI-native delivery and business model is the potential disruption.

Where could the disruption begin?

Disruptive models normally do not begin by replacing the most complex and demanding incumbent offering. They find a foothold where the established solution is too expensive, too cumbersome or simply unavailable.

In software creation, such footholds may include:

• departmental applications and internal workflows;
• prototypes and short-lived applications;
• small integrations and data-processing tasks;
• test creation, documentation and remediation work;
• neglected maintenance and modernisation backlogs;
• applications that were never built because a conventional project could not be justified.

Early AI-created solutions may be weaker on architecture, maintainability, security, integration and operational reliability. Established providers can reasonably argue that these solutions do not yet meet the requirements of complex enterprise environments.

They may be right—and still underestimate the trajectory.

Agents, automated verification, richer enterprise context, architecture controls and improved development environments can progressively extend the range of work that AI-native approaches can perform. The relevant question is therefore not only what an approach can deliver today. It is whether it can move into more demanding work without recreating the full cost and complexity of the model it challenges.

Not every AI engineering offer will follow this path. Some will remain useful tools, some will complement incumbent services, and some will fail. Christensen’s theory should be used as a lens for identifying a possible competitive process, not as proof that every AI development product will become a disruptor.

More software does not necessarily mean more services revenue

The impact on the overall market can be understood through three variables:

External services demand = demand for software outcomes × external share of delivery × service effort and cost per outcome

AI-native engineering can affect all three.

1. Demand for software outcomes may increase

As software becomes faster and less expensive to create, more needs become economically viable. Companies can address smaller process problems, modernise neglected applications, experiment more frequently and embed software in more products and operations.

The total amount of software created could therefore grow substantially.

2. The external share of delivery may decrease

Tech Buyers are not only purchasing AI-enabled services. They are building their own engineering systems around agents, repositories, enterprise context, architecture rules, automated testing and internal platforms.

As these capabilities improve, clients can perform more creation internally. External partners remain relevant, but the boundary between internal and external responsibility moves.

3. The effort required per outcome may decrease

A compact AI-supported team may be able to perform work that previously required a much larger delivery organisation. Even where the work remains external, the required number of billable hours or full-time equivalents may fall.

The net effect on total market revenue is not predetermined. It depends partly on whether additional software demand grows faster than productivity and internalisation reduce external effort.

But the direction for the traditional capacity model is clearer: delivered software, provider revenue and engineering headcount may no longer grow together as they did in the past.

Why established providers may respond rationally—and too slowly

Christensen’s incumbent dilemma was not primarily about poor leadership or an inability to recognise technology. Established organisations often make sensible decisions based on the customers, economics and performance measures that made them successful.

Many Software Engineering Partners are organised around:

• billable headcount;
• utilisation targets;
• rate cards and person-months;
• sales incentives favouring larger engagements;
• a staffing pyramid with many junior and mid-level engineers;
• delivery centres designed to provide scalable capacity;
• revenue forecasts linked to team size and contract duration.

An AI-native model promising dramatically smaller teams and fewer billable hours conflicts with these economics. Even if the provider understands the technology, its existing processes may encourage it to apply AI in ways that protect the current model.

The likely response is therefore not necessarily to reject AI. It may be to incorporate AI into the established proposition:

Our existing teams now use AI, so the existing delivery and commercial model remains valid.

That can create genuine improvements. It does not, however, answer the disruptive question.

An incumbent may also retreat towards larger, more complex and higher-margin engagements as simpler work becomes less attractive. In the short term, this is economically reasonable. Christensen’s examples show why it can nevertheless become dangerous if the new model continues to improve and follows the incumbent into progressively more demanding market segments.

Client demand shifts from production capacity to complementary value

The historical client need was often expressed in terms of capacity:

We do not have enough developers. Provide a team.

An AI-native client organisation may formulate the need differently:

Complement our engineering environment with capabilities, assurance or responsibility that we cannot provide reliably ourselves.

This does not eliminate the role of Software Engineering Partners. It changes the source of their value.

Capabilities likely to become more important in relative terms include:

• deep industry and domain expertise;
• complex architecture and systems integration;
• cybersecurity, privacy and regulatory assurance;
• modernisation of difficult legacy environments;
• independent verification of AI-created systems;
• accountability for production outcomes;
• forward-deployed engineers working closely with the client’s business and technical context;
• operation and governance of complex systems;
• temporary access to scarce specialist expertise.

Capacity will still matter, especially during major transformations, urgent programmes or temporary demand peaks. But access to competent developers becomes a weaker standalone differentiator when clients and competitors can use AI to compress the execution effort.

The provider market may become more polarised

If this development continues, the Software Engineering Services market may become increasingly barbell-shaped.

At one end, large integrated providers can take responsibility for complex transformations, regulated environments and long-term managed operations. Their scale, enterprise access and ability to assume responsibility remain valuable.

At the other end, specialised firms and individual experts can provide scarce domain, architecture, security or platform capabilities through small senior teams.

The broad middle may experience the greatest pressure: providers whose main proposition combines competent engineering capacity, attractive rates, scalable teams and convenient delivery locations, but offers limited differentiation beyond execution.

Possible market consequences include:

• smaller delivery teams and shorter engagements;
• fewer junior-heavy projects;
• pressure on providers dependent on staff augmentation and time-based pricing;
• consolidation among mid-sized generalists;
• acquisitions of specialist firms by larger providers;
• growth of AI-native boutiques, expert networks and fractional roles;
• increasing separation between software creation and independent assurance;
• more outcome-oriented, fixed-price and managed-capability offers;
• closer integration of external experts into the client’s own engineering system.

This is a market hypothesis rather than a settled forecast. Established providers may remain successful for years, particularly while enterprise demand, transformation backlogs and existing contracts remain strong. The first evidence of disruption may not be declining industry revenue. It may appear in team composition, engagement duration, pricing, hiring patterns and the movement of engineering orchestration towards the client.

What should Tech Buyers reconsider?

For Tech Buyers, the practical consequence is not to replace every established partner with an AI-native entrant. It is to revisit assumptions that may no longer hold.

1. Reassess the sourcing boundary

Which capabilities should the organisation build and control internally? Which work can now be performed by internal teams using AI-native methods? Where does external expertise or responsibility remain more valuable than internal execution?

This decision should precede a provider search.

2. Segment the software portfolio

Routine, well-bounded and lower-risk work should not automatically be sourced through the same model as complex core systems, regulated applications or major modernisation programmes.

Different parts of the portfolio may require different combinations of internal creation, specialist support, project outsourcing and managed responsibility.

3. Evaluate the provider’s operating model, not its AI vocabulary

Almost every provider can claim to use AI. Buyers need evidence of what has actually changed:

• Has the provider reduced cycle time or team size?
• How has quality, rework and production reliability developed?
• Does the commercial model share productivity gains with the client?
• Can the provider integrate into the client’s engineering environment?
• What responsibility does it accept for AI-generated output?
• Does the approach remain economically different as complexity increases?

AI usage is a signal. It is not, by itself, evidence of an AI-native delivery model.

4. Reconsider the commercial unit

If productivity increases while the buyer continues to purchase person-months, the provider may capture most of the economic benefit.

That does not mean every engagement should move immediately to fixed price. Uncertainty, changing scope and shared responsibility still matter. But buyers should examine whether hours, team size and rate cards remain the most appropriate basis for value—or whether deliverables, outcomes, managed capabilities and explicit responsibility offer a better fit.

5. Retain control of context and governance

The customer’s repositories, domain knowledge, architecture rules, testing assets and operational feedback become increasingly important components of an AI-native engineering environment.

Buyers should decide deliberately who controls this context, how external partners access it, how outputs are verified and how easily the operating model can be transferred or changed. A new dependency on a provider-controlled AI environment may replace rather than remove the previous form of lock-in.

6. Assess trajectory as well as current performance

An emerging model may initially be unsuitable for critical production work. That is a valid reason not to use it for that work today. It is not a reason to ignore how quickly its capabilities and economics are changing.

Bounded experiments can help buyers determine where AI-native delivery is already viable, what assurance it still requires and which sourcing assumptions should be revisited before the next major partner decision.

The sourcing question behind the disruption

The Software Engineering Services market is unlikely to disappear. The need for software may continue to expand, and external partners will remain important wherever clients need scarce expertise, independent assurance, temporary acceleration or accountable delivery.

What is changing is the relationship between software demand and external labour demand.

AI-native engineering can allow more software to be created with less execution effort. It can also allow the client to internalise a greater share of that execution. The result may be an expanding software economy alongside a slower-growing—or eventually contracting—market for conventional development capacity.

The most important question for Tech Buyers is therefore not:

Which provider has adopted the most AI tools?

It is:

What should remain internal, what should be sourced externally, and what distinctive value and responsibility should the external partner provide in an AI-native engineering model?

That sourcing-boundary decision will shape the required capabilities, evidence, engagement model and governance. It should be reconsidered before simply procuring a more efficient version of the delivery model the organisation already has.

Frequently asked questions

Is AI itself disrupting the Software Engineering Services market?

Not necessarily. AI used to improve an existing delivery model is mainly a sustaining or efficiency innovation. The potentially disruptive development is an AI-native delivery and business model that produces software with fewer people, lower initial commitment and different economics.

Will AI reduce the overall demand for Software Engineering Services?

It is likely to reduce the external effort required for each software outcome. Whether the total market contracts depends on whether additional demand for software grows faster than productivity and internalisation reduce external service volume.

Which Software Engineering Services are most exposed?

Routine implementation, junior-heavy delivery, manual testing, documentation and undifferentiated development capacity appear particularly exposed. Complex architecture, domain expertise, security, modernisation, independent assurance and accountable operation may become more valuable in relative terms.

Will established Software Engineering Partners become obsolete?

No. But their role may change from supplying production capacity towards complementing the client’s engineering environment with scarce expertise, assurance, integration and outcome responsibility.

What should Tech Buyers reconsider first?

The sourcing boundary: what the organisation should perform and control internally, what still requires external support, and what distinctive responsibility an external partner should assume.

ValueLeap perspective

Reassessing your sourcing boundary or an existing partner setup?

ValueLeap helps Tech Buyers structure, validate and govern Software Engineering sourcing and partner decisions—including the implications of AI-native engineering for internal capabilities, external responsibilities and engagement models.

Discuss your sourcing boundary with ValueLeap.

Sources and further reading

• Clayton M. Christensen, The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, Harvard Business School Press. Christensen Institute book overview
• Clayton M. Christensen, Michael E. Raynor and Rory McDonald, “What Is Disruptive Innovation?”, Harvard Business Review, December 2015. Harvard Business School PDF
• Clayton Christensen Institute, “Disruptive Innovation Theory”. Theory overview
• Michael B. Horn, “What does Disruptive Innovation Theory have to say about AI?”, Clayton Christensen Institute, 3 June 2024. Article