Osservabilità degli LLM: 6 lezioni dal CTO di Datadog

Lezione 1: L’AI ha rotto il vecchio modo di fare code review

Partiamo dalla pressione che fa partire tutto il resto: c’è più codice di quanto chiunque possa leggere.

Lê-Quôc è netto: il vecchio modello, una persona che legge una pull request riga per riga, non sopravvive al contatto con lo sviluppo assistito dall’AI. L’ansia che sente in tutto il settore riguarda il fatto che le review diventano impossibili, perché succede troppo per poter seguire tutto leggendo le PR.

La sua risposta non è chiedere alle persone di leggere più in fretta, ma spostare la review altrove.

Quell’ultima clausola è facile da perdersi. Una volta che orchestri un agente per pianificare, un altro per scrivere e un altro per testare, devi anche impedire allo scrittore di aggirare i test automatizzati invece di risolvere il problema.

Va oltre i test. Datadog ora aggiunge dimostrazioni semi-formali e formali che una spec fa ciò che deve fare, qualcosa di troppo gravoso da tentare su larga scala prima che gli agenti si facessero carico del lavoro pesante. Funziona meglio su sistemi backend e di coordinamento, dove il comportamento è abbastanza matematico da poter essere analizzato con precisione.

Lezione 2: La produzione è l’unico test che conta

Passare tutti i test in CI è necessario e lontanissimo dall’essere sufficiente. I fallimenti che contano arrivano dopo.

Ogni rilascio si basa su assunzioni che non puoi verificare del tutto in anticipo, sulla forma dei dati e su come si comportano gli utenti. Se esponi abbastanza traffico reale a quelle assunzioni, i casi rari smettono di essere rari; diventano i rallentamenti e gli errori quotidiani di drift dei dati e dei modelli.

Gli LLM rendono questo più difficile: con il codice ordinario, puoi almeno ragionare su ogni branch, ma nessuno può spiegare in modo meccanicistico perché un modello restituisce ciò che restituisce, quindi lo stesso input non garantisce mai lo stesso output. Gli occasionali risultati strani non si possono eliminare con l’ingegneria.

Quindi smetti di cercare di dimostrare che un sistema è corretto prima di spedirlo. Invece,

• Scrivi valutazioni per il comportamento che vuoi
• Lo monitori in produzione
• Tien i un controllo di stop per un rollout che va storto.

La domanda non è più se ha superato i test, ma se un problema è un caso isolato o l’inizio di una tendenza.

Quel segnale live non è solo una dashboard per umani. Integrato nel sistema di deployment, permette a un agente di distribuire una modifica come farebbe un ingegnere prudente: all’uno per cento degli utenti, poi al cinque, giudicando dai dati reali se la modifica sta facendo ciò che si intendeva.

Lezione 3: Lascia agli agenti il lavoro di fatica

La tesi di Lê-Quôc sugli agenti non è che sostituiscano gli ingegneri, ma che si prendano le parti del lavoro che logorano le persone.

Risolvere un incidente significa lanciare ipotesi su un sintomo e, negli incidenti lunghi, spesso è un’ipotesi azzardata a rivelarsi vera. L’agente Bits AI di Datadog le verifica tutte in parallelo, prima dell’ingegnere, mentre la persona lo guida verso l’intuizione che una dashboard non farebbe mai emergere.

Il punto più profondo è la fatica. Un rollout on-call è allerta improvvisa seguita da ore di nulla, ripetute finché il tuo giudizio si logora.

A un agente non importa, e non peggiora dopo quattro ore a fissare numeri. Stress e fatica degradano le performance umane, ed è per questo che i team ruotano le persone nell’on-call.

Affida il monitoraggio instancabile a una macchina, e le persone tornano riposate per le decisioni che hanno davvero bisogno di loro. La stessa logica vale per il triage di sicurezza, dove gli analisti si bruciano nel distinguere i falsi positivi dalle minacce reali.

Lezione 4: Dividi il lavoro in due loop

Lê-Quôc organizza il lavoro sugli agenti di Datadog attorno a due loop.

Il loop di sviluppo

La maggior parte degli ingegneri riconoscerà il primo loop:

1. Scrivi codice
2. Distribuiscilo
3. Vedi se funziona
4. Correggi
5. Ripeti

La visione di Datadog è che un problema che nasce nel codice di solito ha la sua correzione nel codice, quindi la piattaforma prova a fornirti quella correzione, informata da ciò che sa dell’applicazione: la proprietà, le modifiche recenti e gli errori generati.

Cita l’ottimizzazione delle query al database come esempio. Qualsiasi modello può riscrivere una query lenta; la parte più difficile è dimostrare che la riscrittura è più veloce e sicura prima che arrivi in produzione, quindi Datadog la testa prima su una copia realistica dei dati di produzione e consegna una pull request con le prove allegate.

Il loop di operations e sicurezza

L’altro loop gira in parallelo, o dalle stesse persone o da un team diverso:

1. Rileva
2. Indaga
3. Correggi
4. Ripeti

Qui è dove l’AI Guard di Datadog fa triage degli eventi di sicurezza e blocca gli attacchi più velocemente di un analista che li gestisce a mano. Gli agenti possono anche occuparsi di mansioni operative di routine che gli ingegneri svolgono quotidianamente senza grande entusiasmo, come ridimensionare quel pod Kubernetes.

In entrambi i loop, Lê-Quôc è fermo sull’ordine delle operazioni. Datadog non parte da "ecco l’AI, quale problema può risolvere?". Parte da un problema di cui i clienti già si lamentano, di solito qualche versione di "non voglio fare questa cosa ripetitiva", e risale a capire se un agente possa essere affidabile per gestirla.

Lezione 5: Tieni sotto controllo la spesa per l’AI

Il costo è il vincolo che siede accanto alla sicurezza, e mantenere sotto controllo il prezzo di mettere in produzione i large language model sta diventando una disciplina a sé. La risposta di Lê-Quôc a DASH è l’Agent Console di Datadog.

Chiedi a uno sviluppatore di quale modello abbia bisogno, e spesso dirà il più potente (e costoso). A volte è la scelta giusta, ma molto lavoro è boilerplate che un modello più economico e veloce gestisce altrettanto bene. Distinguerli significa leggere le traiettorie degli agenti di un’organizzazione, quali strumenti chiamano e con quale frequenza hanno successo, finché non emergono pattern.

Quei pattern diventano euristiche più che regole: un modello frontier come l’ultimo Claude Opus o i modelli GPT per la pianificazione, qualcosa di economico come Claude Haiku per generare test.

Il principio sottostante riguarda chi possiede la decisione. Se riduci il costo a un singolo numero, ottieni quella che Lê-Quôc chiama "azione molto bassa": o tutti smettono di spendere, il che uccide il lavoro utile, oppure tutti continuano a spendere, cosa che l’azienda non può sostenere. Preferisce mettere i dati davanti a developer e SRE che scelgono i modelli.

Lezione 6: Impara a imparare

Alla domanda su cosa dovrebbero studiare i nuovi ingegneri, Lê-Quôc dà una risposta che suona vecchia e non lo è.

I modelli sono i tutor più pazienti mai inventati, capaci di spiegare qualsiasi cosa a qualsiasi ritmo, un livello di accesso un tempo riservato a reali con insegnanti privati. Ma un tutor è utile solo se lo interroghi. L’abilità è sapere cosa chiedere e come verificare la risposta.

Consiglia di comprendere i computer strato per strato invece di trattarli come magia. Prendi uno scheduler, un load balancer, una sandbox, e chiedi a un modello di spiegare come funziona, poi continua a incalzare:

• Cosa significa questo termine?
• Come lo misuri?
• Qual è la matematica alla base?
• Come sai che sta funzionando bene?

Studiare i classici in questo modo è volutamente lento. Lo paragona a imparare uno strumento; puoi ascoltare musica tutto il giorno, ma per suonare il pianoforte devi mettere le mani sulla tastiera.

Lo stesso vale per il codice scritto dall’AI. Il vibe coding va bene, dice, purché tu torni a chiederti perché ha funzionato: perché è stato costruito così, ci sono approcci migliori, su cosa è stato modellato. L’obiettivo non è scrivere meno codice con l’AI. È capire il codice di cui ora produci molto di più.

Considerazioni finali

Il messaggio centrale di Lê-Quôc è che il loop non è cambiato, è cambiato il ritmo. La differenza è che nessun umano può osservare abbastanza da vicino alla velocità con cui oggi si muove l’AI, quindi l’osservazione, e una quota crescente della costruzione, passa ad agenti che non si stancano e non vanno nel panico.

Sostiene di trattare l’osservabilità come un control plane, non come un insieme di grafici. Se gli agenti scriveranno, testeranno, distribuiranno e gestiranno il software, hanno bisogno dello stesso ancoraggio ai dati di produzione reali su cui fanno affidamento i bravi ingegneri, più una persona che tenga le decisioni di giudizio e il pulsante di stop. Datadog sta posizionando l’osservabilità come lo strato che rende sicuro questo equilibrio.

L’abilità che questa impostazione richiede agli ingegneri è chiara: leggere i sistemi in base a come si comportano in produzione, non solo dal loro sorgente. Se vuoi costruire questa abitudine, il nostro skill track Machine Learning in Production è un buon posto da cui partire.