Jad Naous

1. Key Themes

Observability spend is a proxy purchase for reliability, and the proxy has stopped working

Jad's founding insight is that companies were never really buying observability. They were buying reliability, and the economics of that purchase broke as architectures shifted to microservices. He describes it: "they were putting money into observability as a proxy for reliability, and for the longest time, the more money you spend, the more reliability you got out." 00:08:16 The curve then flattened: "the cost of observability was actually starting to grow faster than the units of function that you're outputting. And the marginal rate of... increase in reliability for every additional dollar you were spending on observability was just flattening out." 00:08:16 Buyers still wanted to spend: "people were still willing to pay 5 to 20% on reliability." 00:08:54 The opening is to extract signal upstream, collapse the cost, and monetize the reliability layer on top.

Being in the data stream is a strategic position for the AI wave

Grepr sits in the telemetry pipeline, so it gets first access to everything operational. Jad's logic: "if we are in the data stream, and we're extracting the signal, then we are in a strategic position to feed that to whatever is going to come in the future because that's going to be necessary." 00:09:50 The product is a wedge from cost savings (a plug-and-play 90% reduction) into an AI troubleshooting layer: "now we're building out that second layer where we're feeding those signals into the AI layer that's now going in, troubleshooting, figuring out when things are going wrong, going wrong and fixing them." 00:10:05

AI coding is delivering 10-20x gains on production code, with a 10-person team

Jad is concrete about gains. His latest feature, auto-promotion (shredding) in a data lake, "took maybe about 10 days. In previous days, that would have taken maybe about 6 months for a single person." 00:24:19 Martin summarizes: "factor of 10, factor of 20 improvement... For production code, for new products." 00:24:54 Jad's stack is Claude Code with Opus 5.5 on Windows via WSL, running "three or four session windows at the same time." 00:21:38 He ships "these massive, 20-PR things that I just dump on my team to go and review." 00:20:21

The AI multiplies the spread between good and average engineers

Jad's observation about hiring and team composition: "as we started hiring more people into the team, that disparity between, you know, okay engineers and really good engineers just multiplied 10x." 00:13:28 Good engineers got better rather than weak ones catching up. The mechanism is complexity management: "the more complexity that your brain can handle, the more you can break down the tasks and kind of assign them." 00:13:57 He also notes the AI trains the human: "really good engineers are able to somehow put it into their workflows in a way where they, the AI starts training them. In terms of like how to talk to it, how to get the best out of it." 00:11:36

The review bottleneck is shifting from reading code to verifying behavior through tests

With PRs flying around, review practice has changed. Jad says "the thing that has changed a lot in the review cycle, is that we started much more focused on... the tests. And like, doing things like golden expectations, and like, are they shifting." 00:20:53 His workflow uses a PRD, a design doc, and an AI "tech lead reviewer" agent. He still insists on a human pass: "you have to kind of put it all back in one stack and be able to go through it as a human one by one, because otherwise, it just gets messy and bushy." 00:22:57

Operations is harder than code because the state space is vast and the knowledge is distributed

Martin frames the core worry: models are "distribution in, distribution out," code is a manageable manifold, but operations "feels to me more like kind of like the universe. Heavy-tailed and exception-based, and power laws." 00:37:53 Jad agrees it is harder: it involves "external loads that are random," unannounced rollouts, hidden states that cause deadlocks, and "it also because it involves humans a lot more... all the pools of knowledge are distributed too." 00:46:01 Martin adds the data problem: "Where is even the data to learn how to like build a system that understands like all of the operations?" 00:00:19

The path to AI ops: deterministic change detection, then hypothesis-driven experiments

Jad's answer is to stop asking the model to predict and instead have it run a debugging workflow. A separate non-generative system flags novelty: "For every time we see a new kind of pattern emerge in your logs, a new thing that we haven't seen before, we lift it up to the AI." 00:36:06 The AI then reasons: "Let me actually look at the code and figure out where it comes from... Let me see if it's actually happened before." 00:36:31 The reframe: the universe of failures is heavy-tailed, but "the set of steps used to debug it is a manageable thing." 00:40:39 Martin ties it to why chaos engineering failed: humans did the state-space reduction through debugging steps, and now the AI can take that role.

Domains where the solution space matches the training distribution will go like wildfire; the physical world will be slower

Martin's thesis: "AI's going to continue to take off in a wildfire for a constrained domain where the solution space is... the same as the distribution of the training set." 00:53:50 Real-world domains are slower and bound by economics: self-driving "took 20 years and $170 billion of investment to get to worse unit economics than Uber." 00:53:50 His framing of AI is "a universal function approximator" with "economic equilibrium" deciding what works. Jad's counter-lens: we often change the world to fit AI, as with the fully automated data warehouse in robotics.

Buyers purchase the pain they can already quantify, not the AI narrative

A go-to-market lesson from Jad: when pitching customers on AI reliability, "They're like, 'Wait, wait, wait, wait, wait. Roll back. You said you can save 90% of our Datadog bills?' And I'm like, 'That's what I want to buy.'" 00:57:25 Coding wins because productivity is a visible line item; ops value is harder to put a dollar figure on and pay for at the door.

2. Contrarian Perspectives

The best engineers pull further ahead with AI, rather than AI flattening skill differences

The common narrative is that AI democratizes engineering. Jad's field experience says the opposite: "that disparity between, you know, okay engineers and really good engineers just multiplied 10x." 00:13:28 When Martin pressed on whether bad engineers became good, Jad answered flatly: "No. No. No." 00:13:56 His reasoning is that for distributed systems and distributed algorithms, "your brain has to handle the complexity, because like AI doesn't do it." 00:14:33 He caveats that his team is small, but it implies senior architectural talent is the scarce asset and its value rises.

Don't trust AI SREs that start from the alert, since root-cause backtracking is the wrong direction

Most AI SRE products begin at a lagging indicator and trace backward. Jad says that is why they underperform: "backtracking into a root cause is actually very problematic." 00:31:13 Grepr's approach inverts it: scan everything for what changed and surface early-warning messages. He claims that in cases where Grepr's signals were ignored at customers, "those turned into production incidents." 00:32:42

Systems history says you overprovision rather than build smart operational algorithms, so AI ops may be a workaround for a problem that is usually solved with hardware

Martin's skeptical case: every time engineers build adaptive algorithms (swap memory, adaptive routing, congestion control), "We overprovisioned. Every single time." 00:38:42 His conclusion: "the history of systems is that you don't predict stuff, you overprovision because you can't." 00:38:43 If true, the winning market in ops may be cost and efficiency tools like Grepr's pipeline compression rather than autonomous operators. Jad's counter is that AI can plan its own experiments to gather the missing information.

Operations companies are having a tougher time than coding companies, and security is harder still

Martin says as a VC: "the ones that are trying to tackle operations are having a tough go at it. It is much, much tougher than those that are tackling the code." 00:45:05 Security is even harder because an adversary is "intentionally find[ing] rare states." 00:42:32 The prevailing assumption that AI will conquer every software-adjacent domain on the same timeline is challenged. Jad remains optimistic, saying of operations "it's going to be solved." 00:53:19

Some problems require simulation, and models may stall where answers can't be derived

Martin invokes computational irreducibility: "maybe we just are at an event horizon where like models will solve anything that you don't have to actually simulate to get the answer from." 00:48:26 Jad's rebuttal is the non-obvious part: the agent can plan its own execution and experiments to gain the missing information, so irreducibility becomes an experimentation budget rather than a wall.

3. Companies Identified

Grepr

Observability data-reduction and AI reliability startup led by Jad Naous (10 employees). Mentioned as the subject of the episode. It sits in the telemetry stream, filters noise, and extracts signal. Quote: "you put us in the data stream, plug and play, pass the data through, reduce your cost by 90%. And now we're building out that second layer where we're feeding those signals into the AI layer." 00:10:05 — Jad Naous. It scans "a petabyte of logs per day" and escalates novel patterns to an AI. 00:36:00 — Jad Naous

Datadog

Observability incumbent. Mentioned as the pain point customers want to cut. Quote: "You said you can save 90% of our Datadog bills?... That's what I want to buy." 00:57:25 — Jad Naous, relaying customers

Anthropic (Claude Code, Opus 5.5)

Maker of Claude Code and Opus. Jad's daily coding stack. Quote: "I use Opus 5.5... It's an amazing model." 00:20:10 — Jad Naous. Martin agrees: "Which is a really good model." He also reports quirks, such as it spinning up "20... agents to do basic research and burn all your tokens." 00:12:50 — Jad Naous

OpenAI Codex

Alternative coding harness the team tried, mentioned by Jad as having different context-management behavior. Quote: "using Opencode or like different harnesses, or like using Codex versus Claude Code, like different ones have different ways of managing context." 00:12:22 — Jad Naous

Opencode

Open-source coding agent harness the team trialed. See Codex quote above. — Jad Naous

GitHub Copilot

Early autocomplete AI Jad's team used in IntelliJ. Quote: "we were using Copilot in IntelliJ, and we were like, 'Oh, my god, look, it autocompleted these tests.'" 00:11:22 — Jad Naous

Microsoft Windows Subsystem for Linux (WSL)

Jad's dev environment. Quote: "they actually run the Linux kernel within Windows in a hypervisor and provide you access to everything. It's great." 00:19:57 — Jad Naous

Apache Parquet / Apache Iceberg

Columnar file format and table format underlying the data lake architecture Grepr built on. Quote: "typically, the data is column-oriented Parquet files in Iceberg." 00:23:43 — Jad Naous

Imply

Real-time analytics company where Jad was chief product officer, scaling engineering "from about... 15 people to over 90." 00:07:32 — Jad Naous

AppDynamics

Application performance monitoring company Jad joined at ~200 people. It grew to "2,000 people, got acquired by Cisco." 00:06:03 — Jad Naous

Cisco

Acquirer of AppDynamics. Jad was "a Cisco employee for one day." 00:06:03 — Jad Naous

Nicira

Network virtualization startup founded by Martin Casado. Jad: "You went and started Nicira." 00:03:50 — Jad Naous

Uber

Used as the benchmark for self-driving economics. Quote: "$170 billion of investment to get to worse unit economics than Uber." 00:53:50 — Martin Casado

a16z

Venture firm where Martin works and Jad previously spent a couple of years. Jad: "I stayed here for a couple of years, did a bunch of work with you." 00:06:52 — Jad Naous

Stanford / MIT

Academic origins. MIT is where Jad did a postdoc with Nickolai Zeldovich. 00:04:20 — Jad Naous

4. People Identified

CEO of Grepr, former Imply CPO, AppDynamics architect, a16z investor, Stanford PhD (OpenFlow, hardware security). Martin calls him "one of the best systems thinkers I know." 00:02:36 Mentioned as the guest, with a track record of scaling engineering teams and now running 10 people at production-grade velocity.

Martin Casado

a16z general partner, founder of Nicira, Stanford PhD. Jad's "ahead" labmate. He is the primary challenger in the episode, citing his own distributed Gaussian splat renderer: "I will say it's shit... none of the models do a good job." 00:27:53

Nick McKeown

Stanford professor and Jad's and Martin's PhD advisor. Mentioned in passing. 00:03:19

Balaji Prabhakar

Stanford professor remembered by Martin as "the only professor" who smoked. Mentioned anecdotally. 00:03:26

Nickolai Zeldovich

MIT professor, Jad's postdoc advisor: "also amazingly deep and super smart." 00:04:49 — Jad Naous. Martin: "he's phenomenal." 00:04:58

Ramesh Chandra

MIT PhD student whose research on recovering from exploits by rolling back and replaying state over a patched application seeded Jad's first startup. Jad: "a lot of the work was actually really Ramesh's." 00:04:58

Sundar Iyer

Fellow Stanford group member, told by Martin in an anecdote about finite MP3 states that humanity's state spaces are effectively infinite. 00:44:00

James Cowling

MIT PhD and distributed systems expert used by Martin as a archetype of a human running a cluster. Quote: "James Cowling, PhD from MIT, who runs a distributed cluster, and like if the cluster's down, like the company doesn't work." 00:37:08 — Martin Casado

Sebastian Thrun

Won the DARPA Grand Challenge while Martin was at Stanford, kicking off the self-driving hype cycle. 00:53:50 — Martin Casado

Jennifer, Mark, Ben, Satish, Matt (a16z colleagues)

Named by Jad as great people he worked with at a16z. 00:06:50 — Jad Naous. Ben Horowitz is a participant but speaks only through intro credits.

5. Operating Insights

Run three or four agent sessions, not more, and use CLI sub-agents for persistent context

Jad's tuning of parallelism is a concrete operating tactic: "Typically, I work on like three or four session windows at the same time, because I found that more than that, I just start losing context." 00:21:38 Instead of built-in sub-agents, he tells Claude "to spin up command-line sub-agents, because those maintain their persistent session over time." 00:21:09 The constraint is human context-switching capacity, not agent capacity.

Design-doc-first, with an AI tech-lead reviewer, before any code is written

Jad's process: have the implementer agent produce a PRD and design doc, have a separate "tech lead reviewer" agent critique it, then he personally reviews algorithms, division of labor, and PR relationships. "And then, I tell it just go start, start doing it. Figure out if there's like parallelization that you can do." 00:22:06 The human judgment is front-loaded at the design layer, which fits a team of experienced architects.

Warn the model about token burn explicitly

A cheap tactic: "with Claude Code, I find that if I don't tell it, 'Don't spin up... 20 [sub]agents to do basic research,' it'll go and spin up 20... agents to do research and burn all your tokens." 00:12:50 Harness-specific prompt guardrails matter for cost control.

Ground the AI in benchmarks and real datasets for performance work

For query optimization, Jad gave the model "a data set of the queries and like what the users are asking" and benchmarks. 00:29:28 He found it only discovered missed optimizations once told ("these conjuncts... this particular term is repeated"), then it "built a bunch of hypotheses." 00:29:28 Where it fails is sizing (e.g., memory): "That has to come from actual experiments that run in production." 00:29:55 Define performance benchmarks and constraints up front.

Shift reviews toward tests and golden expectations

With volume of PRs exploding, move effort from line-by-line reading to test design and golden-output diffs. 00:21:03 — Jad Naous

6. Overlooked Insights

Grepr's AI is deliberately not predictive; a deterministic novelty detector does the anomaly work

In passing, Jad clarifies that the architecture splits the problem: a non-generative system detects "a new kind of pattern" across a petabyte of daily logs and lifts it to the AI, which then does hypothesis-driven investigation. 00:35:38 That is a quiet but significant design choice: the generative model is used for reasoning over a pre-filtered, high-signal stream rather than raw data. It reframes where moats form in AI ops. The upstream data pipeline, which doubles as a cost-saving product, is the defensible layer, and the LLM is the replaceable one. Customers get the cost win immediately while the pipeline accumulates the structure that makes AI troubleshooting tractable.

The ops-AI evaluation set may already exist as customer incidents that Grepr's early warnings predicted and customers ignored

Jad drops almost as an aside that "in the cases where we ignored it. Those turned into production incidents." 00:32:41 Implicit in that is a growing labeled corpus of early-warning signal to incident outcomes across customer environments. That is exactly the scarce dataset Martin says is missing ("Where is even the data to learn how to... build a system that understands... the operations?"). Because Grepr sits in the pipeline across many customers, it can accumulate ground truth on which novel log patterns precede real failures, which is the training and evaluation asset that others lack.