Consider an outsourcing arrangement in which your team explains the business problem, writes the requirements, answers the supplier’s questions, and checks the result. The supplier uses a coding agent to implement the change. When something fails in production, your service manager takes the call.
You are paying another organization to operate an agent while retaining much of the work that makes its output useful.
For routine software changes, that arrangement deserves a fresh justification. If your people already supply the context and judge the result, an internal team with the right engineering support may be better placed to direct the agent itself. The old division between a client that manages the service and a supplier that delivers changes can become an expensive way to keep knowledge and implementation apart.
Coding may still be difficult. An agent-assisted supplier may now be doing a different job from the one you originally outsourced.
The original bargain had a reason
There were good reasons to outsource software delivery. Building a development capability meant recruiting specialists, learning a stack, maintaining tools, and carrying a team through changes in demand. Implementation involved substantial repetitive work. A supplier could pool those skills across clients and offer capacity you could not economically maintain yourself.
In Deloitte’s 2022 Global Outsourcing Survey, covering business and IT activities, 57% of executives identified cost reduction as the primary driver of traditional outsourcing. The report also distinguished that model from services bought for new capabilities and operating expertise. (Deloitte)
One familiar organizational response was to retain service ownership, priorities, and supplier management inside the business while buying development capacity outside it. The client decided what mattered. The supplier supplied the people who could build it. Documents and acceptance processes connected the two.
That structure made sense when the cost of maintaining your own delivery capability exceeded the cost of explaining work to someone else. The explanation was overhead, but overhead worth paying.
Once agents can handle more routine implementation, that comparison needs doing again. A sourcing decision made for a labor-intensive delivery process should not survive indefinitely on the strength of its original business case.
The supplier is automating the part you bought
Cognizant describes Flowsource as a software engineering platform that integrates generative and agentic AI across development, including code assistance, tests, documentation, and security checks. This is the supplier’s description of its offering, not an independent measurement of how every engagement works. (Cognizant)
A supplier should use better tools.
If your supplier now uses an agent to implement the change, it is reasonable to ask what else you are paying them to provide. They may still bring expertise, support, or capacity you need. Without that distinction, you can end up buying the old labor model while receiving the new production model.
If an engagement is priced by time, reduced effort should be visible in the commercial discussion. If it is priced by outcome, the provider may reasonably retain the reward for finding a more efficient method. Even then, a renewal should compare the service with what you could now deliver internally. An existing contract does not establish the economics of the next one.
The supplier may contribute architecture, reusable components, deployment infrastructure, scarce expertise, or dependable support. Those are substantial services. Translating your instructions into prompts for a generally available agent is a much thinner proposition.
Access to the same model does not make two teams equally capable. It does remove one reason for assuming that implementation belongs on the other side of a contract.
Your service manager may already know what the agent needs
Take a hypothetical change to an internal application: invoices above a threshold need approval, except when the supplier belongs to a particular category. The person managing the service knows which category field is unreliable, which exception was introduced last year, and why one department follows a different rule.
Under the split model, that person explains the requirement. A delivery coordinator translates it. A developer prompts an agent. The proposed implementation comes back for acceptance, and the service manager points out that the exception applies to renewals too.
The developer has not necessarily done anything badly. The knowledge was separated from the act of using it.
With suitable access and engineering support, the service owner could instead work with an internal engineer and the agent on a branch of the application. They could express the exception as an acceptance test, inspect the proposed behavior together, and correct it before a formal handoff. Release approval and security checks would still apply.
An external engineer could work in that same loop. A fair sourcing comparison should give both teams equally direct access to the service owner. If closer collaboration solves the problem while the supplier still adds valuable capability, changing employers is unnecessary.
That approach does not turn a service manager into a software engineer by decree. It gives the person who understands the service a direct part in changing it. The internal engineer remains responsible for technical judgment and maintainability.
A role designed around ordering and accepting someone else’s work can now participate in producing it. Keeping that role permanently outside delivery may preserve a boundary after some of its economic justification has weakened.
Service management itself remains necessary. PeopleCert’s account of ITIL and DevOps explicitly connects service management with engineering, operations, and feedback from production. The distinction between those responsibilities does not require a slow organizational handoff. (PeopleCert)
The handoff has a price of its own
Ronald Coase’s explanation of transaction costs included finding prices, negotiating contracts, inspecting work, and settling disputes. The choice between buying and organizing work internally depends partly on those costs. (Coase’s Nobel lecture)
I expect these costs to matter more when routine implementation gets cheaper. The hours spent specifying, estimating, clarifying, accepting, and correcting a change can become a larger share of its total cost. A faster supplier does not automatically remove the client’s queue, the commercial approval, or the knowledge lost between people.
You might get code sooner while waiting just as long for a useful change.
There is a capability cost too. If employees become skilled only at specifying and accepting changes, they may never develop the ability to direct implementation or understand its constraints. Bringing selected work inside can build that ability over successive changes. It also requires investment in technical review, documentation, and ongoing maintenance.
A failed attempt at insourcing can leave you with a more fragile service and fewer people able to fix it. The comparison has to include that possibility.
A capable supplier still earns its place
An experienced external team may use an agent better than your internal team ever will. It may know your legacy system, recognize dangerous changes, maintain a stronger test suite, and provide support coverage you cannot staff. If it already owns the operational context and works directly with users, bringing delivery inside could introduce handoffs rather than remove them.
Access to an agent does not amount to the ability to run a service.
Nor is code generation a reliable measure of delivery productivity. DORA’s March 2026 analysis of 1,110 open-ended responses from Google engineers described both faster initial work and added verification effort. Its account of the 2025 research associated greater AI adoption with higher delivery throughput and greater instability. Those findings concern development practices, not a controlled comparison of outsourcing and insourcing. (DORA)
METR’s February 2026 update reported selection and timing problems in its later developer productivity experiment, preventing a reliable estimate of current AI speedups. A procurement decision needs evidence from your own work, not a universal productivity multiplier. (METR)
A supplier that takes meaningful responsibility for engineering quality and operation has a defensible business. If you retain the context, the acceptance work, and the operational burden while the supplier mainly generates implementation, the case is much weaker.
Compare one change from request to operation
Before renewing a delivery arrangement, choose a bounded class of changes and examine four things.
Who supplies the context? Trace where the business rules, exceptions, and system knowledge come from. If your employees repeatedly reconstruct that context for the supplier, include their effort in the cost.
What capability does the supplier add? Identify the expertise, tooling, coverage, and reusable assets beyond access to a coding agent. Compare them with the full cost of establishing and maintaining an internal capability.
How much work happens around the coding? Measure elapsed time from request to a reliably operating change, alongside internal effort, review, rework, and defects. Include contract management and the cost of delays. A coding demonstration is too narrow a test.
Who can maintain the result? Check who understands the design, can diagnose a failure, and has the capacity to own the application after release. A working prototype without that capability is unfinished work.
For a low-risk application or change, try an internal service owner and engineer using an agent. Give the supplier equally direct collaboration and use the same acceptance and release standards for both. Repeat the comparison across enough similar changes to avoid mistaking an unusually easy task for a new operating model. Include setup, maintenance, and any cost of changing the supplier arrangement. Account for idle internal capacity, demand peaks, and absences; variable demand can favor a supplier.
Some services will remain better outside. Others may justify a smaller supplier role, focused on specialist review, difficult integrations, or operational coverage. Routine changes with high internal context and heavy coordination overhead are plausible candidates to bring back.
If the reason you outsourced was that coding was tedious and expensive, and your supplier now uses an agent to do much of it, you should be able to explain what still makes the arrangement worthwhile. “We have always separated service management from delivery” is no longer enough.
References
- Deloitte, Global Outsourcing Survey 2022, printed page 9.
- Cognizant, Flowsource, offering description accessed 3 October 2026.
- PeopleCert, How DevOps Complements ITIL and Enterprise Governance, accessed 3 October 2026.
- Ronald Coase, The Institutional Structure of Production, Nobel lecture, 9 December 1991.
- Jessica Baolin and Nathen Harvey, DORA, Balancing AI tensions: Moving from AI adoption to effective SDLC use, 10 March 2026.
- Joel Becker and colleagues, METR, We are Changing our Developer Productivity Experiment Design, 24 February 2026.