AI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous

AI can now generate substantial production code, but Jad Naous argues that writing software and operating it are different problems. Production systems face unpredictable workloads, failures, hidden state, and interactions among teams, leaving an enormous range of possible conditions. Martin Casado and Naous consider whether AI can move beyond interpreting alerts to detect changes, form hypotheses, and test causes in the live environment; neither treats AI as ready to manage distributed systems autonomously.

For Naous, the central challenge is making operational complexity understandable to AI, not simply collecting more telemetry. Data may omit context, and the system’s state can be hard to bound. An AI troubleshooter would need to narrow that state space, run experiments, and test possible causal explanations against actual behavior. Rare, exception-driven failures are difficult to learn from past examples, while choices that are safe in familiar conditions may behave unpredictably when loads or system states change. Security could be harder still because adversaries deliberately seek unusual states.

Naous says engineering leaders were concerned in 2023 about infrastructure and observability costs. He estimates companies spent roughly 5% to 20% of infrastructure spending on observability, often treating that spend as a proxy for reliability, even as costs rose faster than the functions delivered and added spending yielded diminishing reliability returns. Grepr processes telemetry in the data stream, looking for environmental changes and novel log patterns rather than starting with an alert and tracing backward. Naous says it scans petabytes of customer logs per day; after internal use and trials in a couple of customer environments, he said results were promising. He also described a couple of cases in which previously ignored alerts later became production incidents. In customer conversations, reducing Datadog bills drew more interest than the AI pitch, while the value of operations AI remains harder to price: it could improve SRE productivity or prevent costly incidents, but is still early.

Naous says AI has increased the leverage of strong engineers, but his estimate is limited to Grepr’s 10-person team: he sees the gap between okay and really good engineers widening by 10 times. In his view, AI makes good engineers better rather than turning weaker engineers into strong ones; engineers still need to understand distributed systems and query semantics to direct the models. He typically runs three or four command-line agent sessions in parallel, assigning implementation to one and review of pull requests or design documents to another. He checks requirements, algorithms, task divisions, and dependencies before splitting work, then reunites changes for human review, with more attention now going to tests and whether behavior matches expectations.

A production data-lake feature that Naous calls auto-promotion, or shredding, illustrates the coding gains: it turns fields in semi-structured log events into independently filterable columns to improve data layout and query speed. His team shipped it in about 10 days, compared with his estimate that one person would previously have needed about six months, a roughly 10-to-20-times development speedup. AI-generated SQL also improved when grounded in query examples and performance benchmarks, and the model found optimization opportunities in inefficient code. But it could not choose the right memory allocation; that required experiments in production. The example captures the episode’s distinction: models can help build complex software and may be nearing human-level query optimization, while deciding how a running system will behave still requires evidence from that system.

The speakers expect faster AI progress in constrained domains with patterns resembling training data, and slower progress where outcomes depend on the natural world or unusual conditions. They suggest that AI may learn an operational diagnostic process without having encountered every specific failure, but leave open whether models can reliably bridge instructions and real-world system behavior. Some problems may require simulation or generated code to explore outcomes that cannot be predicted directly. The economic value of AI, they argue, will depend less on demonstrations than on which applications work reliably in practice.