Obserwowalność LLM: 6 lekcji od CTO Datadog

Lekcja 1: AI rozbiło stary sposób review kodu

Zacznijmy od presji, która uruchamia całą resztę: kodu jest więcej, niż ktokolwiek może przeczytać.

Lê-Quôc mówi wprost, że stary model — człowiek czytający pull request linia po linii — nie wytrzymuje zderzenia z developmentem wspieranym przez AI. Niepokój, który słyszy w branży, dotyczy tego, że review stają się niemożliwe, bo dzieje się zbyt wiele, by nadążać czytaniem PR-ów.

Jego odpowiedź nie polega na tym, by kazać ludziom czytać szybciej, tylko by przenieść review gdzie indziej.

Ostatni człon łatwo przeoczyć. Gdy orkiestrujesz jednego agenta do planowania, innego do pisania, a kolejnego do testów, musisz też powstrzymać „pisarza” przed ogrywaniem testów automatycznych zamiast rozwiązywania problemu.

Idzie też dalej niż testy. Datadog dodaje teraz półformalne i formalne dowody na to, że specyfikacja robi to, co powinna — coś zbyt wymagającego, by powszechnie próbować przed erą agentów, które przejęły ciężar pracy. Najlepiej działa to w backendzie i systemach koordynacji, gdzie zachowanie jest na tyle matematyczne, by precyzyjnie o nim rozumować.

Lekcja 2: Produkcja to jedyny test, który się liczy

Zaliczenie wszystkich testów w CI jest konieczne i zdecydowanie niewystarczające. Prawdziwe porażki zdarzają się później.

Każde wydanie opiera się na założeniach, których nie da się w pełni sprawdzić z wyprzedzeniem — o kształcie danych i zachowaniu użytkowników. Wystaw te założenia na odpowiednio duży realny ruch, a rzadkie przypadki przestają być rzadkie; stają się codziennymi spowolnieniami i błędami wynikającymi z dryfu danych i modelu.

LLM-y to utrudniają: przy zwykłym kodzie możesz przynajmniej rozważyć każdą gałąź, ale nikt nie wyjaśni mechanistycznie, dlaczego model zwraca to, co zwraca, więc ten sam input nigdy nie gwarantuje tego samego outputu. Okazjonalnych dziwnych wyników nie da się „wyinżynierować”.

Przestajesz więc próbować dowieść poprawności systemu przed wysyłką. Zamiast tego:

• Piszesz ewaluacje pożądanych zachowań
• Monitorujesz je na produkcji
• Trzymasz w pogotowiu kontrolę stop na wypadek nieudanego rollout’u.

Pytanie nie brzmi już, czy „zaliczyło”, tylko czy problem to jednorazowy przypadek, czy początek trendu.

Ten sygnał na żywo to nie tylko dashboard dla ludzi. Wpięty w system wdrożeń pozwala agentowi robić rollout tak, jak ostrożny inżynier: najpierw do jednego procenta użytkowników, potem do pięciu, oceniając na podstawie realnych danych, czy zmiana robi to, co miała robić.

Lekcja 3: Pozwól agentom przejąć żmudę

Argument Lê-Quôca za agentami nie jest taki, że zastępują inżynierów, lecz że przejmują części pracy, które ludzi zużywają.

Rozwiązywanie incydentu to strzelanie hipotezami do symptomu, a przy długich incydentach często sprawdza się ta najbardziej nieprawdopodobna. Agent Bits AI od Datadog sprawdza je wszystkie równolegle, z wyprzedzeniem wobec inżyniera, podczas gdy człowiek kieruje go w stronę przeczucia, którego żaden dashboard by nie pokazał.

Głębszy punkt to zmęczenie. Rollout na on-callu to nagła gotowość, po której następują godziny niczego — powtarzane aż do strzępienia się osądu.

Agentowi to nie przeszkadza i nie staje się gorszy po czterech godzinach wpatrywania się w liczby. Stres i zmęczenie pogarszają ludzką wydajność — dlatego zespoły rotują ludzi na dyżurach on-call.

Oddaj maszynie bezustanne czuwanie, a ludzie wrócą wypoczęci do decyzji, które ich potrzebują. Ta sama logika dotyczy triage’u bezpieczeństwa, gdzie analitycy wypalają się, sortując false positive’y od realnych zagrożeń.

Lekcja 4: Podziel pracę na dwie pętle

Lê-Quôc organizuje pracę agentów w Datadog wokół dwóch pętli.

Pętla deweloperska

Większość inżynierów rozpozna pierwszą pętlę:

1. Pisz kod
2. Wdrażaj
3. Sprawdź, czy działa
4. Popraw
5. Powtarzaj

Perspektywa Datadog jest taka, że problem mający źródło w kodzie zwykle ma też rozwiązanie w kodzie, więc platforma stara się podać ci to rozwiązanie — na podstawie wiedzy o aplikacji: jej właścicielstwie, ostatnich zmianach i zgłaszanych błędach.

Wskazuje na optymalizację zapytań bazodanowych jako przykład. Każdy model potrafi przepisać wolne zapytanie; trudniejsza część to udowodnić, że wersja jest szybsza i bezpieczna, zanim trafi na produkcję, więc Datadog testuje ją najpierw na realistycznej kopii danych produkcyjnych i przekazuje pull request z dołączonymi dowodami.

Pętla operacyjno-bezpieczeństwowa

Druga pętla działa równolegle — przez tych samych ludzi albo inny zespół:

1. Wykrywaj
2. Badaj
3. Naprawiaj
4. Powtarzaj

Tu AI Guard od Datadog przeprowadza triage zdarzeń bezpieczeństwa i blokuje ataki szybciej niż analityk robiący to ręcznie. Agenci mogą też przejmować rutynowe operacyjne drobiazgi, które inżynierowie robią codziennie bez entuzjazmu, jak zmiana rozmiaru tego jednego poda Kubernetes.

W obu pętlach Lê-Quôc jest stanowczy co do kolejności działań. Datadog nie zaczyna od „oto AI, jaki problem może rozwiązać?”. Zaczyna od problemu, na który klienci już narzekają — zwykle w stylu „nie chcę robić tej powtarzalnej rzeczy” — i cofa się do pytania, czy agentowi można to powierzyć.

Lekcja 5: Trzymaj wydatki na AI w ryzach

Koszt to ograniczenie stojące obok bezpieczeństwa, a utrzymanie ceny operacjonalizacji dużych modeli językowych w ryzach staje się osobną dyscypliną. Odpowiedź Lê-Quôca na DASH to Agent Console od Datadog.

Zapytaj dewelopera, jakiego modelu potrzebuje, a często wskaże ten najmocniejszy (i najdroższy). Czasem to dobra decyzja, ale wiele pracy to boilerplate, który tańszy i szybszy model zrobi równie dobrze. Odróżnienie jednego od drugiego wymaga czytania trajektorii agentów w organizacji — z jakich narzędzi korzystają i jak często odnoszą sukces — aż pojawią się wzorce.

Te wzorce stają się heurystykami, a nie zasadami: model z czołówki, jak najnowszy Claude Opus lub modele GPT, do planowania; coś taniego, jak Claude Haiku, do generowania testów.

Zasada pod spodem dotyczy tego, kto podejmuje decyzję. Sprowadź koszt do jednej liczby, a otrzymasz — jak mówi Lê-Quôc — „bardzo niską wykonalność”: albo wszyscy przestają wydawać (i pożyteczna praca zamiera), albo wszyscy nadal wydają (czego biznes nie utrzyma). Woli pokazać dane deweloperom i SRE, którzy wybierają modele.

Lekcja 6: Naucz się, jak się uczyć

Zapytany, czego powinni się uczyć nowi inżynierowie, Lê-Quôc daje odpowiedź, która brzmi staroświecko, ale taka nie jest.

Modele to najbardziej cierpliwi tutorzy w historii — potrafią wyjaśnić wszystko, w dowolnym tempie — poziom dostępu zarezerwowany kiedyś dla królów z prywatnymi nauczycielami. Ale tutor jest użyteczny tylko wtedy, gdy go przesłuchujesz. Umiejętność polega na tym, by wiedzieć, o co pytać i jak sprawdzić odpowiedź.

Poleca rozumieć komputery warstwa po warstwie, zamiast traktować je jak magię. Weź scheduler, load balancer, sandbox i poproś model, by wyjaśnił, jak działa, a potem dopytuj dalej:

• Co oznacza ten termin?
• Jak to mierzysz?
• Jaka jest za tym matematyka?
• Skąd wiesz, że działa dobrze?

Takie studiowanie klasyki jest celowo powolne. Porównuje to do nauki instrumentu; możesz słuchać muzyki całymi dniami, ale żeby zagrać na pianinie, musisz położyć ręce na klawiaturze.

Tak samo jest z kodem pisanym przez AI. Vibe coding jest w porządku, mówi, o ile wrócisz i zapytasz, dlaczego to zadziałało: dlaczego zbudowano to w ten sposób, czy są lepsze podejścia, na czym to wzorowano. Celem nie jest pisanie mniejszej ilości kodu z AI. Celem jest rozumienie kodu, którego teraz wytwarzasz o wiele więcej.

Na koniec

Centralne przesłanie Lê-Quôca jest takie, że pętla się nie zmieniła, ale tempo tak. Różnica polega na tym, że żaden człowiek nie zdoła wystarczająco uważnie obserwować przy prędkości, z jaką porusza się dziś AI, więc obserwacja — i rosnąca część budowania — przechodzi do agentów, którzy się nie męczą i nie panikują.

Postuluje, by traktować obserwowalność jako płaszczyznę sterowania, a nie zestaw wykresów. Jeśli agenci mają pisać, testować, wdrażać i obsługiwać oprogramowanie, potrzebują tego samego oparcia w realnych danych produkcyjnych, na którym polegają dobrzy inżynierowie — plus człowieka, który trzyma w ręku decyzje wymagające osądu i przycisk stop. Datadog pozycjonuje obserwowalność jako warstwę, która to ubezpiecza.

Umiejętność, której ten obraz wymaga od inżynierów, jest jasna: czytać systemy przez to, jak zachowują się na produkcji, a nie tylko przez ich źródła. Jeśli chcesz wyrobić ten nawyk, nasz skill track Machine Learning in Production to dobre miejsce, by zacząć.