Why AI Can Write Code But Can’t Keep It Running (Yet)
Grepr CEO Jad Naous talks with a16z's Martin Casado about how coding agents have changed a 10-person engineering team, with projects that once took six months now finishing in about ten days. They examine whether AI can reason about and troubleshoot production distributed systems, why operations is a harder problem than code generation, and where AI adoption is likely to go next.
AI, Coding Agents, and the Hard Problem of Operating Production Systems
Jad Naous, CEO of Grepr, makes a case that writing production code with AI is a very different problem from running the systems that code produces. Code lives in a space that models have seen extensively, but operational behavior depends on workloads, access patterns, configuration, and failures that rarely appear in training data, which means the path from generating software to operating it is considerably longer.
From Autocomplete to Multi-Agent Engineering
Jad recalls that AI coding began as autocomplete, with tools like Copilot filling in test scaffolding. That changed quickly. On his 10-person team, the gap between engineers who adapt their workflow to AI and those who do not is widening. Strong engineers learn how a given model and harness manage context, when to spin up sub-agents, and how to phrase requests, and this compounds their existing advantage rather than lifting weaker engineers to the same level. He argues that the leverage goes to people who already understand the complexity of their systems, since the human still has to decompose the work and hold the whole design in their head.
His current workflow centers on command-line sub-agents that maintain persistent sessions, which he finds more context-efficient than in-process sub-agents. He typically runs three or four sessions at once, since more than that causes him to lose track of the threads. Agents review each other’s pull requests, and the human reviews a design document and product spec before implementation begins. Parallelizable pieces get handed to additional agents, but everything still has to be reassembled into one stack that a person can reason through, because otherwise the work becomes unmanageable.
The concrete example is auto-promotion, or shredding, in a data lake: turning semi-structured log fields into independently filterable columns in Parquet and Iceberg. Work that he estimates would have taken a single engineer about six months now takes around ten days. He is explicit that this is production code, not a demo, and that the speedup is roughly a factor of 10 to 20.
Why Distributed Systems Resist Generated Code
The harder question is whether a model can reason about behavior once code is running. Correctness, availability, and performance in distributed systems are trade-offs that depend on the environment: a lock sacrifices availability, eventual consistency sacrifices read freshness, caching trades memory for latency, and none of these choices is visible in the syntax. Jad distinguishes syntax, the text a developer writes, from semantics, what the machine actually does at runtime, and argues that much of what matters in operations lives in the second category.
His experience with query optimization is more encouraging. When the model is grounded in explicit performance benchmarks and real user query data, it can form hypotheses, identify redundant conjuncts, and iterate toward better plans. It falls down when asked how much memory a system needs, because that answer has to come from experiments run against production. The practical pattern he sees is that models do well when they recognize their own uncertainty and design an experiment to resolve it.
Detecting Change Instead of Backtracking Causes
Grepr’s approach to AI-driven troubleshooting inverts the usual root-cause workflow. Many AI SRE tools begin with a lagging indicator, such as a spiking metric or an alert, and then try to backtrack through a complex system to find the cause, which Jad considers problematic. Grepr instead starts from the assumption that a system was working before and looks for what changed: large-scale clustering over logs to find new patterns and early warnings like exhausted connection pools or exceeded memory. A predictive component flags out-of-norm patterns across petabytes of daily logs, and only those signals are lifted to the AI, which then generates and tests causal hypotheses against the code and past behavior. Jad says this has been effective internally and at customer sites, where ignored warnings turned into production incidents.
He distinguishes this from using generative models as predictors. The language model’s role is to reason about what a deterministic or statistical signal means and what to check next, not to forecast the future.
The Case for Operations as a Harder Domain
Jad notes that every added line of code multiplies the possible operational states, so the space quickly exceeds anything that could be enumerated. He argues this is why chaos engineering and similar product approaches never fully worked, and why human operators, with their runbooks and tacit knowledge, have been the real mechanism for managing clusters. He is optimistic that AI can take over the steps a human debugger performs, such as forming causal chains and verifying them against observed data, even if it cannot exhaustively model the state space. The bet is that the reasoning procedure is constrained even when the outcomes are heavy-tailed.
Martin Casado pushes back with the historical observation that systems engineering has repeatedly favored overprovisioning over smart prediction, from RAM to routing, and that operations involve exceptions, sparse data, and humans holding knowledge in distributed ways. Security is harder still, because an adversary actively searches for rare states. Jad responds that the realistic path is to reduce the search by having models propose causal chains and check them, with simulation or code generation filling in the parts that cannot be inferred directly.
Where AI Goes Next
The broader question is which domains will adopt AI quickly. Jad’s view is that AI spreads rapidly where the solution distribution matches the training distribution, as with code, syntax, and generated images. Problems grounded in the physical or adversarial world are slower, and the economics are harder. Self-driving is his reference point: a DARPA Grand Challenge win that looked imminent took roughly twenty years and substantial investment to reach economics below those of ride-hailing. He also notes that customers buying AI-driven reliability often want the cost savings first, which suggests the operational value needs to be expressed in dollars before it sells.