LLM-Observability: 6 Lektionen vom CTO von Datadog

Lektion 1: KI hat den alten Code-Review-Prozess aufgebrochen

Beginnen wir mit dem Druck, der alles andere lostritt: Es gibt mehr Code, als irgendwer lesen kann.

Lê-Quôc sagt deutlich: Das alte Modell, bei dem ein Mensch einen Pull Request Zeile für Zeile liest, hat im KI-gestützten Development keine Chance. Die weitverbreitete Sorge lautet, dass Reviews unmöglich werden, weil zu viel passiert, um es über PRs nachzuvollziehen.

Seine Antwort ist nicht, schneller zu lesen, sondern den Review an einen anderen Ort zu verlagern.

Dieser letzte Punkt geht leicht unter. Orchestrierst du einen Agenten fürs Planen, einen fürs Schreiben und einen fürs Testen, musst du auch verhindern, dass der Schreib-Agent die automatisierten Tests ausspielt, statt das eigentliche Problem zu lösen.

Er geht über Tests hinaus. Datadog fügt heute semi-formale und formale Beweise hinzu, dass eine Spezifikation tut, was sie soll – etwas, das früher zu aufwendig war, bevor Agenten die Schwerarbeit übernahmen. Am besten funktioniert das bei Backend- und Koordinationssystemen, deren Verhalten mathematisch präzise begründbar ist.

Lektion 2: Die Produktion ist der einzige Test, der zählt

Alle Tests in CI zu bestehen ist notwendig und bei Weitem nicht ausreichend. Die entscheidenden Ausfälle passieren später.

Jeder Release basiert auf Annahmen, die du vorher nicht vollständig prüfen kannst – über die Form der Daten und das Verhalten der Nutzenden. Bei genug echtem Traffic werden seltene Fälle nicht mehr selten, sondern zu den alltäglichen Verlangsamungen und Fehlern durch Daten- und Modelldrift.

LLMs machen das schwieriger: Bei herkömmlichem Code kannst du zumindest jede Verzweigung logisch durchdenken. Niemand kann jedoch mechanistisch erklären, warum ein Modell genau diesen Output liefert, daher ist derselbe Input nie garantiert mit demselben Output verknüpft. Gelegentliche kuriose Ergebnisse lassen sich nicht wegingenieurieren.

Also hörst du auf, ein System vorab als korrekt beweisen zu wollen. Stattdessen

• schreibst du Evaluierungen für das gewünschte Verhalten,
• überwachst du es in der Produktion
• und behältst eine Stopp-Kontrolle für einen missglückten Rollout.

Die Frage ist nicht mehr, ob es bestanden hat, sondern ob ein Problem ein Ausreißer ist oder der Beginn eines Trends.

Dieses Livesignal ist nicht nur ein Dashboard für Menschen. In das Deployment-System verdrahtet, kann ein Agent einen Change so ausrollen, wie es eine vorsichtige Ingenieurin tun würde: erst auf ein Prozent der Nutzenden, dann fünf – stets anhand realer Daten beurteilend, ob die Änderung den Zweck erfüllt.

Lektion 3: Lass Agenten die Routinearbeit machen

Lê-Quôcs Plädoyer für Agenten ist nicht, Ingenieur:innen zu ersetzen, sondern ihnen die Teile der Arbeit abzunehmen, die auslaugen.

Bei einem Incident Hypothesen gegen Symptome zu testen, heißt viele Spuren verfolgen – und bei langen Incidents ist es oft eine gewagte, die stimmt. Datadogs Bits-AI-Agent prüft sie alle parallel, noch bevor die Ingenieurin ansetzt, während der Mensch es in Richtung einer Ahnung lenkt, die kein Dashboard zeigen würde.

Der tiefere Punkt ist Ermüdung. On-Call bedeutet plötzliche Alarmbereitschaft, gefolgt von Stunden des Wartens – wieder und wieder, bis die Urteilsfähigkeit leidet.

Einem Agenten macht das nichts aus – und nach vier Stunden Zahlenstarren wird er nicht schlechter. Stress und Müdigkeit senken die menschliche Performance – darum rotieren Teams überhaupt durchs On-Call.

Gib die mühelose Dauerbeobachtung an Maschinen ab, und Menschen kommen erholt zurück für die Entscheidungen, die sie wirklich brauchen. Dasselbe gilt für Security-Triage, wo Analyst:innen beim Aussortieren von False Positives ausbrennen.

Lektion 4: Teile die Arbeit in zwei Schleifen

Lê-Quôc organisiert Datadogs Agentenarbeit um zwei Schleifen.

Die Entwicklungsschleife

Die erste Schleife werden die meisten Ingenieur:innen wiedererkennen:

1. Code schreiben
2. Shippen
3. Prüfen, ob es funktioniert
4. Fixen
5. Wiederholen

Datadogs Blick: Wenn ein Problem im Code entsteht, liegt die Lösung meist ebenfalls im Code. Also liefert die Plattform dir diese Lösung – gestützt auf Wissen über die Anwendung: Ownership, letzte Änderungen, aufgetretene Fehler.

Als Beispiel nennt er die Optimierung von Datenbankabfragen. Jedes Modell kann eine langsame Query umschreiben; schwieriger ist es, zu beweisen, dass die neue schneller und sicher ist, bevor sie die Produktion erreicht. Also testet Datadog sie zuerst gegen eine realistische Kopie der produktiven Daten und übergibt einen Pull Request mit belastbaren Nachweisen.

Die Operations- und Security-Schleife

Die zweite Schleife läuft parallel – durch dasselbe oder ein anderes Team:

1. Erkennen
2. Untersuchen
3. Beheben
4. Wiederholen

Hier triagiert Datadogs AI Guard Security-Events und blockiert Angriffe schneller, als es Analyst:innen von Hand können. Agenten können auch alltägliche Betriebsaufgaben übernehmen, die Ingenieur:innen wenig Freude bereiten – etwa das eine Kubernetes-Pod zu resize’n.

Über beide Schleifen hinweg ist Lê-Quôc klar in der Reihenfolge: Datadog startet nicht mit "Hier ist KI, was kann sie lösen?". Ausgangspunkt ist ein reales Kundenproblem – meist eine Variante von "Ich will diese Routineaufgabe nicht mehr machen" –, und dann die Frage, ob ein Agent sie zuverlässig übernehmen kann.

Lektion 5: Halte die KI-Ausgaben im Zaum

Kosten stehen gleichberechtigt neben Sicherheit. Die Ausgaben für das Operationalisieren von Large Language Models zu steuern, wird zur eigenen Disziplin. Lê-Quôcs Antwort auf der DASH ist Datadogs Agent Console.

Frag eine Entwicklerin, welches Modell sie braucht, und oft fällt die Wahl auf das stärkste (und teuerste). Manchmal ist das richtig, aber vieles ist Boilerplate, die ein günstigeres, schnelleres Modell ebenso gut erledigt. Die Unterscheidung gelingt, wenn du die Trajektorien deiner Agenten liest: welche Tools sie aufrufen und wie oft sie erfolgreich sind – bis sich Muster zeigen.

Diese Muster werden zu Heuristiken statt Regeln: Ein Frontier-Modell wie das neueste Claude Opus oder GPT für Planung, etwas Günstiges wie Claude Haiku für das Generieren von Tests.

Das zugrunde liegende Prinzip betrifft Ownership der Entscheidung. Kosten auf eine einzige Zahl zu verdichten führt zu dem, was Lê-Quôc "very low actionability" nennt: Entweder alle hören auf zu investieren, was sinnvolle Arbeit tötet, oder alle machen weiter, was das Business nicht tragen kann. Er legt die Daten lieber den Developers und SREs vor, die die Modelle auswählen.

Lektion 6: Lernen lernen

Gefragt, was neue Ingenieur:innen studieren sollten, gibt Lê-Quôc eine Antwort, die alt klingt und es nicht ist.

Modelle sind die geduldigsten Tutor:innen, die je erfunden wurden – sie können alles in jedem Tempo erklären. Ein Zugang, der früher Privattutor:innen und Königshäusern vorbehalten war. Doch ein Tutor ist nur nützlich, wenn du ihn befragst. Die Kompetenz liegt darin, zu wissen, was du fragst und wie du die Antwort prüfst.

Er empfiehlt, Computer Schicht für Schicht zu verstehen statt sie als Magie zu behandeln. Nimm einen Scheduler, einen Load Balancer, eine Sandbox und lass dir von einem Modell erklären, wie es funktioniert – und bohre dann weiter nach:

• Was bedeutet dieser Begriff?
• Wie misst du das?
• Welche Mathematik steckt dahinter?
• Woran erkennst du, dass es gut funktioniert?

Die Klassiker auf diese Weise zu studieren, ist absichtlich langsam. Er vergleicht es mit dem Erlernen eines Instruments: Du kannst Musik den ganzen Tag hören, aber um Klavier zu spielen, musst du die Hände auf die Tasten legen.

Dasselbe gilt für KI-geschriebenen Code. Vibe Coding ist okay, sagt er, solange du zurückkehrst und fragst, warum es funktioniert hat: Warum wurde es so gebaut, gibt es bessere Ansätze, woran war es orientiert? Ziel ist nicht, mit KI weniger Code zu schreiben. Ziel ist, den Code zu verstehen, von dem du nun viel mehr produzierst.

Abschließende Gedanken

Lê-Quôcs Kernaussage: Die Schleife hat sich nicht geändert, das Tempo schon. Kein Mensch kann bei der Geschwindigkeit, mit der KI heute arbeitet, aufmerksam genug zuschauen. Also wandert das Beobachten – und ein wachsender Teil des Bauens – zu Agenten, die nicht ermüden und nicht in Panik geraten.

Er plädiert dafür, Observability als Control Plane statt als Sammlung von Charts zu begreifen. Wenn Agenten Software schreiben, testen, shippen und betreiben sollen, brauchen sie dasselbe Fundament in echten Produktionsdaten, auf das gute Ingenieur:innen vertrauen – plus eine Person mit Urteilsvermögen und Stopp-Knopf. Datadog positioniert Observability als die Schicht, die diesen Tausch sicher macht.

Die geforderte Kompetenz ist klar: Lies Systeme über ihr Verhalten in der Produktion – nicht nur über den Source. Wenn du diese Gewohnheit aufbauen willst, ist unser Machine Learning in Production-Lernpfad ein guter Startpunkt.