Tuesday, September 15, 2026 AboutContact
Tech

Fewer Than One in Ten Enterprise Applications Is Fully Observable, and Agents Are Now Writing the Code

Missing visibility used to slow human teams down, but agents now deploy at machine speed into estates that nobody can fully see, which turns a cost problem into a control problem.

By Megan Alcott· September 11, 2026· 3 min read
Fewer Than One in Ten Enterprise Applications Is Fully Observable, and Agents Are Now Writing the Code
Photo Courtesy: Getty Images · source

Fewer than one in ten enterprise applications is fully observable today, according to a January 2026 report from Neurones IT Asia. A SolarWinds survey in March found that 77 per cent of IT teams lacked full visibility across hybrid environments.

Those numbers were already uncomfortable. Bernd Greifeneder, founder and chief technology officer of Dynatrace, argues that the arrival of agentic software delivery converts them into a different category of problem.

When development was primarily human-driven, missing context slowed teams down and raised operating costs. The people making changes were at least moving at human speed, and could be stopped.

Two speeds at once

Most enterprises are currently running both models simultaneously, and it is worth separating them.

In the first, AI augments existing workflows, helping engineers work faster. That remains the dominant pattern.

In the second, increasingly capable agents take on larger portions of software delivery and operations, while the humans concentrate on goals, specifications and constraints.

The shift produces a consequence that is easy to miss. As agents take over the writing, intellectual property migrates. It stops living in the codebase and starts living in the specification, because the code itself becomes a generated output.

That is a substantial change in what an engineering organisation actually owns.

They make decisions at machine speed without understanding the downstream effects

What agents cannot see

The gap Greifeneder identifies is specific, and it is not about capability.

Agents can write, deploy and optimise software faster than any human team. What they have no awareness of is what happens once that software is running in production.

They cannot see whether a change they made caused a slowdown, triggered an error cascade, or crossed a compliance boundary. They make decisions at machine speed without understanding the downstream effects of those decisions.

Set that against the observability figures and the shape of the risk becomes clear. In an estate where nine in ten applications are not fully observable, a human deploying a change is working partly blind. An agent deploying continuously into the same estate is working entirely blind, and doing it far more often.

The migration of the crown jewels

The point about specifications deserves more attention than it usually gets.

If the code is a generated artefact, then the durable asset is the specification that produced it: the goals, the constraints, the definitions of acceptable behaviour. That is where the institutional knowledge now sits, and most organisations have no discipline around treating it that way.

Codebases are versioned, reviewed, tested and access-controlled. Specifications, in most companies, are a document somebody wrote.

The practical implication is that the governance effort has to move with the asset. Reviewing generated code line by line becomes both impossible and beside the point once volume rises, because the error will almost always trace back to an ambiguous or incomplete instruction rather than to a mistake in translation. Organisations that keep auditing the output while leaving the specification unversioned are inspecting the wrong artefact.

How to get there without breaking things

Greifeneder's recommended path is deliberately unambitious, and the reasoning is sound.

For most enterprises the question is not whether the shift happens, but how to introduce it while managing risk, compliance and existing operational dependencies. The transition does not arrive everywhere at once.

So start with innovation teams and lower-risk applications. Prove the model there. Build institutional confidence on work where a failure is survivable, and let that trust expand into business-critical workloads over time.

That is the same sequencing any competent organisation would apply to a new deployment process. The difference is the urgency of the prerequisite. Before agents are allowed to operate at machine speed in production, somebody has to be able to see production.

On the current figures, most enterprises cannot.