The Post-Vibe Problem

Modern-day software reliability is starting to take a massive hit. It is not because failures are inherently more frequent, but because the rate of change in systems is outpacing our ability to understand them.

For years, the focus in software engineering was speed. Shipping was slow, deployments were risky, and feedback loops were long. The industry responded by optimizing for throughput. As a result, CI/CD improved, observability matured, and more recently, AI-assisted development has pushed this even further. The 2025 DORA report shows that as AI adoption increases, deployment frequency rises measurably. Teams are able to ship more changes, more often, with less friction.

All this speed comes with a tradeoff. For every 25% increase in AI adoption, change failure rate increases by 7.2%, meaning that at full adoption, systems can become roughly 28.8% more unstable (DORA 2025). At the same time, around 30% of developers report little to no trust in AI-generated code (DORA 2025). Vibe coding has created a much deeper issue. We are increasing the rate of change faster than we are increasing our ability to reason about those changes. This gap becomes visible during incidents.

MTTR (Mean Time to Resolution) is still the primary metric used to evaluate reliability. It covers the full lifecycle of an incident: detection, triage, coordination, investigation, and repair (incident.io). But MTTR compresses very different types of work into a single number. In practice, incident durations are uneven. Many resolve quickly, but a smaller set stretches into 45–60+ minutes and dominates operational cost (Faros AI). These longer incidents are rarely caused by coordination issues. They occur when engineers cannot quickly determine what changed and how that change caused the observed failure.

This becomes clearer when you break down a typical incident. In a 60-minute incident without AI, about 10–15 minutes go to coordination (paging people and gathering context), and 25–35 minutes go to debugging. The actual fix often takes less than 5–10 minutes. Most of the time is spent understanding the system.

AI tools have meaningfully improved the coordination layer. That initial 10–15 minutes can drop to 3–5 minutes through automation and better context (Rootly). But the debugging phase largely remains unchanged. Teams still spend 20–30 minutes figuring out what broke. So while MTTR improves, its overall shape does not fundamentally change. The real bottleneck is not coordination; it is reasoning.

At the same time, the nature of that reasoning is becoming more difficult. In an AI-assisted development environment, engineers are increasingly working with code that they did not fully author or deeply understand. This is reflected in DORA signals like deployment rework rate, where teams spend more time correcting their own changes. Systems are not just changing faster—they are becoming harder to reason about. Each change introduces more uncertainty into how components interact, making the debugging phase longer and more complex, not shorter.

The tooling ecosystem has responded by optimizing everything around the operational friction of incident response. Platforms like Rootly report 20–40% reductions in MTTR by improving alerting, triage, and coordination. These improvements are real. They reduce the time it takes to assemble context and bring the right people together. But they have a lower bound. They do not significantly reduce the time it takes to understand why the system failed.

This is why MTTR improvements tend to plateau. Once coordination overhead is removed, the remaining bottleneck is reasoning. Engineers still need to identify what changed, trace how that change propagated through the system, and determine why it failed. That process remains largely manual, and it becomes more difficult as systems grow in complexity and rate of change.

The result is a structural imbalance. Throughput is increasing. Failure rates are increasing. But our ability to explain failures has not kept up. We can ship faster than we can understand. That is the reasoning gap.

Closing this gap requires a shift. The industry has largely solved observability—collecting signals about what is happening. What's missing is interpretation. Not more data, but a way to connect changes to effects, and effects to root causes in a structured and reliable way.

This is what we are building toward. If the bottleneck is reasoning, then systems need structure to reason over. Today's tools surface signals (logs, metrics, traces), but leave the hardest step to humans: connecting them. We make that connection explicit. We model incidents as graphs that link changes, services, and symptoms into a causal structure.

Under the hood, this is not a single flat graph. It is a layered world model where different types of system information are represented separately and then composed for reasoning. One layer captures system structure (service dependencies and request paths). Another captures change over time (deploys, versions, code changes). A third captures observed behavior (errors, latency, traffic anomalies). These layers remain typed and time-aware, and are connected through shared entities with associated confidence.

This separation allows reasoning across imperfect signals without relying on any single source of truth. Instead of a static global graph, we construct an incident-scoped world model by combining only the relevant parts of each layer. This makes it possible to trace from change to symptom, evaluate causal paths, and narrow down likely explanations in a structured way.

If we can make systems easier to reason about under failure, we can begin to close the gap between how fast we build and how well we understand.