Writing

AI Can Generate Code — But Only Observability Can Tell It If It Works

The runtime feedback loop behind spec-driven AI systems. Specifications describe intent. Runtime reveals reality. Observability is the bridge between those worlds.

March 10, 2026·7–8 min read·English
AI EngineeringObservabilitySpec-Driven DevelopmentWHAWITMLOpsArchitecture

For most of the history of software engineering, the process was straightforward. Engineers wrote code, compiled it, deployed it, and debugged issues when they inevitably appeared in production. Over time the system improved through iteration, but the loop always revolved around humans writing and refining the code.

Artificial intelligence is now changing that model.

With the rise of spec-driven development, the primary artifact of software engineering is no longer the implementation itself. Instead, it becomes the specification — a description of how the system should behave, how components interact, and what outcomes are expected.

Modern AI systems can take these specifications and generate significant portions of the software automatically. APIs, services, infrastructure configuration, tests, and sometimes entire architectures can emerge from a sufficiently detailed specification.

This transformation changes the role of the engineer. Developers increasingly focus on defining what the system should do, while AI systems focus on producing how the system does it. But this shift introduces an important question.

Once the system is generated and deployed, how does the AI know whether the system actually works in the real world?
01The gap

Specifications describe intent — runtime reveals reality

A specification captures the intent of a system. It defines expected behaviors, rules, constraints, and interactions between components. In many ways, a specification represents the ideal version of a system.

Production environments, however, are far from ideal.

Real systems operate under constantly changing conditions. Networks behave unpredictably. External services fail. Traffic patterns fluctuate. Latency appears in unexpected places. Concurrency introduces subtle timing issues. Users interact with systems in ways no specification fully anticipates.

The gap between intent and reality is where most software problems appear.

Historically, human engineers bridged this gap. When something failed in production, they analyzed logs, inspected metrics, followed traces, and gradually formed a mental model of what had happened.

AI-generated systems do not have intuition. They depend entirely on feedback. Without feedback from the runtime environment, an AI system can only reason about the specification itself. It has no visibility into the behavior of the system once it is deployed.

This is why observability becomes critical.

02Ground truth

Runtime telemetry is the only honest signal

Every running system continuously produces signals. Requests travel through services. Latency fluctuates. Errors occur. Resources are consumed. Distributed traces reveal the path a request follows through a complex architecture.

Together, these signals form what we call runtime telemetry. Telemetry is not a description of what the system was intended to do. It is the record of what the system actually did.

If the specification represents intent, runtime telemetry represents truth.

And truth is the only feedback an intelligent system can use to understand the consequences of its actions.

03A new role

Observability as a communication layer

Traditionally, observability tools were designed for human operators. Engineers used dashboards, logs, and alerts to diagnose production incidents. But in an AI-driven engineering environment, observability plays a much broader role. It becomes the communication layer between production systems and intelligent agents.

Through observability data, an AI agent can detect patterns that indicate abnormal behavior: a sudden increase in latency, a spike in error rates, or a service dependency behaving unpredictably. These signals provide the context necessary for the agent to reason about what might be happening inside the system.

Instead of waiting for humans to investigate incidents manually, observability allows intelligent agents to begin interpreting production behavior themselves. In this sense, observability becomes the runtime interface through which systems explain their behavior.

04The loop

The runtime feedback loop

Once AI systems have access to runtime telemetry, a powerful feedback loop emerges.

Specifications define the intended behavior of the system. AI generates the implementation from those specifications. The system is deployed into production, where real users interact with it. Observability then captures how the system behaves under real-world conditions. That information can be analyzed by intelligent agents, which can identify discrepancies between the specification and the observed runtime behavior. Those insights can then be used to refine the system. The process becomes cyclical.

Figure · The runtime feedback loop

This loop transforms production environments into continuous feedback engines. The system is no longer static after deployment. It becomes something that can be observed, interpreted, and improved continuously.

05Scale

Understanding production at scale

Modern distributed systems generate enormous volumes of telemetry. Even moderately sized platforms can produce millions of signals per minute across logs, metrics, and traces.

For humans, interpreting this data in real time is extremely difficult. The volume is too large and the relationships between signals are often subtle.

Intelligent agents, however, can analyze patterns across large datasets much more efficiently. They can correlate signals across services, detect anomalies earlier, and recognize recurring operational patterns.

For this to work effectively, observability platforms must do more than collect telemetry. They must provide structured insight into runtime behavior, enabling agents to interpret the system rather than simply record its activity.

06The platform

The role of WHAWIT

WHAWIT approaches observability from the perspective of AI-native systems. Instead of treating observability as a passive monitoring tool, the platform treats runtime telemetry as an essential input for intelligent agents.

The objective is not simply to collect logs and metrics, but to transform runtime signals into information that can be interpreted by both humans and AI systems. When anomalies appear, the platform can correlate signals across services, identify behavioral patterns, and help explain what is happening inside the system.

This enables a new operational model. Rather than relying entirely on human investigation, AI agents can begin to analyze runtime behavior directly, identifying issues and suggesting improvements based on real production data.

Observability becomes the system's sensory layer, allowing intelligent agents to perceive what is happening in the environment they help create.

07Closing

The future of AI-native engineering

As AI continues to generate larger portions of modern software systems, observability will become one of the most important components of the engineering stack.

Without runtime visibility, AI-generated systems remain static artifacts. They can produce implementations, but they cannot understand whether those implementations behave correctly in real environments. With observability, systems gain the feedback necessary to evolve.

Specifications define what we want.
AI produces how we attempt to achieve it.
But only runtime behavior tells us whether the system actually works.

Observability is the bridge between those worlds. And in the emerging era of AI-native engineering, that bridge may become the most critical component of all.

José Escrich

Fractional CTO and software architect. Built in Bariloche, Patagonia — working with teams worldwide.

© 2020–2026 José Escrich. All rights reserved.
Designed & built by @jes