We just surveyed 300 frontend and mobile engineers across 16 countries, and the finding that keeps sticking with me isn't the one about AI. It's this: 74% of engineering teams rate themselves in the "middle" of the observability maturity scale. Not reactive, not strategic. Stuck in the middle. They have dashboards, they have tracing, they have alerts. And yet when something goes wrong, they still can't tell you why.
That gap, between detecting a problem and explaining it, is the most expensive problem in frontend engineering right now. Most teams have just learned to live with it. As AI hype swirls around them and writing code becomes easier than ever, they're frozen when it comes to making observability and reliability easier for themselves. So let's talk about why.
Why Detecting Problems Isn't the Same as Understanding Them
There's a version of observability that's become table stakes: crash reporting, some performance tracing, a dashboard or two. You probably have this. It tells you when something broke. But it doesn't tell you what broke, why it broke, who was affected, or whether it actually mattered to your business.
That last part is where things get interesting. In e-commerce and media, which together represent over half of survey respondents, frontend performance isn't a technical metric. It's a revenue metric:
- A slow checkout flow
- An image that takes too long to load because someone changed a CDN configuration
- An API response that starts returning 400s because of a change upstream
Those aren't abstract engineering problems. They're abandoned carts and users who leave and don't come back. They're brand perception eroding one frustrating session at a time.
Your legacy observability tools will tell you your error rate went up. What they won't tell you is that the users who hit that error were in the middle of a purchase, that they were on a specific carrier and device combination, and that 40% of them uninstalled the app within 48 hours. That's the gap. And it's not a small one.
Why Engineers Aren't Using AI for Observability Yet
Here's the part that genuinely surprised me in the survey data.
89% of respondents actively use AI in their engineering workflows. 52% use it every single day for tasks like code generation, debugging, and test creation. It's become part of how engineers work.
Only 8% use AI for observability.
That's not an indictment of AI. It's a clear signal about where the tooling has and hasn't shown up. 29% of respondents aren't even aware that AI can be applied to observability tasks. This isn't resistance; it's a discovery problem. Engineers are pragmatic, and they adopt tools that make their jobs easier. AI for coding cleared that bar. AI for observability hasn't been productized and distributed in a way that lets most teams find it, try it, and trust it.
And trust is the real variable here. When asked what it would take to increase AI adoption in observability, the answers weren't about capability. They were about confidence: verifiable outputs (69%), transparency in how it works (66%), and human-in-the-loop workflows (57%).
Engineers aren't anti-AI. But they're very much anti-black-box, especially when the stakes are high. If your system is down and an AI tool gives you a confidently wrong root cause, you've made things worse. One survey respondent described this as "confident incorrectness." After all, AI can easily lead engineering teams down deep rabbit holes, especially when investigations span complex systems.
Why Mobile Teams Have the Biggest Observability Gap
One finding that deserves more attention is that mobile teams are significantly behind web teams on observability maturity, and the diagnostic problem they face is objectively harder. Mobile just has more complexity to contend with, including:
- Device fragmentation
- OS versions
- App versions
- Network conditions
An issue that's intermittent on one carrier on one device on one app version looks completely different from the same issue on a different combination. To make matters worse, 26% of mobile teams still rely on basic monitoring. They're trying to investigate issues without the context to reliably do it.
It's telling that 79% of mobile engineers want AI for root cause analysis, which is the highest demand of any segment in the survey. The teams who need it most are furthest from having it.
Why You Can't AI Your Way Out of Bad Observability
AI is not going to fix observability on its own. Only 8% of surveyed teams are actively using AI for observability, and they all share a high-level of observability maturity. If you don't have end-to-end visibility from user experience to backend root cause, there's nothing for the AI to reason over.
But the inverse is also true. Better observability without AI is leaving real capability on the table. The three tasks engineers most want AI help with are pattern and anomaly detection, regression detection across releases, and root cause analysis. These are exactly the tasks that scale poorly with manual investigation. As your systems get more complex and release velocity increases, you'll need automation to streamline issue discovery, prioritization, and resolution.
This is also why the emerging MCP server pattern is interesting but not sufficient on its own. Connecting an AI model directly to your observability data sounds powerful, but just dumping raw telemetry into Claude won't get you very far.
What an AI model actually needs is context. It needs correlated signals across frontend and backend, not just metrics. Instead, it needs the story those metrics are telling, such as recommendations grounded in what actually changed and what users actually experienced. If a user hits a slow network request that triggers a cascade of failures that ends in a forced app close, you need the full thread:
- What task was the user trying to complete?
- How did this request move through your backend system?
- Which services introduced latency or failures that contributed to downstream issues?
- How was the actual user experience affected?
- What was the business outcome of this issue?
Your AI model needs the full picture before it can effectively reason about the root cause. If you provide it with a stream of raw data, you run the risk of long, dark, expensive investigations that don't produce much explanatory power. If you instead give it structured, correlated, and meaningful signals, you can act on reliable, verifiable outputs.
The teams that will pull ahead over the next two to three years are the ones that treat AI and observability as the same problem. These are not two separate initiatives. They’re one connected practice: knowing what's happening, understanding why, and being able to act on it faster than your competition.
The data is telling you where the opportunity is. The question is whether you'll move toward it before the cost of not knowing becomes impossible to ignore.
To see the full survey data referenced in this post, read The AI and observability gap for frontend teams. If you'd like to see how your frontend observability maturity stacks up against hundreds of engineering teams, take this quick self-assessment.
