The Code Tsunami Has Not Landed in Production Yet

On-call duty already consumes 20 to 30 percent of a developer’s time. In legacy-heavy environments, keep-the-lights-on work eats more than half of total engineering capacity. Those numbers come from Spiros Xanthos, CEO of Resolve AI, co-creator of OpenTelemetry, and former GM of Splunk Observability, in a McKinsey interview published in June 2026. They describe the operational baseline before the AI code wave arrives. That timing detail is the part most enterprises are getting wrong.

Every AI adoption dashboard we have seen this year measures the same things: lines generated, suggestions accepted, pull requests merged, cycle time compressed. All of it is measured at code-generation time. None of it captures where the cost of that code actually accrues, which is production, weeks or months later, when the system built partly by agents starts paging humans who did not write it.

Xanthos puts the mechanism plainly: “A lot more code is being generated, and developers are often less familiar with the systems they are shipping, likely resulting in lower-quality code.” And then the sentence that should reframe every enterprise AI scorecard: “Larger enterprises have not yet seen the full effects of that tsunami of code, and they will increasingly need AI to help manage the operational complexity that comes with it.”

The invoice arrives at a different address

The unfamiliarity problem compounds the volume problem. We covered the verification side of this in the agent debt verification paradox: code that passes review can still carry defects that only surface under production load. What Xanthos adds is the arithmetic underneath. If on-call already takes 20 to 30 percent of developer time at today’s code volume, and volume multiplies while system familiarity drops, the operational fraction does not hold steady. It grows. In organizations where keep-the-lights-on work already exceeds 50 percent of capacity, the tsunami lands on a team that was underwater before the wave formed.

Smaller AI-forward companies are the leading indicator here. They generate proportionally more AI code, they felt the operational drag first, and they adopted AI operations tooling first. Large enterprises are running six to eighteen months behind on the same curve, celebrating generation-time metrics while the production bill is still in the mail. We quantified what that bill looks like when it arrives ungoverned in the operations tax of running AI at scale.

There is a queue-shaped cost hiding in the same interview. Customer-reported issues, Xanthos notes, “often sit in queues for days before someone picks them up.” Days of dead time on known problems, in organizations that measure developer productivity to the decimal. That queue is where the first governed AI deployment belongs, and it is where the interview’s most useful governance insight shows up.

Investigation authority before remediation authority

Asked where enterprises are actually adopting AI in production operations, Xanthos describes the pattern: “one of the lower-risk areas where we are already seeing a lot of interest is triaging and investigation rather than automated remediation.”

As a market observation, that is mildly interesting. As a governance design, it is the whole playbook. The enterprises moving safely are splitting production authority into two grants and sequencing them. Investigation authority comes first: the agent can read logs, correlate traces, query metrics, reconstruct timelines, and propose a root cause. Every one of those actions is read-only, reversible by definition, and auditable line by line. Remediation authority comes later, if ever: the agent can restart services, roll back deploys, mutate configuration. Those actions change production state, and a wrong one creates the next incident.

The sequence works because investigation generates its own evidence file. Every triage the agent runs can be scored against the human conclusion that follows it. After a quarter you know, with real numbers, how often the agent’s root-cause call matched the senior engineer’s. That accuracy record is the admission ticket to remediation authority, and it converts the trust decision from a debate about vendor claims into a review of your own incident history. This is the same on-the-loop supervision structure we described for agent operations oversight, applied to the incident pipeline. And before any remediation grant, the rollback question has to be settled first; we mapped where automatic rollback actually works and where it fails.

The pattern generalizes past incident response. Any autonomous system, in any function, can have its authority split the same way: rights to observe and conclude before rights to act. Most agent governance failures we see trace back to granting both at once.

Xanthos also flags a second-order effect worth planning for: application developers can now self-serve infrastructure debugging that previously required a platform specialist, which shrinks the war-room headcount an incident demands. That reshapes on-call rotations and platform team charters, and it is cheaper to redesign those deliberately than to let them erode.

The fragmentation excuse just expired

The most quietly disruptive claim in the interview comes from Xanthos arguing against his own former thesis. He spent years at Splunk Observability, where the operating model was consolidation: centralize your telemetry into one platform, then operate from it. His current position: “Instead of replacing existing systems, AI can work across fragmented environments and make better use of the tools enterprises already have.”

He runs a company that sells exactly this capability, so discount the claim accordingly. But the architectural logic holds independent of the vendor. An AI system that can query each monitoring tool where it lives does not need the multi-year platform migration that centralize-first demanded. Which removes the most common reason enterprises give for deferring governed AI operations: “our tooling is too fragmented, we need to consolidate first.” If investigation-grade AI works across the fragmentation you already have, the consolidation project stops being a prerequisite and becomes what it always was, a separate decision with its own economics.

That matters for governance timelines. Waiting was defensible when the entry cost was a platform migration. When the entry cost is an investigation-only pilot on your existing tools, waiting is a choice to keep paying the queue tax and the on-call tax at current rates while code volume rises.

Do this now

Measure your own baseline before the wave arrives. Pull the last quarter of on-call hours and keep-the-lights-on tickets, and compute the two percentages Xanthos cites for your own organization. That number is the denominator every AI coding win should be judged against.

Then write an authority ledger for production AI: two columns, investigation rights and remediation rights. Grant the first column to an agent on your worst queue, the one where customer-reported issues sit for days. Score its conclusions against human ones for a quarter. Let the accuracy record, not the vendor deck, decide when anything moves to the second column.

The organizations that will absorb the code tsunami are the ones instrumenting the shoreline now, while their adoption dashboards still look like pure good news.

---

This analysis synthesizes Resolve AI CEO Spiros Xanthos: AI’s impact on software production systems (McKinsey & Company, June 2026).

Victorino Group helps engineering organizations sequence production authority for AI systems, from investigation rights to governed remediation. Let’s talk.