LLM-observerbarhet: 6 lärdomar från Datadogs CTO

Lektion 1: AI slog sönder det gamla sättet att granska kod

Vi börjar med trycket som sätter igång allt annat: det finns mer kod än någon kan läsa.

Lê-Quôc är tydlig med att den gamla modellen – en människa som läser en pull request rad för rad – inte överlever i mötet med AI-assisterad utveckling. Oron han hör i branschen handlar om att granskningar blir omöjliga, eftersom det händer för mycket för att kunna följas genom att läsa PR:ar.

Hans svar är inte att be folk läsa snabbare, utan att flytta granskningen någon annanstans.

Den där sista bisatsen är lätt att missa. När du orkestrerar en agent som planerar, en som skriver och en som testar, måste du också hindra skrivaren från att spela de automatiserade testerna i stället för att lösa problemet.

Han går bortom tester. Datadog lägger nu till semiformal och formell bevisföring att en spec gör det den ska, något som var för betungande att försöka brett innan agenter tog över grovjobbet. Det fungerar bäst på backend- och koordinationssystem, där beteendet är tillräckligt matematiskt för att resonera exakt om.

Lektion 2: Produktion är det enda testet som räknas

Att klara alla tester i CI är nödvändigt och långt ifrån tillräckligt. De fel som spelar roll sker senare.

Varje release vilar på antaganden du inte kan kontrollera fullt ut i förväg, om datats form och hur användare beter sig. Utsätt de antagandena för tillräckligt mycket verklig trafik och de sällsynta fallen slutar vara sällsynta; de blir vardagliga fördröjningar och fel från data- och modelldrift.

LLM:er gör detta svårare: Med vanlig kod kan du åtminstone resonera igenom varje gren, men ingen kan mekaniskt förklara varför en modell returnerar det den gör, så samma indata garanterar aldrig samma utdata. Det tillfälliga märkliga resultatet går inte att konstruera bort.

Så du slutar försöka bevisa att ett system är korrekt innan det skeppas. I stället

• skriver du utvärderingar för beteendet du vill ha
• övervakar det i produktion
• behåller du en stoppkontroll för en utrullning som blir dålig.

Frågan är inte längre om det klarade testet, utan om ett problem är en engångsföreteelse eller början på en trend.

Den där livesignalen är inte bara en dashboard för människor. Inkopplad i deploysystemet låter den en agent rulla ut en ändring som en försiktig ingenjör skulle göra, till en procent av användarna, sedan fem, och utifrån verkliga data bedöma om ändringen gör det som var avsett.

Lektion 3: Låt agenter ta slitjobbet

Lê-Quôcs argument för agenter är inte att de ersätter ingenjörer, utan att de tar de delar av jobbet som nöter ner människor.

Felsökning av en incident innebär att kasta hypoteser på ett symptom, och vid långa incidenter är det ofta en långsökt hypotes som visar sig sann. Datadogs agent Bits AI kontrollerar dem alla parallellt, i förväg, medan ingenjören styr den mot den magkänsla som en dashboard aldrig skulle visa.

Den djupare poängen är trötthet. En on-call-utrullning är plötslig skärpthet följt av timmar av ingenting, upprepat tills omdömet blir sämre.

En agent bryr sig inte, och blir inte sämre efter fyra timmars stirrande på siffror. Stress och trötthet försämrar mänsklig prestation, vilket är varför team roterar personer i on-call från början.

Lägg det outtröttliga vaktandet på en maskin, så kommer människor tillbaka utvilade för besluten som behöver dem. Samma logik gäller säkerhetstriage, där analytiker bränner ut sig på att sålla falska positiver från verkliga hot.

Lektion 4: Dela upp arbetet i två loopar

Lê-Quôc organiserar Datadogs agentarbete kring två loopar.

Utvecklingsloopen

De flesta ingenjörer känner igen den första loopen:

1. Skriv kod
2. Skeppa
3. Se om det fungerar
4. Fixa
5. Upprepa

Datadogs vinkel är att ett problem som har sitt ursprung i kod oftast har sin lösning i kod, så plattformen försöker ge dig den lösningen, informerad av vad den vet om applikationen: dess ägarskap, dess senaste ändringar och de fel den har kastat.

Han pekar på optimering av databasfrågor som exempel. Vilken modell som helst kan skriva om en långsam fråga; den svårare delen är att bevisa att omskrivningen är snabbare och säker innan den når produktion, så Datadog testar den mot en realistisk kopia av produktionsdata först och lämnar över en pull request med bevisen bifogade.

Drifts- och säkerhetsloopen

Den andra loopen körs parallellt, antingen av samma personer eller av ett annat team:

1. Detektera
2. Undersök
3. Åtgärda
4. Upprepa

Här triagerar Datadogs AI Guard säkerhetshändelser och stoppar attacker snabbare än en analytiker som arbetar igenom dem för hand. Agenter kan också hantera rutinmässiga driftgöromål som ingenjörer gör dagligen utan större entusiasm, som att ändra storlek på just den där Kubernetes-podden.

I båda looparna är Lê-Quôc bestämd om ordningen. Datadog börjar inte från "här är AI, vilket problem kan den lösa?". De börjar från ett problem kunder redan klagar på, oftast någon variant av "jag vill inte göra den här repetitiva grejen", och arbetar bakåt till om en agent kan anförtros det.

Lektion 5: Håll AI-kostnaderna i schack

Kostnad är begränsningen som sitter bredvid säkerhet, och att hålla priset för att operationalisera stora språkmodeller i schack håller på att bli en egen disciplin. Lê-Quôcs svar på DASH är Datadogs Agent Console.

Fråga en utvecklare vilken modell de behöver, och ofta nämner de den mest kraftfulla (och dyraste). Ibland är det rätt val, men mycket arbete är rutin som en billigare, snabbare modell hanterar lika bra. Att skilja dem åt kräver att läsa trajektorierna för en organisations agenter – vilka verktyg de anropar och hur ofta de lyckas – tills mönster framträder.

De mönstren blir heuristiker snarare än regler: en ledande modell som senaste Claude Opus eller GPT-modeller för planering, något billigt som Claude Haiku för att generera tester.

Principen under ytan handlar om vem som äger beslutet. Summera kostnaden till ett enda tal, och du får vad Lê-Quôc kallar "mycket låg handlingsbarhet": antingen slutar alla spendera, vilket dödar nyttigt arbete, eller så fortsätter alla spendera, vilket verksamheten inte kan bära. Han vill hellre lägga data framför utvecklarna och SRE:erna som väljer modellerna.

Lektion 6: Lär dig att lära

På frågan vad nya ingenjörer bör studera ger Lê-Quôc ett svar som låter gammalt men inte är det.

Modeller är de mest tålmodiga handledare som någonsin uppfunnits, kapabla att förklara vad som helst i vilken takt som helst – en nivå av tillgång som tidigare var förbehållen kungligheter med privatlärare. Men en handledare är bara användbar om du förhör den. Färdigheten är att veta vad du ska fråga och hur du ska kontrollera svaret.

Han rekommenderar att förstå datorer lager för lager i stället för att behandla dem som magi. Ta en schemaläggare, en lastbalanserare, en sandbox, och be en modell förklara hur den fungerar, och fortsätt sedan pressa:

• Vad betyder den här termen?
• Hur mäter man den?
• Vad är matematiken bakom?
• Hur vet du att den fungerar bra?

Att studera klassikerna på det här sättet är medvetet långsamt. Han jämför det med att lära sig ett instrument; du kan lyssna på musik hela dagen, men för att spela piano måste du lägga händerna på tangenterna.

Samma sak gäller AI-skriven kod. Vibe coding är okej, säger han, så länge du kommer tillbaka och frågar varför det fungerade: varför byggdes det så här, finns det bättre angreppssätt, vad modellerades det på. Målet är inte att skriva mindre kod med AI. Det är att förstå den kod du nu producerar så mycket mer av.

Avslutande tankar

Lê-Quôcs huvudbudskap är att loopen inte har förändrats, men tempot har det. Skillnaden är att ingen människa kan hålla uppsikt tillräckligt noga i den hastighet som AI nu rör sig, så övervakningen – och en växande andel av byggandet – flyttas till agenter som inte tröttnar och inte får panik.

Han förespråkar att behandla observerbarhet som ett kontrollplan snarare än en uppsättning diagram. Om agenter ska skriva, testa, skeppa och drifta mjukvara behöver de samma förankring i verkliga produktionsdata som bra ingenjörer förlitar sig på, plus en person som håller i omdömesfrågorna och stoppknappen. Datadog positionerar observerbarhet som lagret som gör den avvägningen säker.

Färdigheten som denna inramning kräver av ingenjörer är tydlig: läs system genom hur de beter sig i produktion, inte bara genom deras källkod. Om du vill bygga den vanan är vår Machine Learning in Production-kompetensväg en bra start.