a16z Podcast

Jad Naous on why AI solved code but not operations

Jad Naous· CEO at Grepr
·~59 min·English·a16z
AgentsAI InfrastructureBusiness Strategy
TL;DR

Grepr CEO Jad Naous argues AI conquered coding because code lives in the same distribution it was trained on, while operating real production systems stays hard — so his bet is to hand the AI a deterministic signal that something changed and let it run a bounded debugging playbook instead of asking it to predict the chaos.

01Core Mental Model

Two Worlds: The Digital and the Actual

AI is fluent in the digital world it was trained on, but the actual world of running systems is a different distribution — and the two are often not the same.

The world that the AI lives in is all digital and there's the actual world and like those things are not necessarily the same.

— Jad Naous, a16z Podcast
Key Insight
Naous reframes the AI-capability debate as a data-distribution question rather than an intelligence one: what matters is less how smart the model is than whether a problem's answers resemble its training data. That lens quietly predicts where AI stalls next — anywhere the solution lives in the messy physical or operational world rather than in text or code.
02How AI Changes Dev

AI Widened the Engineer Gap

AI did not level the playing field — Naous says the gap between okay and really good engineers multiplied about 10x as his team grew.

really good engineers are able to somehow put it into their workflows in a way where they the AI starts training them.

— Jad Naous, a16z Podcast
Key Insight
The surprising inversion is who teaches whom — Naous describes the AI training the engineer, not the reverse. The bottleneck is the human's capacity to hold system complexity and break it into tasks the model can execute, so AI amplifies that skill instead of substituting for it.
03The Gain Is Real

Six Months to Ten Days, Solo

A production data-lake feature that would have taken about six months before took Naous roughly ten days working alone — a 10x to 20x jump on real shipping code.

that took maybe about 10 days. In previous days that would have taken maybe about 6 months.

— Jad Naous, a16z Podcast
Key Insight
Naous is careful that this is production infrastructure — auto-promotion and column shredding inside a data lake — not a demo, which is what makes the number load-bearing. The gain is concentrated in code, the one domain where the solution space matches the training data, setting up the contrast with everything that follows.
04The Hard Part

Code Describes; Running Is Reality

Operations resists AI because code is only a description of a system, while the running system explores a state space that effectively has no bound.

I think that code is a reduction of all the operational states of a of a machine into like the instructions that make it run.

— Jad Naous, a16z Podcast
Key Insight
The framing the interviewer presses — and Naous agrees with — is that operations is heavy-tailed: every added bit of state roughly doubles the possible behaviors, so a system reaches more states than there are atoms in the universe, dominated by rare exceptions. Naous's own sharpening is that code is only a reduction of those operational states into instructions, so a model trained on common cases has little to learn from a long tail that almost never repeats.
05The Approach

Detect What Changed, Don't Backtrack

Instead of tracing an alert backward to a root cause, Grepr detects when something new appears in the data and hands that signal to the AI to investigate.

backtracking into a root cause is actually very problematic. And so instead, what we're doing is doing it the other way around, which is can we actually start by figuring out if there's something different in your environment that has changed?

— Jad Naous, a16z Podcast
Key Insight
The architecture splits the labor by what each part is good at: a deterministic model finds the needle — a never-before-seen pattern in a petabyte of daily logs — because spotting out-of-norm things is what statistical detectors do well, and only then does the generative model reason about cause. It sidesteps asking the LLM to predict, which Naous agrees it is not good at.
06Why It's Tractable

Infinite States, Finite Playbook

The set of things that can break is effectively infinite, but the set of steps used to debug them is small and learnable — so the AI runs the workflow a human would.

So the goal isn't to like have the model just be like this is what happens. It's hey run through this workflow to determine what happened.

— Jad Naous, a16z Podcast
Key Insight
This resolves the apparent contradiction in the interview: operations looks unlearnable because the failure space is astronomical, but the response space is not. Naous bets the tractable object is the diagnostic procedure, not the failure — which, as the conversation notes, is why earlier attempts to enumerate failures (chaos engineering) stalled while experienced humans navigated incidents with a handful of moves.
07Go To Market

The Legible Value Wins the Sale

The part of Grepr that sells itself is the plain number — a 90% cut to the observability bill — not the harder-to-price promise of AI-driven reliability.

you put us in the data stream, plug and play, pass the data through, reduce your cost by 90%.

— Jad Naous, a16z Podcast
Key Insight
Naous tells it as a sales story: when Grepr led with AI-driven reliability, customers interrupted to buy the cost cut instead. Engineering productivity and a line-item saving are easy to put a dollar on, while the value of an incident you prevented is not — so even a working AI capability sells best when it is attached to a number the buyer already tracks.