Will SaaS application vendors be disrupted by, and replaced by code that customers build for themselves with vibe coding tools? An analysis of whether or not the SaaS Apocalypse will strike the Observability market follows:
There are many types of Saas Applications software vendors with many different characteristics. Observability software is supposed to help customers understand the performance and reliability of their important applications, identify problems in the performance and reliability of those applications, and help solve those problems. Observability vendors have the following characteristics that make replacing their software with something vibe coded by a customer problematic:
Observability Data is Hard and not Generally Available
In order to solve the Observability problem you need data about the behavior of the application and the entire software and hardware infrastructure supporting the application. That data is very real time (it changes constantly) so it is not a part of the training set of LLM’s. Infrastructure data (for example data about the behavior of the cloud where the application runs) is easily available through cloud API’s (like CloudWatch) and more recently MCP servers from the cloud vendors. The major Observability vendors like Datadog and Dynatrace also make their data sets available via MCP servers.
Data about the behavior of applications is much harder. You either need to install an agent into the application like the ones from Datadog and Dynatrace, instrument the application with OpenTelemetry, or install an OpenTelemetry compatible agent like the one from Odigos. But this is hard to do in a consistent manner across all of your applications and there is considerable effort and cost involved in application instrumentation.
Data about applications also invariably involves compliance and security issues. Data about end user financial transactions is subject to PCI and health data is subject to HIPAA. Asking a customer to maintain compliance in these and other aspects of security in their own Observability solution themselves is probably a bridge too far.
Therefore, vibe coding your own Observability solution requires gathering and understanding a bunch of disparate data across your application set. Not an easy thing to do.
Analyzing Observability Data is Hard – Really Hard
No Observability vendor has to date successfully automated the problem detection –> root cause analysis –> problem remediation –> fix verification process. That is because it is really hard to accurately identify problems (with no false alarms or missed alarms) and then identify and implement the rest of the Observability process. If the vendors have not solved this problem after 30 years of trying it is safe to say that a person at a customer with a vibe coding tool is not going to understand how to analyze this data and solve this problem either. So it is not likely that this person will be able to vibe code up their own Observability solution.
The Back End of Observability is Hard – Really Hard
Observability vendors have invested huge amounts of time, effort and money into their back ends (Grail from Dynatrace, Husky and Toto from Datadog) precisely because you cannot just take an open source database and throw your metrics, logs, traces and dependencies for every application into it and expect it to work well at scale. While it is true that lots of applications are monitored by Open Telemetry and that data is pointed a various open source databases, the combination of Open Telemetry and an open source database does not begin to actually solve the Observability problem (the problem articulated directly above).
The Observability Problem Changes Constantly
There are two ways to look at this. The first is how often does a SaaS Observability vendor update the software that they are running for their customers? The answer is multiple times a day. The second is to look at the history of changes in how applications are built and run and how frequently those changes are likely in the future. Those changes include Java, other languages, the cloud, N-Tier architectures, micro-service architectures, LLM functionality in applications, MCP servers, Open Claw and vibe coded applications and agents. Each of these changes has required and is requiring significant changes to Observability products and solutions. In other words Observability is not a problem that gets solved once. It is a constantly metastasizing problem that needs to be solved over and over again with different approaches (and different software) each time. Customers are unlikely to choose to commit the resources to keeping their home grown Observability solutions current across their range of applications especially when the pace of innovation is a high as it is right now.
Agents Represent a Really Difficult Observability Challenge
Since its inception the Monitoring and Observability industries have basically focused upon the experience of the human beings using the application software being monitored. Those applications did a fixed and known set of things and those things were monitored by Observability for performance and reliability. Now we are about to put AI based Agents into production. Those agents are pieces of software that do useful work for us on their own. And because the AI that the Agents are based upon is in an LLM and the LLM is stochastic (statistical) in nature, it is uncertain whether those agents are going to do the right thing every time (they will hallucinate). The problem of detecting whether agents are doing the right thing or not is likely to fall into the lap of the Observability vendors and it again something that most customers will not want to build for themselves.
The Observability Problem is About to Dramatically Expand in Scope
The most important impact of vibe coding is that it will accelerate the rate at which customers can implement business functionality in software. Think of this as a dramatic acceleration in digital transformation, a dramatic acceleration in the pace of change (updates) in those applications, and the fastest growth ever in the number of applications in production that need to be monitored with Observability. Most customers would rather focus upon using vibe coding to drive revenue and market share instead of using it to monitor their applications.
Testing Your Observability Solution is Time Consuming and Expensive
Everyone knows that implementing the application instrumentation part of Observability is hard. It is hard because you have to test the Observability agents against every language that you have in production and against every instance of where that language is implemented in an application. You also have to test against how applications use the software infrastructure that they rely upon. All of this to make sure that the Observability approach is not creating performance and reliability problems. If it is, then you have the vendor to turn to to help you address those issues. Taking on this entire compatibility, performance and reliability problem themselves is just too much for most customers.
Operating an Observability Solution at Scale is Hard and Expensive
There is no getting around the fact that an Observability solution produces a huge amount of data for every application and transaction that is monitored. That amount of data is only going to increase as agents get put into production and need to be monitored. That data needs to be related at ingest time (Dynatrace SmartScape) and needs to be stored over time so that relevant anomaly detection can occur. Again, most customers would rather pay the Observability vendor to do this for them and use their own people to drive business results in their software efforts.
Summary
While it may be possible for customers to vibe code solutions for some of the problems currently solved by their Saas vendors, the data, the analysis of that data, the problem set and the pace of change all argue against the replacement of SaaS delivered Observability solutions by home grown vibe coded solutions.
