Observabilidade de LLM: 6 lições do CTO da Datadog

Lição 1: a IA quebrou o jeito antigo de revisar código

Comecemos pela pressão que dispara todo o resto: há mais código do que qualquer pessoa consegue ler.

Lê-Quôc é franco ao dizer que o modelo antigo, um humano lendo um pull request linha a linha, não resiste ao desenvolvimento assistido por IA. A ansiedade que ele ouve pelo setor é que os reviews se tornaram inviáveis, porque acontece coisa demais para acompanhar lendo PRs.

A resposta dele não é pedir para as pessoas lerem mais rápido, e sim mover o review para outro lugar.

Esse último ponto passa fácil batido. Quando você orquestra um agente para planejar, outro para escrever e outro para testar, você também precisa impedir que o escritor manipule os testes automatizados em vez de resolver o problema.

Ele vai além dos testes. A Datadog agora adiciona provas semi-formais e formais de que uma spec faz o que deveria, algo muito trabalhoso para tentar amplamente antes de os agentes assumirem a parte pesada. Funciona melhor em sistemas de backend e coordenação, onde o comportamento é matemático o suficiente para raciocinar com precisão.

Lição 2: produção é o único teste que conta

Passar em todos os testes no CI é necessário e está longe de ser suficiente. As falhas que importam acontecem depois.

Cada release se apoia em pressupostos impossíveis de checar totalmente antes, sobre o formato dos dados e o comportamento dos usuários. Com tráfego real suficiente, os casos raros deixam de ser raros; viram as lentidões e erros do dia a dia causados por drift de dados e de modelos.

LLMs pioram isso: com código tradicional, ao menos dá para raciocinar sobre cada branch, mas ninguém explica mecanicamente por que um modelo retorna o que retorna, então a mesma entrada nunca garante a mesma saída. Resultados estranhos ocasionais não somem com engenharia.

Então, você para de tentar provar que o sistema está correto antes de enviar. Em vez disso, você

• Escreve avaliações para o comportamento desejado
• Monitora em produção
• Mantém um controle de parada para um rollout que azedar.

A pergunta deixa de ser se passou, e vira se o problema é um ponto fora da curva ou o início de uma tendência.

Esse sinal ao vivo não é só um dashboard para humanos. Integrado ao sistema de deploy, permite que um agente faça o rollout como um engenheiro cuidadoso: para 1% dos usuários, depois 5%, julgando com dados reais se a mudança está cumprindo o objetivo.

Lição 3: deixe os agentes ficarem com o trabalho braçal

O argumento de Lê-Quôc para agentes não é que eles substituem engenheiros, mas que assumem as partes do trabalho que desgastam as pessoas.

Resolver um incidente significa testar hipóteses contra um sintoma e, em incidentes longos, muitas vezes a hipótese improvável é a verdadeira. O agente Bits AI da Datadog verifica todas em paralelo, à frente do engenheiro, enquanto a pessoa direciona pela intuição que um dashboard não mostraria.

O ponto mais fundo é a fadiga. Um rollout em on-call é um pico de alerta seguido de horas de nada, repetido até o julgamento ficar comprometido.

Um agente não se incomoda e não piora depois de quatro horas encarando números. Estresse e fadiga degradam o desempenho humano, por isso os times fazem rodízio no on-call.

Entregue a vigia incansável à máquina e as pessoas voltam descansadas para as decisões que precisam delas. A mesma lógica vale para triagem de segurança, em que analistas se esgotam separando falsos positivos de ameaças reais.

Lição 4: divida o trabalho em dois ciclos

Lê-Quôc organiza o trabalho com agentes na Datadog em dois ciclos.

O ciclo de desenvolvimento

A maioria dos engenheiros vai reconhecer o primeiro ciclo:

1. Escrever código
2. Enviar
3. Ver se funcionou
4. Corrigir
5. Repetir

A abordagem da Datadog é que um problema que nasce no código normalmente tem sua correção no código, então a plataforma tenta te entregar essa correção, informada pelo que sabe sobre a aplicação: quem é dono, mudanças recentes e erros disparados.

Ele cita otimização de queries como exemplo. Qualquer modelo reescreve uma query lenta; o mais difícil é provar que a reescrita é mais rápida e segura antes de chegar à produção. Por isso, a Datadog testa contra uma cópia realista dos dados de produção e entrega um pull request com as evidências anexas.

O ciclo de operações e segurança

O outro ciclo roda em paralelo, pelo mesmo time ou por outro:

1. Detectar
2. Investigar
3. Corrigir
4. Repetir

Aqui, o AI Guard da Datadog faz a triagem de eventos de segurança e bloqueia ataques mais rápido do que um analista faria manualmente. Agentes também cuidam de tarefas operacionais rotineiras que engenheiros fazem diariamente sem muito entusiasmo, como redimensionar aquele único pod do Kubernetes.

Nos dois ciclos, Lê-Quôc é firme quanto à ordem das coisas. A Datadog não parte de "aqui está a IA, qual problema ela resolve?". Parte de um problema que os clientes já reclamam, geralmente alguma variação de "não quero fazer essa tarefa repetitiva", e só então avalia se um agente pode assumir com confiança.

Lição 5: mantenha os gastos com IA sob controle

Custo é a restrição ao lado da segurança, e manter o preço de operacionalizar grandes modelos de linguagem sob controle virou uma disciplina. A resposta de Lê-Quôc na DASH é o Agent Console da Datadog.

Pergunte a um developer qual modelo precisa e, muitas vezes, ele vai citar o mais poderoso (e caro). Às vezes é a escolha certa, mas muito trabalho é boilerplate que um modelo mais barato e rápido resolve tão bem quanto. Distinguir um do outro exige ler as trajetórias dos agentes da organização, quais ferramentas chamam e com que frequência têm sucesso, até surgirem padrões.

Esses padrões viram heurísticas, não regras: um modelo de fronteira como o último Claude Opus ou modelos GPT para planejamento, algo barato como o Claude Haiku para gerar testes.

O princípio por trás é sobre quem decide. Se você agrega custo em um número único, cai no que Lê-Quôc chama de "baixíssima acionabilidade": ou todo mundo para de gastar, matando trabalho útil, ou todo mundo segue gastando, o que o negócio não sustenta. Melhor colocar os dados diante de developers e SREs que escolhem os modelos.

Lição 6: aprenda a aprender

Quando perguntam o que engenheiros iniciantes devem estudar, Lê-Quôc dá uma resposta que soa antiga, mas não é.

Modelos são os tutores mais pacientes já inventados, capazes de explicar qualquer coisa no ritmo que você precisar — um nível de acesso que já foi privilégio de reis com professores particulares. Mas um tutor só é útil se você o interroga. A habilidade é saber o que perguntar e como checar a resposta.

Ele recomenda entender computadores camada por camada, em vez de tratá-los como mágica. Pegue um scheduler, um balanceador de carga, um sandbox, e peça para um modelo explicar como funciona; depois, continue insistindo:

• O que este termo significa?
• Como você mede isso?
• Qual é a matemática por trás disso?
• Como você sabe que está funcionando bem?

Estudar os clássicos desse jeito é lento de propósito. Ele compara a aprender um instrumento: você pode ouvir música o dia todo, mas, para tocar piano, precisa colocar as mãos nas teclas.

O mesmo vale para código escrito por IA. Vibe coding tudo bem, ele diz, desde que você volte e pergunte por que funcionou: por que foi feito assim, se existem abordagens melhores, em que foi inspirado. O objetivo não é escrever menos código com IA, e sim entender o código que agora você produz em muito maior volume.

Considerações finais

A mensagem central de Lê-Quôc é que o ciclo não mudou, mas o ritmo sim. O que muda é que nenhum humano consegue observar de perto na velocidade em que a IA agora opera, então a observação — e uma parcela crescente da construção — vai para agentes que não cansam e não entram em pânico.

Ele defende tratar observabilidade como plano de controle, não um conjunto de gráficos. Se agentes vão escrever, testar, entregar e operar software, precisam do mesmo lastro em dados reais de produção de que bons engenheiros dependem, mais uma pessoa com o julgamento e o botão de parada. A Datadog está posicionando a observabilidade como a camada que torna essa troca segura.

A habilidade que essa visão pede dos engenheiros é clara: ler sistemas pelo comportamento em produção, não só pelo código-fonte. Se você quer criar esse hábito, nossa trilha de habilidades Machine Learning in Production é um bom ponto de partida.