a16z Podcast

Die Lücke zwischen dem Schreiben einer Zeile Code und der Wartung eines lebenden Systems in der Produktion ist ein Abgrund an Komplexität, den die KI noch nicht vollständig überbrückt hat. Während Large Language Models (LLMs) die „Syntax“ – die digitale Repräsentation von Logik – gemeistert haben, kämpfen sie mit der „Semantik“, was in diesem Kontext das tatsächliche Laufzeitverhalten eines Systems bezeichnet. Die Herausforderung besteht darin, dass das Verhalten eines Programms nicht nur ein Produkt seines Codes ist, sondern das Ergebnis seiner Interaktion mit unvorhersehbaren Workloads, Hardware-Beschränkungen und einem Zustandsraum, der mit jedem hinzugefügten Bit an Daten exponentiell wächst.

Jad Naous, CEO von Grepr, argumentiert, dass der Erfolg der KI beim Codieren daraus resultiert, dass sie auf einer handhabbaren Mannigfaltigkeit (Manifold) aller menschengeschriebenen Codes trainiert wurde. Betriebssysteme sind jedoch „heavy-tailed“ und ausnahmenbasiert. Naous vertritt die Ansicht, dass KI zwar mittlerweile bemerkliche Mengen an Produktionscode schreiben kann, der Betrieb eines Systems jedoch ein Nachdenken über Dinge erfordert, die nicht in den Trainingsdaten enthalten sind – wie etwa die Speicherspitze eines bestimmten Servers oder eine plötzliche Änderung der Traffic-Muster. Er sieht die Welt der KI als eine digitale Simulation, die oft im Widerspruch zur chaotischen, physischen Realität der Infrastruktur steht.

Der intellektuelle Austausch zwischen Naous und a16z konzentriert sich auf die Frage, ob diese operative Lücke eine unüberwindbare Mauer oder ein lösbares technisches Problem ist. a16z schlägt vor, dass der Weg nach vorne nicht darin besteht, die KI zu bitten, Ausfälle vorherzusagen – was rechentechnisch irreduzibel ist –, sondern die KI zu nutzen, um den Workflow des Debuggings zu steuern. Indem man den Betrieb als eine Serie deterministischer Schritte betrachtet (eine Änderung erkennen, eine Hypothese aufstellen, ein Experiment durchführen), argumentiert a16z, dass die KI die Rolle eines menschlichen SRE (Site Reliability Engineer) simulieren kann, um einen nahezu unendlichen Zustandsraum in etwas Handhabbares zu begrenzen.

Naous veranschaulicht diesen Übergang an seiner Arbeit bei Grepr, wo er über die einfache Observability hinausgeht. Er argumentiert, dass Unternehmen Observability historisch gesehen als Ersatz für Zuverlässigkeit gekauft haben, aber die Grenzerträge dieser Investition stagnierten. Der Ansatz von Grepr besteht darin, Signale bereits im Upstream des Datenstroms zu extrahieren, wodurch die Kosten um bis zu 90 % gesenkt werden, und diese hochpräzisen Signale dann in eine KI-Schicht einzuspeisen. Diese KI löst nicht einfach nur Alarme aus; sie analysiert das Signal, um zu bestimmen, ob ein neues Log-Muster eine bedeutsame Anomalie oder bloßes Rauschen ist.

Ein erheblicher Teil des Dialogs befasst sich mit dem „Hebel“ (Leverage), den die KI den Ingenieuren bietet. Naous behauptet, dass sich die Kluft zwischen durchschnittlichen und Elite-Ingenieuren verzehnfacht hat. Da die KI die Syntax übernimmt, liegt der Wert des Elite-Ingenieurs nun in seiner Fähigkeit, architektonische Komplexität zu managen und massive Probleme in Aufgaben zu zerlegen, die eine KI ausführen kann. Naous teilt ein beeindruckendes Beispiel: die Implementierung einer komplexen „Auto-Promotion“-Funktion in einem Data Lake innerhalb von zehn Tagen – ein Projekt, für das ein einzelner Ingenieur zuvor sechs Monate benötigt hätte.

Letztendlich dreht sich das Gespräch um eine philosophische Debatte über die Grenzen der KI. a16z bleibt optimistisch, dass sich der „distributionale“ Erfolg der KI im Bereich Code schließlich auf den Betrieb ausweiten wird. Naous ist vorsichtiger und weist darauf hin, dass einige Probleme rechentechnisch irreduzibel sind – man muss das System einfach laufen lassen, um zu sehen, was passiert. Er vermutet, dass die Zukunft nicht darin liegen wird, dass die KI die reale Welt „löst“, sondern dass Menschen die reale Welt so verändern, dass sie den Beschränkungen entspricht, die eine KI tatsächlich verwalten kann.

Zentrale Diskussionsthemen

Syntax vs. Semantik in der Software

Naous und a16z unterscheiden zwischen der „Syntax“ des Codes (den getippten Zeichen) und der „Semantik“ (dem, was die Maschine zur Laufzeit tatsächlich tut). Sie argumentieren, dass LLMs Meister der Syntax sind, da sie fast jede denkbare Art, eine Funktion zu schreiben, gesehen haben. Die Semantik wird jedoch von externen Faktoren beeinflusst – Schema, Datenform und Hardware –, die für das Modell oft unsichtbar sind. Diese Unterscheidung erklärt, warum eine KI zwar einen verteilten Algorithmus schreiben kann, Ihnen aber nicht sagen kann, wie viel RAM man ihm zuweisen muss.

Die „Leverage Gap“ im Engineering

Naous beobachtet eine wachsende Produktivitätslücke zwischen Senior-Architekten und Junior-Entwicklern. Da die KI den Boilerplate-Code und die Routine-Implementierung übernimmt, hat sich der „Engpass“ hin zum systemischen Denken auf hoher Ebene verschoben. Die Fähigkeit, ein komplexes mentales Modell eines verteilten Systems aufrechtzuerhalten und dieses in Prompts zu zerlegen, ist nun der primäre Werttreiber. Dies ermöglicht es einem kleinen Team (wie dem Zehn-Personen-Team von Naous), die Arbeitsleistung einer viel größeren Organisation zu erbringen.

Das Versagen traditioneller Observability

Naous kritisiert den aktuellen Branchentrend, 5–20 % der Infrastruktur-Budgets für Observability-Tools auszugeben. Er argumentiert, dass mehr Daten nicht mehr Zuverlässigkeit bedeuten, sondern stattdessen ein „Rauschproblem“ erzeugen. Das Ziel sollte die Verschiebung von „nachlaufenden Indikatoren“ (Alarmierung nach einer Spitze) hin zur „Upstream-Signalextraktion“ sein, bei der die KI eine Änderung in der Umgebung identifiziert, bevor sie sich als Produktionsvorfall manifestiert.

Rechentechnische Irreduzibilität und Simulation

a16z und Naous debattieren darüber, ob KI jemals einen menschlichen Operator vollständig ersetzen kann. a16z argumentiert, dass der Zustandsraum eines Systems zwar effektiv unendlich ist, die Schritte, die ein Mensch zum Debuggen unternimmt, jedoch endlich sind und modelliert werden können. Naous hält dem die Idee der rechentechnischen Irreduzibilität entgegen – die Vorstellung, dass einige Systeme nicht vorhergesagt werden können und in Echtzeit simuliert oder ausgeführt werden müssen, um die Antwort zu finden, was eine harte Grenze für prädiktive KI setzt.

Überraschende Erkenntnisse

• Der 10- bis 20-fache Produktivitätssprung: Features in Produktionsqualität, für die ein Ingenieur zuvor sechs Monate benötigte, können nun mithilfe von KI-Agenten in etwa zehn Tagen ausgeliefert werden.


• Das Observability-Paradoxon: Höhere Ausgaben für Observability-Tools haben einen Punkt abnehmender Grenzerträge erreicht, an dem die Kosten der Datenerfassung schneller steigen als die dadurch gewährleistete Zuverlässigkeit.

Praktische Erkenntnisse

• Wechsel von Alerts zur Änderungserkennung: Anstatt auf einen Anstieg einer Metrik zu achten (nachlaufender Indikator), nutzen Sie KI, um zu erkennen, wann ein neues, bisher unbekanntes Muster in den Logs auftritt (vorlaufender Indikator).


• Komplexität für Agenten zerlegen: Um den Hebeleffekt von KI zu maximieren, fordern Sie nicht ein gesamtes System an; unterteilen Sie das Projekt in semantische Schichten, definieren Sie die „Golden Expectations“ (Tests) und weisen Sie Sub-Agenten parallele Aufgaben zu.


• Fokus auf den „Workflow“, nicht auf die „Antwort“: Fragen Sie bei der Fehlerbehebung mit KI nicht: „Warum ist das passiert?“, sondern fordern Sie die KI auf, einen „Hypothesen-Verifizierungs-Workflow durchzulaufen“, um das Problem einzugrenzen.


• Priorisierung der Upstream-Filterung: Reduzieren Sie Telemetriekosten und Rauschen, indem Sie Signale direkt an der Quelle extrahieren, anstatt Rohdaten an eine nachgelagerte Observability-Plattform zu senden.


• Investition in architektonisches Denken: Da Syntax zu einer Commodity wird, ist die wertvollste Fähigkeit für Ingenieure das „Systems Thinking“ – die Fähigkeit, hochdimensionale Komplexität zu handhaben und die Grenzen eines Problems zu definieren.


• „Golden Expectations“ für PRs nutzen: Da das Volumen an KI-generiertem Code zunimmt, sollte sich der Review-Prozess von der Überprüfung des Codes selbst hin zu einer rigorosen Validierung der Tests und der „goldenen“ Erwartungen an den Output verschieben.