As equipes de engenharia estão gerando mais código com agentes de IA do que nunca. Mas eles estão se deparando com um obstáculo quando esse código chega à produção.
O problema não é necessariamente o próprio código gerado pela IA. Acontece que as ferramentas de monitoramento tradicionais geralmente lutam para fornecer os dados granulares em nível de função que os agentes de IA precisam para entender como o código realmente se comporta em ambientes de produção complexos. Sem esse contexto, os agentes não conseguem detectar problemas ou gerar correções que levem em conta a realidade da produção.
É um desafio que a startup Hud está procurando ajudar a resolver o problema com o lançamento de seu sensor de código de tempo de execução na quarta-feira. O sensor homônimo da empresa funciona junto com o código de produção, rastreando automaticamente como cada função se comporta, dando aos desenvolvedores um alerta sobre o que realmente está acontecendo na implantação.
“Cada equipe de software que constrói em escala enfrenta o mesmo desafio fundamental: construir produtos de alta qualidade que funcionem bem no mundo real”, disse Roee Adler, CEO e fundador da Hud, ao VentureBeat em entrevista exclusiva. “Na nova era de desenvolvimento acelerado por IA, não saber como o código se comporta na produção torna-se uma parte ainda maior desse desafio.”
O que os desenvolvedores de software estão enfrentando
Os pontos problemáticos que os desenvolvedores enfrentam são bastante consistentes em todas as organizações de engenharia. Moshik Eilon, líder de tecnologia do grupo Monday.com, supervisiona 130 engenheiros e descreve uma frustração familiar com as ferramentas de monitoramento tradicionais.
“Quando você recebe um alerta, geralmente acaba verificando um endpoint que tem uma taxa de erro ou alta latência e deseja fazer uma busca detalhada para ver as dependências downstream”, disse Eilon ao VentureBeat. “Muitas vezes é o aplicativo real e depois é uma caixa preta. Você obtém apenas 80% de latência downstream no aplicativo.”
A próxima etapa normalmente envolve trabalho de detetive manual em várias ferramentas. Verifique os registros. Correlacionar carimbos de data/hora. Tente reconstruir o que o aplicativo estava fazendo. Para problemas novos e profundos em uma grande base de código, muitas vezes as equipes não possuem os dados exatos de que precisam.
Daniel Marashlian, CTO e cofundador da Drata, viu seus engenheiros gastando horas no que ele chama de “imposto de investigação”. “Eles estavam mapeando um alerta genérico para um proprietário de código específico e, em seguida, vasculhando os logs para reconstruir o estado do aplicativo”, disse Marashlian ao VentureBeat. “Queríamos eliminar isso para que nossa equipe pudesse se concentrar inteiramente na correção, e não na descoberta”.
A arquitetura de Drata agrava o desafio. A empresa integra-se a vários serviços externos para fornecer conformidade automatizada, o que cria investigações sofisticadas quando surgem problemas. Os engenheiros rastreiam o comportamento em uma base de código muito grande, abrangendo módulos de risco, conformidade, integrações e relatórios.
Marashlian identificou três problemas específicos que levaram Drata a investir em sensores de tempo de execução. A primeira questão foi o custo da mudança de contexto.
“Nossos dados estavam dispersos, então nossos engenheiros tiveram que atuar como pontes humanas entre ferramentas desconectadas”, disse ele.
A segunda questão, observou ele, é a fadiga alerta. “Quando você tem um sistema distribuído complexo, os canais de alerta gerais tornam-se um fluxo constante de ruído de fundo, o que nossa equipe descreve como um efeito ‘ding, ding, ding’ que eventualmente é ignorado”, disse Marashlian.
O terceiro fator principal foi a necessidade de integração com a estratégia de IA da empresa.
“Um agente de IA pode escrever código, mas não pode corrigir um bug de produção se não puder ver as variáveis de tempo de execução ou a causa raiz”, disse Marashlian.
Por que os APMs tradicionais não conseguem resolver o problema facilmente
As empresas há muito confiam em uma classe de ferramentas e serviços conhecida como Application Performance Monitoring (APM).
Com o ritmo atual de desenvolvimento de IA de agência e fluxos de trabalho de desenvolvimento modernos, tanto Monday.com quanto Drata simplesmente não conseguiram obter a visibilidade necessária das ferramentas APM existentes.
“Se eu quisesse obter essas informações do Datadog ou do CoreLogix, teria apenas que ingerir toneladas de logs ou toneladas de spans e pagaria muito dinheiro”, disse Eilon.
Eilon observou que Monday.com usou taxas de amostragem muito baixas devido a restrições de custo. Isso significava que muitas vezes eles perdiam os dados exatos necessários para depurar problemas.
As ferramentas tradicionais de monitoramento de desempenho de aplicativos também exigem previsão, o que é um problema porque às vezes um desenvolvedor simplesmente não sabe o que não sabe.
“A observabilidade tradicional exige que você antecipe o que precisará depurar”, disse Marashlian. “Mas quando surge um problema novo, especialmente em uma base de código grande e complexa, muitas vezes você perde os dados exatos de que precisa.”
Drata avaliou diversas soluções nas categorias de engenharia de confiabilidade de sites de IA e resposta automatizada a incidentes e não encontrou o que era necessário.
“A maioria das ferramentas que avaliamos foram excelentes no gerenciamento do processo de incidentes, no roteamento de tickets, no resumo de threads do Slack ou na correlação de gráficos”, disse ele. “Mas muitas vezes eles paravam antes do código em si. Eles podiam nos dizer ‘O serviço A está inoperante’, mas não podiam nos dizer o porquê especificamente.”
Outro recurso comum em algumas ferramentas, incluindo monitores de erros como o Sentry, é a capacidade de capturar exceções. O desafio, de acordo com Adler, é que estar ciente das exceções é bom, mas isso não as conecta ao impacto nos negócios nem fornece o contexto de execução que os agentes de IA precisam para propor soluções.
Como os sensores de tempo de execução funcionam de maneira diferente
Os sensores de tempo de execução levam a inteligência até o limite onde o código é executado. O sensor do Hud funciona como um SDK que se integra a uma única linha de código. Ele vê todas as execuções de funções, mas envia apenas dados agregados leves, a menos que algo dê errado.
Quando ocorrem erros ou lentidão, o sensor coleta automaticamente dados forenses profundos, incluindo parâmetros HTTP, consultas e respostas ao banco de dados e contexto de execução completo. O sistema estabelece linhas de base de desempenho em um dia e pode alertar sobre desacelerações drásticas e discrepâncias que o monitoramento baseado em percentis não detecta.
“Agora obtemos todas essas informações para todas as funções, independentemente do nível em que estejam, mesmo para pacotes subjacentes”, disse Eilon. “Às vezes você pode ter um problema muito profundo e ainda o vemos muito rápido.”
A plataforma fornece dados por meio de quatro canais:
- Aplicativo web para monitoramento e análise centralizados
- Extensões IDE para VS Code, JetBrains e Cursor que mostram métricas de produção diretamente onde o código é escrito
- Servidor MCP que alimenta dados estruturados para agentes de codificação de IA
- Sistema de alerta que identifica problemas sem configuração manual
A integração do servidor MCP é crítica para o desenvolvimento assistido por IA. Os engenheiros da Monday.com agora consultam o comportamento da produção diretamente no Cursor.
“Posso apenas fazer uma pergunta ao Cursor: Ei, por que esse endpoint está lento?” Eilon disse. “Quando ele usa o Hud MCP, obtenho todas as métricas granulares e essa função é 30% mais lenta desde a implantação. Assim, também posso encontrar a causa raiz.”
Isso altera o fluxo de trabalho de resposta a incidentes. Em vez de começar no Datadog e detalhar as camadas, os engenheiros começam pedindo a um agente de IA para diagnosticar o problema. O agente tem acesso imediato aos dados de produção em nível de função.
De incidentes de vodu a soluções de minutos
A mudança da capacidade teórica para o impacto prático fica clara na forma como as equipes de engenharia realmente usam os sensores de tempo de execução. O que costumava levar horas ou dias de trabalho de detetive agora é resolvido em minutos.
“Estou acostumado a ter esses incidentes de vodu em que há um pico de CPU e você não sabe de onde veio”, disse Eilon. “Há alguns anos, tive um incidente desses e tive que construir minha própria ferramenta que pega o perfil da CPU e o despejo de memória. Agora só tenho todos os dados da função e vi engenheiros resolvendo isso muito rápido.”
Na Drata, o impacto quantificado é dramático. A empresa criou um comando interno de triagem que os engenheiros de suporte executam em seus assistentes de IA para identificar instantaneamente as causas principais. O trabalho de triagem manual caiu de aproximadamente 3 horas por dia para menos de 10 minutos. O tempo médio para resolução melhorou em aproximadamente 70%.
A equipe também gera um relatório diário de “Atenção” sobre erros de ganho rápido. Como a causa raiz já foi detectada, os desenvolvedores podem corrigir esses problemas em minutos. Os engenheiros de suporte agora realizam diagnósticos forenses que antes exigiam um desenvolvedor sênior. O rendimento de tickets aumentou sem expandir a equipe L2.
Onde esta tecnologia se encaixa
Os sensores de tempo de execução ocupam um espaço distinto dos APMs tradicionais, que se destacam no monitoramento de nível de serviço, mas lutam com dados granulares e econômicos em nível de função. Eles diferem dos monitores de erros que capturam exceções sem contexto de negócios.
Os requisitos técnicos para apoiar agentes de codificação de IA diferem da observabilidade humana. Os agentes precisam de dados estruturados em nível de função sobre os quais possam raciocinar. Eles não podem analisar e correlacionar logs brutos como os humanos fazem. A observabilidade tradicional também pressupõe que você pode prever o que precisará para depurar e instrumentar adequadamente. Essa abordagem falha com o código gerado por IA, onde os engenheiros podem não compreender profundamente todas as funções.
“Acho que estamos entrando em uma nova era de código gerado por IA e neste quebra-cabeça, esse quebra-cabeça de uma nova pilha emergente”, disse Adler. “Eu simplesmente não acho que a pilha de observabilidade da computação em nuvem se encaixe perfeitamente em como será o futuro.”
O que isso significa para as empresas
Para organizações que já usam assistentes de codificação de IA, como GitHub Copilot ou Cursor, a inteligência de tempo de execução fornece uma camada de segurança para implantações de produção. A tecnologia permite o que Monday.com chama de “investigação de agente”, em vez de salto manual de ferramentas.
A implicação mais ampla está relacionada à confiança. “Com o código gerado por IA, estamos obtendo muito mais código gerado por IA, e os engenheiros começam a não conhecer todo o código”, disse Eilon.
Os sensores de tempo de execução preenchem essa lacuna de conhecimento, fornecendo contexto de produção diretamente no IDE onde o código é escrito.
Para as empresas que buscam escalar a geração de código de IA além dos pilotos, a inteligência em tempo de execução aborda um problema fundamental. Os agentes de IA geram código com base em suposições sobre o comportamento do sistema. Os ambientes de produção são complexos e surpreendentes. Os dados comportamentais em nível de função capturados automaticamente da produção fornecem aos agentes o contexto necessário para gerar código confiável em escala.
As organizações devem avaliar se sua pilha de observabilidade existente pode fornecer de maneira econômica a granularidade exigida pelos agentes de IA. Se alcançar a visibilidade em nível de função exigir um aumento drástico nos custos de ingestão ou instrumentação manual, os sensores de tempo de execução poderão oferecer uma arquitetura mais sustentável para fluxos de trabalho de desenvolvimento acelerados por IA que já estão surgindo em todo o setor.
