ExpertsFMAI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous
The a16z Show · October 16, 2026
5 Selected Lessons:
framework · 2 heuristic · 1 reasoning_pattern · 1 case · 1
Change-detection over root-cause-backtracking for operational AI
Source
The a16z Show — AI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous (October 16, 2026) · at 28:22 ▸ · at 30:27 ▸ · at 32:28 ▸ · at 35:22 ▸
When this applies
when trying to diagnose failures in any complex system with a huge state space — software, security, or otherwise
The takeaway
Rather than reasoning backward from a bad outcome through a vast possibility space, instrument for 'something changed' signals in real time and reason forward from the point of first deviation.
Why it works
Backtracking from a lagging indicator (an alert or spike) through an enormous, branching causal history is computationally and combinatorially hard; instead, continuously clustering/scanning for novel patterns surfaces the originating change near the moment it happens, collapsing the search space.
One level up
In high-dimensional systems, replace retrospective search with real-time anomaly surfacing wherever the search space is too large to invert.
Where it stops holding
This stops working when the system doesn't 'tell you something went wrong' via any early signal — i.e., failures that are silent until the lagging indicator appears, or when baseline behavior is too noisy to distinguish a meaningful change from normal drift.
Detail
procedure:
- Ingest full petabyte-scale log stream rather than sampled/pre-filtered telemetry
- Run a (non-generative) predictive/clustering model continuously to detect new/out-of-norm patterns
- Surface the first early-warning message (e.g. 'connections ran out', 'memory exceeded') to the AI layer
- Have the AI reason over that signal: check code origin, check history, form and test hypotheses
- Determine whether it's an actual problem requiring action
benchmarks: {"result":"internally and in customer environments, cases ignored by the team turned into production incidents, per Jad"}
rationale: Most other AI-SRE systems start from the lagging alert and try to backtrack root cause through a complex system, which Jad argues is 'very problematic' and why those systems don't work.
In their words
A lot of those systems basically start from a lagging indicator, like, hey, this metric spiked or like this alert happened. Go back through a very complex system and try to determine why that happened
Ground AI code-generation improvements in explicit performance benchmarks
Source
The a16z Show — AI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous (October 16, 2026) · at 25:04 ▸ · at 28:22 ▸
When this applies
when asking an AI (or any automated system) to improve code/output quality where 'better' isn't self-evident from the code alone
The takeaway
When asking an automated system to optimize something non-obvious, supply it with a measurable, real benchmark/dataset to ground its hypotheses, rather than relying on it to 'just know' what's better.
Why it works
Giving the model concrete performance benchmarks and real usage data lets it form falsifiable hypotheses about what to optimize and test them against ground truth, converting an otherwise unverifiable judgment call into an experiment the model can run and check.
One level up
Autonomous reasoning systems perform well when given an external ground-truth signal to test hypotheses against, and poorly when asked to judge quality from internal consistency alone.
Where it stops holding
This stops working when no representative benchmark/dataset of real usage exists to ground the optimization (e.g., for genuinely novel workloads), or for decisions like memory allocation that 'has to come from actual experiments that run in production' rather than any benchmark.
Detail
procedure:
- Point the model at a dataset of actual queries and user requests
- Have it generate hypotheses about optimizations (e.g., removing redundant conjuncts)
- Validate hypotheses against the performance benchmark
- Iterate until grounded improvement is found
benchmarks: {"result":"did a 'relatively good job' on query optimization once grounded in benchmarks; but had 'no idea' how much memory to allocate, which needed real production experiments"}
rationale: The model's initial pass missed obvious redundancy until shown it was wrong by the benchmark; grounding, not raw capability, closed the gap.
In their words
But ultimately, it was able, because it was able to ground that in performance benchmarks. And I was like, look, here's a data set of the queries and what the users are asking, and so on. Go work on it.
History of systems engineering: over-provision rather than predict
Source
The a16z Show — AI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous (October 16, 2026) · at 37:24 ▸
When this applies
when deciding whether to invest in a 'smart' predictive/adaptive algorithm versus simply adding margin/capacity to sidestep the hard prediction problem
The takeaway
When a system faces heavy-tailed, exception-driven variability, the historically dominant engineering answer is to buy margin/slack rather than build precise prediction — check whether 'solve it with AI' is repeating a pattern previous engineers abandoned for good reason.
Why it works
Predictive/adaptive algorithms for highly variable, exception-heavy environments are historically unreliable (oscillation, catastrophic failure modes like swap thrashing), so engineers have repeatedly chosen the cruder but more robust strategy of over-provisioning capacity instead.
One level up
Before betting on intelligence/prediction to solve a resource-allocation problem, ask why the field's established practice is instead to over-provision, and whether that reason still holds.
Where it stops holding
This stops working when over-provisioning becomes prohibitively expensive or physically impossible (e.g., truly scarce resources), forcing a return to prediction-based approaches regardless of their unreliability.
Detail
approach: Survey the actual historical engineering choice (over-provision vs. predict) in analogous past problems before assuming AI prediction will be the winning strategy for a new one.
signals:
- swap-to-disk catastrophic failure mode in memory management
- adaptive routing algorithms causing oscillations, replaced by ECMP over-provisioning
- congestion control history
rationale: 'the history of systems is that you don't predict stuff, you over-provision because you can't.'
In their words
But I will tell you: the history of systems, as you know, is you always want to build a smart algorithm that does the efficient thing, the smart virtual memory management, the smart congestion control, the smart routing. And what do we do instead every single time? We build
AI amplifies existing skill gaps rather than closing them
Source
The a16z Show — AI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous (October 16, 2026) · at 10:06 ▸ · at 13:40 ▸
When this applies
when deploying a powerful new tool or leverage multiplier across a team of varying skill levels
The takeaway
Leverage tools amplify the user's existing skill rather than substitute for it — expect disparity to grow, not shrink, after rollout.
Why it works
A tool that extends capability multiplies existing judgment and complexity-handling ability; engineers who can decompose problems well direct the tool effectively, while those who can't get little added value, widening the gap.
One level up
Before betting that a new tool will 'level the playing field,' assume it will instead widen pre-existing competence gaps.
Where it stops holding
This stops working when the tool fully automates a task end-to-end with no judgment required from the user, in which case skill differences may matter less.
Detail
rule: Good engineers get much better with AI; weak engineers don't become good — the disparity multiplies, roughly described as '10x'.
threshold: Observed on a small team (not yet validated at 100+ people, per Jad's own caveat)
rationale: The more complexity a person's brain can handle and decompose, the better they can direct and supervise AI output; AI doesn't do that decomposition/judgment work itself for hard distributed-systems problems.
In their words
And then, as we started hiring more people into the team, that disparity between okay engineers and really good engineers just multiplied 10x.
Customers wanted to buy the cost-savings, not the reliability/AI story
Source
The a16z Show — AI Can Write the Code. Can It Run the System? | Grepr CEO Jad Naous (October 16, 2026) · at 57:20 ▸
When this applies
when selling a bundled product where one component has an obvious, easily priced ROI and another component has a vague, hard-to-value benefit
The takeaway
When pitching a multi-part value proposition, expect the easily quantified, line-item-reducing benefit to dominate buyer attention regardless of the seller's own priorities; lead with what customers can already price.
Why it works
Buyers gravitate to the part of an offering with an immediately quantifiable dollar value (data bill reduction) and tune out the part whose value (avoided incidents, reliability) is diffuse and hard to price, even when the latter may be more strategically important.
One level up
Market readiness, not technical merit, determines which part of your value proposition actually closes the deal.
Where it stops holding
This stops working once the market matures enough that buyers have established ways to price the harder-to-quantify benefit (as Jad notes already happened for coding productivity, 'one of the highest line items').
Detail
situation: Grepr pitched a combined offer: 90% telemetry cost reduction plus AI-driven reliability improvements.
decision: Customers interrupted the pitch to confirm they wanted to buy the cost reduction specifically.
outcome: Customers said explicitly 'that's what I want to buy' about the cost savings and brushed past the AI/reliability pitch.
lesson: For coding productivity, value is already obvious and easy to price ('engineering productivity... one of the highest line items'), but for ops/reliability gains it's still early and hard for buyers to attach a dollar value to, even though it may matter more.
In their words
They're like, wait, wait, wait, wait, wait. Roll back. You said you can save 90% of our data dog bills. Yeah. And they're like, that's what I want to buy. but but but the but the AI thing, and they're like, No, no, no, no, but that's what we want to buy right now.