LLM-observability: 6 lessen van de CTO van Datadog

Les 1: AI brak de oude manier van code reviewen

Beginnen we bij de druk die alles in gang zet: er is meer code dan wie dan ook kan lezen.

Lê-Quôc is helder: het oude model, een mens die een pull request regel voor regel leest, overleeft AI-ondersteunde ontwikkeling niet. De zorg die hij overal in de industrie hoort, is dat reviews onmogelijk worden, omdat er te veel gebeurt om via PR's bij te houden.

Zijn reactie is niet vragen om sneller te lezen, maar de review naar ergens anders verplaatsen.

Die laatste clausule is makkelijk te missen. Zodra je de ene agent laat plannen, een andere laat schrijven en weer een andere laat testen, moet je er ook voor zorgen dat de schrijver de geautomatiseerde tests niet gaat gamen in plaats van het probleem op te lossen.

Hij gaat verder dan tests. Datadog voegt nu semi-formele en formele bewijzen toe dat een spec doet wat hij moet doen — iets wat eerder te belastend was om op grote schaal te proberen, voordat agents het zware werk overnamen. Het werkt het best bij backend- en coördinatiesystemen, waar het gedrag wiskundig genoeg is om er precies over te redeneren.

Les 2: Productie is de enige test die telt

Alle tests halen in CI is noodzakelijk en lang niet voldoende. De problemen die ertoe doen, gebeuren later.

Elke release rust op aannames die je vooraf niet volledig kunt controleren, over de vorm van de data en hoe gebruikers zich gedragen. Blootgesteld aan genoeg echt verkeer stoppen zeldzame gevallen met zeldzaam zijn; ze worden de alledaagse vertragingen en fouten van data- en modeldrift.

LLM's maken dit lastiger: bij gewone code kun je tenminste elke tak beredeneren, maar niemand kan mechanistisch verklaren waarom een model geeft wat het geeft. Dezelfde input levert dus nooit gegarandeerd dezelfde output op. Af en toe een vreemd resultaat valt niet weg te engineeren.

Dus stop je met proberen een systeem vóór verzending correct te bewijzen. In plaats daarvan

• Schrijf je evaluaties voor het gewenste gedrag
• Monitor je in productie
• Houd je een stopcontrole achter de hand voor een rollout die misgaat.

De vraag is niet langer of het geslaagd is, maar of een probleem eenmalig is of het begin van een trend.

Dat live signaal is niet alleen een dashboard voor mensen. Ingebouwd in het deploysysteem laat het een agent een change uitrollen zoals een zorgvuldige engineer dat zou doen: naar één procent van de gebruikers, dan vijf, en op basis van echte data beoordelen of de wijziging doet wat de bedoeling was.

Les 3: Laat agents het monnikenwerk doen

Lê-Quôc's pleidooi voor agents is niet dat ze engineers vervangen, maar dat ze de onderdelen van het werk overnemen die mensen afmatten.

Een incident troubleshooten betekent hypothesen op een symptoom afvuren, en bij lange incidenten blijkt vaak een vergezochte hypothese de juiste. Datadog's Bits AI-agent test ze allemaal parallel, vóór de engineer, terwijl de persoon het bijstuurt richting het onderbuikgevoel dat een dashboard nooit zou laten zien.

Het diepere punt is vermoeidheid. Een on-call rollout is plotselinge paraatheid gevolgd door urenlang niets, herhaald tot je beoordelingsvermogen rafelt.

Een agent heeft daar geen moeite mee, en wordt niet slechter na vier uur naar cijfers staren. Stress en vermoeidheid tasten menselijk presteren aan — daarom rouleren teams mensen überhaupt door on-call.

Laat het eindeloze turen over aan een machine, en mensen komen uitgerust terug voor de beslissingen die hen nodig hebben. Hetzelfde geldt voor security-triage, waar analisten opgebrand raken door valse positieven van echte dreigingen te scheiden.

Les 4: Splits het werk in twee lussen

Lê-Quôc organiseert Datadog's agentwerk rond twee lussen.

De ontwikkellus

De meeste engineers zullen de eerste lus herkennen:

1. Code schrijven
2. Shippen
3. Kijken of het werkt
4. Fixen
5. Herhalen

Datadog's invalshoek is dat een probleem dat in code ontstaat, meestal ook in code wordt opgelost. Dus probeert het platform je die fix aan te reiken, gevoed door wat het weet over de applicatie: eigenaarschap, recente wijzigingen en de fouten die zijn opgetreden.

Hij noemt databasequery-optimalisatie als voorbeeld. Elk model kan een trage query herschrijven; het lastigere deel is bewijzen dat de herschrijving sneller en veilig is vóór productie. Daarom test Datadog eerst tegen een realistische kopie van de productiedata en levert het een pull request met het bewijs erbij.

De operations- en security-lus

De andere lus draait parallel, door dezelfde mensen of een ander team:

1. Detecteren
2. Onderzoeken
3. Oplossen
4. Herhalen

Hier triaget Datadog's AI Guard security-events en blokkeert het aanvallen sneller dan een analist die alles met de hand doorloopt. Agents kunnen ook routinematige operationele klussen afhandelen die engineers dagelijks doen zonder veel enthousiasme, zoals dat ene Kubernetes-podje resizen.

Over beide lussen heen is Lê-Quôc duidelijk over de volgorde der dingen. Datadog begint niet bij "hier is AI, welk probleem kunnen we oplossen?" Het begint bij een probleem waar klanten al over klagen — meestal een variant op "ik wil dit repetitieve werk niet doen" — en werkt terug naar de vraag of een agent ermee kan worden vertrouwd.

Les 5: Houd AI-uitgaven in toom

Kosten zijn de beperking naast veiligheid, en de prijs van het operationaliseren van large language models in toom houden wordt een discipline op zich. Lê-Quôc's antwoord op DASH is Datadog's Agent Console.

Vraag een developer welk model hij nodig heeft, en vaak noemen ze het krachtigste (en duurste). Soms is dat de juiste keuze, maar veel werk is boilerplate die een goedkoper, sneller model net zo goed aankan. Het onderscheid maken betekent de trajecten van de agents in een organisatie lezen: welke tools ze aanroepen en hoe vaak ze slagen — tot er patronen zichtbaar worden.

Die patronen worden heuristieken in plaats van regels: een frontiermodel zoals de nieuwste Claude Opus of GPT-modellen voor plannen, iets goedkoops zoals Claude Haiku voor het genereren van tests.

Het onderliggende principe gaat over eigenaarschap van de beslissing. Kosten optellen tot één getal levert wat Lê-Quôc "heel lage uitvoerbaarheid" noemt: of iedereen stopt met uitgeven — wat nuttig werk doodt — of iedereen blijft uitgeven — wat het bedrijf niet volhoudt. Hij zet de data liever voor de developers en SRE's die de modellen kiezen.

Les 6: Leer hoe je leert

Gevraagd wat nieuwe engineers zouden moeten bestuderen, geeft Lê-Quôc een antwoord dat oud klinkt en het niet is.

Modellen zijn de meest geduldige tutors ooit, in staat om alles in elk tempo uit te leggen — een niveau van toegang dat vroeger was voorbehouden aan royalty met privéleraren. Maar een tutor is alleen nuttig als je hem ondervraagt. De vaardigheid is weten wat je moet vragen en hoe je het antwoord checkt.

Hij raadt aan computers laag voor laag te begrijpen in plaats van ze als magie te zien. Neem een scheduler, een load balancer, een sandbox en vraag een model om uit te leggen hoe die werkt — en blijf doorvragen:

• Wat betekent deze term?
• Hoe meet je dit?
• Wat is de wiskunde erachter?
• Hoe weet je dat het goed werkt?

De klassiekers op deze manier bestuderen is expres traag. Hij vergelijkt het met een instrument leren; je kunt de hele dag naar muziek luisteren, maar om piano te spelen moet je je handen op de toetsen leggen.

Hetzelfde geldt voor door AI geschreven code. Vibe coding is prima, zegt hij, zolang je terugkomt en vraagt waarom het werkte: waarom is het zo gebouwd, zijn er betere aanpakken, waar is het op gemodelleerd. Het doel is niet minder code schrijven met AI, maar de code begrijpen waarvan je nu zoveel meer produceert.

Tot slot

Lê-Quôc's kernboodschap is dat de lus niet is veranderd, maar het tempo wel. Wat anders is: geen mens kan nog scherp genoeg meekijken op de snelheid waarmee AI nu beweegt. Dus het meekijken — en een groeiend deel van het bouwen — verschuift naar agents die niet moe worden en niet in paniek raken.

Hij pleit ervoor om observability te zien als een control plane in plaats van een set grafieken. Als agents software gaan schrijven, testen, shippen en runnen, hebben ze dezelfde verankering in echte productiedata nodig waar goede engineers op vertrouwen — plus een mens die de beoordelingsknoppen en de stopknop vasthoudt. Datadog positioneert observability als de laag die die ruil veilig maakt.

De vaardigheid die dit kader van engineers vraagt is helder: lees systemen via hun gedrag in productie, niet alleen via de broncode. Wil je die gewoonte opbouwen, dan is ons Machine Learning in Production-skill track een goed beginpunt.