After the Code Is Written: Jed on AI, Production Systems and the Limits of Autonomous Operations

1. Guest Background

The supplied episode of a16z / The Ben & Marc Show runs for approximately 59 minutes and asks why AI can write software yet still struggles with keeping it running. Its guest is Jed, also rendered as Jad in the transcript, introduced as CEO of Grepper. The evidence provides no surname, and the company name should be treated as the transcription supplied rather than silently corrected. His relevance to the discussion comes from the systems work and operating experience he describes.

Jed worked on OpenFlow and built hardware implementations of SHA-3 candidates to evaluate their behavior. He subsequently conducted application-security research at MIT with Nikolay Zeldovich. One research-based startup attempted a particularly demanding recovery mechanism: after an application was exploited, roll back the associated state and replay it against a patched version to remove the exploit. Jed says the technology was too early and that the team almost made it work.

That account introduces the episode's central difficulty. The interviewer immediately asks how anyone can bound the state associated with an operational system. A patch can be identifiable while its surrounding consequences remain difficult to contain. Jed later worked at AppDynamics, spent time in venture capital and served as a chief product officer building product and engineering-related teams. The conversation therefore draws on implementation, organizational coordination and product judgment. His earlier recovery project supplies a useful lens for the interview, without establishing that today's AI tools have solved its underlying state-boundary problem.

2. What the Episode Covers

Jed's starting point is an economic mismatch in observability. He says conversations with engineering leaders in 2023 repeatedly turned to infrastructure and observability spending. In his account, observability represented roughly 5%–20% of infrastructure expenditure, but the intended purchase was reliability and predictable spending. He argues that microservices and collection at multiple layers increased telemetry volumes while the reliability gained from each additional dollar flattened. These are findings and interpretations he reports from those conversations, rather than an established spending distribution for all companies.

His product approach follows that diagnosis: extract useful signals upstream in the telemetry stream, reduce downstream processing costs and feed the signals into an AI troubleshooting layer. Jed claims a 90% cost reduction. The interview does not supply a measurement method or independent validation. The architecture nevertheless presents a distinct proposition worth examining: the same upstream processing could support both a cost product and a reliability product. Evidence for one benefit would still need to be separated from evidence for the other.

The development discussion turns to how engineers organize AI work. Jed says effective users adapt to different models, harnesses and approaches to context. He describes a tenfold widening of the gap between ordinary and excellent engineers, then explicitly limits that observation to his small team building distributed systems. The explanation he offers is that people must understand complexity well enough to divide work into tasks agents can execute.

His own workflow combines parallelism with review. He typically manages three or four session windows; beyond that, he starts losing context. Persistent command-line agent sessions help maintain continuity. Agents prepare design and PR documents and review one another's proposals. Jed checks algorithms, the division of work and dependencies between PRs before implementation proceeds. The result must eventually converge into a stack a human can inspect individually. Tests and golden expectations receive increasing attention during review.

The concrete delivery example is auto promotion, or shredding: promoting fields from semi-structured log events into independent data-lake columns for filtering and querying. The implementation involves Parquet, Iceberg, metadata commits and coordination across writers. Jed reports shipping it in about ten days and estimates that one person previously would have needed six months. The interviewer calls that roughly a tenfold to twentyfold improvement. A reported completion time, a counterfactual estimate and an interviewer's multiplier are different forms of evidence; together they describe one project, not a universal productivity rate.

The operational architecture introduces another division of labor. A separate detection mechanism identifies environmental changes and new log patterns, then an AI agent traces code, checks history and evaluates explanations. Jed cites daily petabyte-scale logs as an input example and names connection, memory and buffer exhaustion as possible early signals. The discussion thus shifts from generating an implementation to obtaining the evidence needed to decide what an operating system requires next.

3. Core Views: Reasoning, Examples, and Limits

The episode's strongest distinction is between producing code and establishing its behavior. Even the terminology receives scrutiny. When the interviewer uses SQL execution time to illustrate semantics, Jed separates performance characteristics from meaning: configuration-dependent treatment of NULL is a semantic issue, whereas runtime depends on data and schema. They subsequently use semantics more loosely for system behavior. Preserving that correction matters because correct results, intended meaning and acceptable performance require different checks. A plausible implementation does not supply all three kinds of evidence.

Distributed systems make those distinctions consequential. The interviewer points to consistency, locking and caching: an acceptable choice depends on access patterns and workload. Generating a familiar design cannot establish whether temporary stale reads are acceptable or whether a cache helps the actual application. The missing ingredient may be information about the environment rather than knowledge of the algorithm. This makes the completeness of the task specification part of the engineering problem.

Jed's query-optimization example shows how feedback can help. His team supplies query datasets, performance benchmarks and stream-processor constraints. Yet he first had to point out a repeated conjunction in an AND expression before the model began exploring further optimization hypotheses. Human diagnosis helped direct the search; benchmarks then allowed candidate improvements to be evaluated. The result supports an iterative method rather than the stronger claim that the model independently recognized every useful transformation. Jed also says memory allocation still requires production experiments.

The interviewer's distributed Gaussian-splat renderer offers a contrasting experience. He reports poor results where paging and streaming millions of splats depend on the running system. That does not establish a general inability to optimize rendering software. It does challenge any assumption that success under one set of benchmarks transfers automatically to another workload. Together, the examples make feedback coverage a central question: which important states and constraints are represented, and which remain outside the agent's working evidence?

Jed applies a related separation to AI SRE. The detector raises a changed pattern; the generative agent investigates its significance. A connection-exhaustion message can become the starting point for tracing code and checking historical events. This avoids requiring a language model to predict every incident directly from the full log stream. However, novelty can also reflect ordinary traffic changes. A detected difference is neither proof of failure nor proof of a particular cause. The investigation must earn those conclusions through additional evidence.

The deployment account is encouraging but narrow. Jed reports internal use and a few customer environments, including a couple of ignored warnings that later became incidents. The interview provides no denominator for those successes: how many warnings led nowhere, how many incidents arrived without warning, or whether acting on a warning would have prevented the outcome. Jed himself draws a clear capability boundary. He considers human-level query optimization very close, but says AI cannot yet independently run a business-critical distributed cluster. A local optimization result cannot carry that larger operational responsibility.

The skeptical argument concerns rare events and incomplete knowledge. The interviewer describes operations as heavy-tailed and exception-driven, with limited examples of many important failures. His references to extra RAM, overprovisioning, ECMP and adaptive-routing oscillations explain why he values spare capacity over prediction-dependent efficiency. These are his engineering judgments, not proof that adaptive systems invariably fail. Both speakers also identify random external loads, unannounced releases and interacting conditions that produce deadlocks. Operational knowledge may be distributed among people, including someone who heard informally about a deployment that never entered the available record.

Their most productive agreement is that debugging procedures may be easier to learn than the entire failure space. An agent can propose causal chains, retrieve evidence and run experiments to eliminate explanations inconsistent with the environment. Jed describes a similar approach to security signals involving behavior, entities and cardinalities. The interviewer adds an important limitation: adversaries deliberately seek rare problematic states. Investigation methods that work for ordinary operational variation therefore need separate evaluation in an adversarial setting.

Finally, the discussion of computational irreducibility reframes what useful intelligence might do. The interviewer argues that language and code compress a higher-dimensional world, and some answers require actual execution or simulation. Jed responds that an agent can plan information gathering, write experimental code and simulate instead of answering immediately. That expands the evaluation target from immediate correctness to effective inquiry. It leaves unresolved whether the agent can recognize important dimensions absent from its initial description. Running an experiment and knowing which missing condition to investigate remain distinct challenges.

4. Learning and Application

For engineering teams, the most direct application is to make AI assignments testable contracts. A query-translation task should specify input conditions, semantic rules such as NULL handling, expected results and performance requirements. Correctness checks should remain distinct from timing measurements. Representative query samples can guide optimization, while memory sizing requires a separate experiment grounded in running behavior. These are practical deductions from the interview, not additional outcomes reported by Jed.

Parallel work also needs explicit integration boundaries. Ask agents to propose the design and PR dependencies before implementation, then have a responsible engineer check algorithms, interfaces and sequencing. During review, establish why the expected results are correct rather than relying only on passing tests. If implementation and expectations change together, a green result alone cannot explain the behavioral change. Jed's three or four windows describe his context limit; teams should measure their own coordination burden instead of treating that number as a staffing formula.

Productivity evaluation should distinguish implementation time from design, review and integration effort. Ten days versus an estimated six months is a useful case to examine, but the earlier duration is counterfactual. A stronger internal assessment would compare similar tasks with comparable acceptance requirements and record human review and rework alongside delivery speed. That helps determine whether the benefit comes from a repeatable process or from one engineer's unusually deep familiarity with the system.

An operational pilot can begin with bounded investigation. Let detection raise new patterns or resource warnings, then require the agent to present candidate causes, supporting evidence and unresolved questions. When deployment context or hidden state is missing, involve people who possess it. Track detection quality, investigation usefulness and actionability separately. Because the interview supplies no aggregate performance statistics, the evaluation should retain false alarms, missed incidents and inconclusive investigations as well as successful examples. Otherwise a collection of impressive cases can conceal an ineffective overall system.

Experiments and simulations should state which loads and conditions they cover. Their results provide additional evidence without guaranteeing that omitted production states are harmless. Security requires particular care because an adversary may change behavior deliberately. Neither useful investigation nor progress on query optimization establishes readiness to accept independent responsibility for a critical cluster.

Teams can also reduce the environment's complexity. The speakers discuss changing warehouses and robotic settings to make automation more feasible. A software counterpart would be making deployment records, configuration changes and dependency information easier to retrieve, reducing reliance on informal conversations. This is an analytical extension of their argument. Its value depends on whether the cost of organizing the environment is justified by better investigation. The interviewer's forecast of faster progress in constrained domains offers a pilot-selection hypothesis, not a demonstrated law.

Procurement should maintain separate accounts for telemetry bills, engineering time and incident losses. Jed's story about customers prioritizing claimed Datadog savings shows a purchase preference; it does not validate the 90% figure. A trial should define workload, retained data, comparison period and added costs, while checking that useful investigative signals survive the cost reduction. Reliability improvements need their own evidence, and avoided losses require careful attribution. An easily priced entry product can create an opportunity to test operational capabilities without proving those capabilities in advance.

Source

• Original episode: Why AI Can Write Code But Can’t Keep It Running (Yet)