Are we witnessing the end of traditional software factories, or the beginning of a more interesting kind of engineering organization?
For decades, many software organizations have relied on a familiar formula: need more features, hire more developers; need faster delivery, add another team; need lower costs, outsource to a lower-cost market.
That formula built an enormous global industry. But in 2026, AI assistants can generate implementations, tests, documentation, and increasingly complex changes. This raises an uncomfortable question for traditional software factories:
If writing code becomes cheaper, what exactly are we paying external development providers for?
I don't think outsourcing will disappear. I think the ability to produce code is becoming less distinctive than the ability to understand, operate, and evolve the product behind it.
The software factory was built around scarcity
The traditional factory emerged from legitimate needs: scarce local engineering talent, temporary specialist requirements, and a desire for flexible delivery capacity. External providers can offer talent, speed, and predictable commercial arrangements.
But there has always been a tension: the people producing software aren't necessarily the people who own its consequences.
A project can pass acceptance tests and be delivered on schedule. Six months later, nobody at the customer may remember why an integration is asynchronous, why a database constraint was omitted, or why an unusual validation exists.
The repository explains what the system does. It seldom preserves the full history of why.
A company can own every line of source code and still lack the capability to evolve its own product.
This is not unique to outsourcing. Internal teams with high turnover or weak documentation can lose knowledge too. But project-based handovers make the problem particularly visible.
AI changes the economics of implementation—not necessarily delivery
In three randomized field experiments involving 4,867 developers, researchers estimated 26.08% more completed tasks among developers given access to an AI coding assistant (standard error: 10.3 percentage points). The results varied across settings, and the outcome was completed tasks—not lifetime product cost or customer value. The paper appeared online in Management Science in 2026.
Source: Cui et al., The Effects of Generative AI on High-Skilled Work, Management Science (2026)
Google's 2025 DORA research similarly suggests widespread AI adoption, while emphasizing that AI amplifies the strengths and weaknesses of the surrounding organization.
But faster code generation is not always faster delivery. In a randomized study of 16 experienced open-source developers working on 246 tasks, METR found that access to early-2025 AI tools increased completion time by 19% in the studied setting.
METR's February 2026 update discussed newer evidence of potential speedups but also methodological limitations that prevented a reliable estimate.
These experiments should not be averaged into a single productivity number: they examine different people, tools, tasks, and outcomes. The lesson isn't that AI is always faster or slower. It is that code production and successful software delivery are different things. Review, integration, operational risk, and long-term maintenance still matter.
Outsourcing contracts are changing—but causality remains uncertain
According to the ISG Americas Q2 2026 Index, combined cloud and managed-services contract value rose 39% year over year, while traditional IT outsourcing contract value declined 23%. Engineering services, including AI integration work, increased 9%.
Technology services spending can grow while some traditional delivery models shrink.
This is not proof that AI caused the decline. ISG measures particular contract categories and sizes, and a quarter does not establish a permanent trend. But it challenges the assumption that every form of software outsourcing benefits equally from technological growth.
ISG's outsourcing index tracks commercial contracts meeting its reporting thresholds, including annual contract value. Its combined market includes cloud-based as-a-service offerings and managed services. Cloud infrastructure spending is not equivalent to custom software development. A decline in one outsourcing category does not prove that software engineering demand as a whole has declined.What exactly does ISG measure?
Four regions, different market signals
🇺🇸 North America: Pressure on transactional delivery
North American companies are major buyers of global software services. The Americas ISG data shows weaker traditional application development and maintenance contracting alongside strong cloud and AI-related demand.
One plausible explanation is a changing build-versus-buy calculation: if a capable internal team can implement more with AI, outsourcing routine implementation solely for labor capacity may become less compelling.
But reducing coding contracts is not reducing the need for engineering accountability. Architecture, security, integrations, and production operations still need owners.
🇨🇱 South America: Beyond cheaper nearshore developers
Latin America has developed a substantial nearshore engineering ecosystem based on time-zone alignment, technical talent, and competitive costs.
A 2026 report from the IDB, World Bank, and WTO found that Latin American and Caribbean exports of digitally delivered services grew from $18.5 billion in 2005 to $87.7 billion in 2024, yet represented only about 2% of the global total. These figures cover more than software outsourcing.
If customers can use AI to increase internal capacity, the strongest regional opportunities may move toward differentiated expertise: financial infrastructure, healthcare interoperability, logistics, cloud modernization, distributed systems, and regulated integrations.
The opportunity is not merely to provide cheaper programmers. It is to become a more valuable engineering partner.
🇪🇺 Europe: Continuity and specialization
The ISG EMEA Q2 2026 Index reported 21% year-over-year growth in managed-services contract value, contrasting with the Americas.
Eurostat reported 10.45 million ICT specialists employed in the EU in 2025.
Europe's long-lived enterprise systems, regulated environments, and multinational integrations can reward stable providers with deep institutional knowledge. The distinction is not external versus internal: it is continuous responsibility versus interchangeable project staffing.
🇮🇳 Asia: Scale is not disappearing
The ISG Asia Pacific Q2 2026 Index reported 50.5% year-over-year growth in combined technology-services contract value, including strong growth in cloud services. Individual categories performed differently.
India's established outsourcing ecosystem and global capability centers (GCCs) show that globally distributed engineering can remain important. GCCs also illustrate an alternative: permanent engineering organizations abroad, with closer strategic alignment and knowledge continuity than a succession of temporary projects.
A production incident reveals the ownership gap
Imagine a logistics platform where an apparently small change adds a field to a shipment event. An AI agent updates the schema, the API, the migration, and the tests in an afternoon. The feature passes acceptance testing.
Weeks later, an older consumer replays events and interprets missing values incorrectly. A customer-facing report becomes inconsistent. The immediate fix is small; discovering the business meaning of the field, the replay semantics, and the reason the older consumer exists is not.
This is a hypothetical example, not a measured case study. It illustrates the difference between delivering an implementation and carrying the consequences of a decision across the product lifecycle. The same failure could happen with an internal team: employment status is not a substitute for institutional memory.
When AI-generated output becomes a review bottleneck
The cost of producing a plausible change is not the same as the cost of establishing that it is correct. A team can now receive more pull requests, test cases, and proposed fixes than its review and validation process can safely absorb. The bottleneck moves from typing to verification, prioritization, and integration.
This distinction matters for outsourced delivery, too. A provider may show an impressive increase in completed tickets while the customer's architecture group, security reviewers, or production engineers inherit an expanding queue of unresolved decisions. The appropriate response is not to reject AI-generated work, but to invest in automated checks, clear ownership boundaries, review capacity, and reliable production feedback.
In economic terms, lowering the price of implementation can increase demand for the complementary capabilities that make implementation useful. That is a hypothesis about organizational behavior, not a measured prediction that every company will hire more core engineers.
What is a core engineering team?
A core team is not defined simply by who signs its paychecks. It is defined by who remains accountable after a feature ships.
That team understands the domain, architectural trade-offs, operational failure modes, product priorities, and consequences of change.
Consider two delivery arrangements:
| Project delivery | Continuous product ownership |
|---|---|
| Receive requirements | Clarify and challenge requirements |
| Implement accepted scope | Consider effects on the whole system |
| Pass tests and hand over | Monitor behavior in production |
| Close the engagement | Remain accountable for evolution |
Neither model guarantees good engineering. But continuous responsibility creates stronger incentives to consider long-term costs.
A feature that takes two days to generate can still create years of maintenance obligations.
What does research say about ownership?
The 2024 study Examining Ownership Models in Software Teams: A Systematic Literature Review and a Replication Study reviewed 79 papers and revisited relationships between ownership and software quality. Not all previously reported correlations with defects replicated.
That matters: a smaller number of contributors does not automatically mean fewer bugs.
We should distinguish:
- Code ownership: Who changes particular files or components?
- Knowledge ownership: Who understands the decisions and constraints?
- Product ownership: Who is accountable for behavior, outcomes, and evolution?
These overlap, but they are not identical. The third is the organizational capability I believe becomes increasingly valuable in the AI era.
AI doesn't eliminate engineering responsibility
Imagine asking an AI agent to add a customer field and propagate it across several services. It may update models, APIs, migrations, events, and tests rapidly.
An engineer familiar with the system still needs to ask: Are old consumers compatible? Is the field sensitive? What happens during replay? Is the migration safe? What happens if downstream processing fails? Does the change contradict an earlier business decision?
AI can help investigate these questions. But someone must establish which questions matter, validate the answers, and accept responsibility.
DORA's central organizational insight is relevant here: stronger testing, internal platforms, feedback loops, and team practices help turn AI assistance into actual delivery value. Fragile organizations may merely generate changes faster than they can safely absorb them.
The economics of ownership
AI can reduce the marginal cost of drafting code, but the total cost of a change also includes discovering requirements, reviewing and integrating changes, migration, observability, incident response, and future modifications. Lowering one component does not automatically lower the whole.
A useful conceptual model is:
Lifecycle cost = implementation + integration + verification
+ operations + rework + knowledge-transfer cost
This is an accounting lens, not a validated empirical formula. It also explains why billing by developer-hours can become a poor proxy for value: the customer cares about sustainable outcomes, while an hourly contract directly prices labor inputs. Outcome-based contracts have their own problems—attribution, scope, and risk allocation—and do not magically solve accountability.
A small core team with a large capability surface
The alternative is not necessarily full insourcing.
PRODUCT STRATEGY
|
CORE PRODUCT TEAM
|
+-------------+-------------+
| | |
Domain Architecture Operations
knowledge & decisions & reliability
| | |
+-------------+-------------+
|
CONTINUOUS OWNERSHIP
|
+-------------+-------------+
| | |
AI agents External Specialized
& tooling engineers providers
The core team retains domain knowledge, architectural authority, release decisions, and operational accountability. External specialists provide expertise or capacity. AI assists with implementation, analysis, documentation, and tests.
This is a proposed operating model, not an empirically established optimal staffing ratio.
The question shifts from “How many developers do we need for these tickets?” to “Which capabilities must we retain to own this product, and which can we obtain externally?”
Outsourcing is not one business model
| Arrangement | What the customer buys | Where continuity can live |
|---|---|---|
| Staff augmentation | Temporary engineering capacity | Usually in the customer's core team |
| Fixed-scope project | A defined deliverable | At risk during handover unless deliberately transferred |
| Managed service | Ongoing service performance | With the provider, if incentives and access support it |
| Dedicated external product team | Long-lived product capability | Across customer and provider, with shared governance |
| Global capability center | An enduring distributed organizational capability | Within the company's own operating model |
These are ideal types, not mutually exclusive categories. The useful dividing line is who has decision rights, production visibility, and a duty to preserve knowledge after delivery.
The strongest counterargument: outsourcing can improve ownership
There is a serious objection to the thesis: a specialist provider with a stable team, strong operational discipline, and experience across many customers may preserve knowledge better than an internal team that rotates engineers, underinvests in documentation, or reorganizes every year. Some firms also cannot economically retain every specialist needed for security, accessibility, data platforms, or regulatory compliance.
That is why the argument should not be reduced to insource everything. The defensible principle is to retain the ability to make informed decisions and hold partners accountable, while allowing responsibility for execution—and sometimes operations—to be shared contractually with enduring external teams. Continuity, access, incentives, and decision rights matter more than payroll classification.
Three futures for the software factory
1. Commodity factories face pressure
Providers competing mainly on available developers and hourly rates may find it harder to differentiate when customers and competitors share powerful AI tools.
2. Specialized providers become more valuable
Domain expertise, complex integrations, security, regulated systems, and modernization may remain defensible areas of external engineering value. These providers sell judgment and outcomes, not just hours.
3. External teams become genuine product teams
A long-term external team can have stable membership, operate production, participate in architecture, and retain institutional knowledge. External employment is not incompatible with ownership. The key is whether responsibility survives delivery milestones.
Measure ownership, not output volume
Counting developers, tickets, story points, or generated lines of code cannot establish whether a product is becoming more sustainable.
| Dimension | Better measure |
|---|---|
| Delivery | Lead time from validated need to production |
| Reliability | Change failure rate and recovery time |
| Maintainability | Cost and risk of subsequent changes |
| Knowledge continuity | Time for a new engineer to make a safe change |
| Product impact | Adoption, retention, revenue, or operational outcomes |
| Vendor dependence | Ability to operate and change without a particular supplier |
| Economics | Total lifecycle cost, including rework and incidents |
I'd like to see longitudinal studies comparing AI-enabled permanent product teams with outsourced project teams, controlling for product maturity, complexity, and engineering practices. The existing evidence does not yet justify a universal claim that one model wins.
A practical test for product ownership
Before expanding or replacing an engineering provider, ask: Can we explain our most consequential architectural decisions? Can we deploy, roll back, and recover without one particular contractor? Who decides whether a requested feature is safe for existing customers? Who investigates incidents six months after handover? How quickly can a new engineer make a safe change?
If the answers are unclear, the risk is not simply vendor lock-in. It is capability lock-out: possessing the repository without possessing the knowledge, access, and judgment needed to evolve it.
A useful practical exercise is to run a supplier-absence drill: choose a low-risk production change and ask the retained team to trace the requirement, identify affected consumers, ship behind a rollback plan, and explain how they would investigate an incident. The goal is not to prove that the vendor is dispensable. It is to discover which capabilities depend on undocumented relationships before a crisis exposes them.
The question we should be asking in 2026
For years, software organizations were designed around the scarcity of people who could write code. AI changes that constraint without removing the need for engineering expertise.
As implementation becomes more accessible, domain understanding, architectural judgment, operational reliability, and accountability may become even more valuable.
That doesn't mean every company should build everything internally. It means companies should avoid accidentally outsourcing the knowledge and decision-making capabilities required to sustain their products.
The question is no longer just who can build the software. It's who will understand it, maintain it, and take responsibility for what happens next.
Perhaps that's what AI is really forcing us to reconsider: not the value of developers, but the value of ownership.
Reading the evidence carefully
The productivity studies above are experiments about development tasks; DORA describes associations and organizational practices; ISG measures qualifying commercial contracts; and regional trade statistics include services other than software. None directly estimates the causal effect of AI on outsourcing employment, nor proves that internally employed teams outperform enduring external teams. The regional interpretations and future scenarios are arguments to test, not observed outcomes.
Sources and further reading
- Cui et al. (2026), The Effects of Generative AI on High-Skilled Work, Management Science
- METR (2025), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
- METR (2026), Developer Productivity Experiment Update
- Google DORA (2025), State of AI-assisted Software Development
- Koana et al. (2024), Examining Ownership Models in Software Teams
- A Mosaic of Perspectives: Understanding Ownership in Software Engineering (2025)
- ISG (2026), Americas Q2 Technology Services Index
- ISG (2026), EMEA Q2 Technology Services Index
- ISG (2026), Asia Pacific Q2 Technology Services Index
- IDB, World Bank & WTO (2026), Digital Trade in Latin America and the Caribbean
- Eurostat (2026), ICT Specialists in the EU
This article presents an interpretation of multiple studies and market reports, not a causal demonstration that AI is replacing outsourcing. The underlying sources measure different populations and outcomes.
What do you think? If your main development provider disappeared tomorrow, could your team still deploy, debug, and evolve the product?
Top comments (0)