Moshe Sambol, VP de Soluções de Cliente da Lightrun – Série de Entrevistas

Moshe Sambol, VP de Soluções de Cliente da Lightrun – traz mais de duas décadas de experiência abrangendo engenharia de software, arquitetura, infraestrutura de nuvem e liderança técnica voltada para o cliente. Antes de se juntar à Lightrun em 2022, ele passou quase uma década na Google, onde ocupou várias posições de liderança, incluindo Gerente de Engenharia de Cliente de Nuvem, ajudando organizações a adotar e dimensionar tecnologias da Nuvem da Google. No início de sua carreira, Sambol ocupou funções de engenharia e desenvolvimento de liderança na Oracle, Sun Microsystems, BMC Software e JPMorgan Chase. Na Lightrun, ele inicialmente liderou a Engenharia de Soluções Globais antes de se tornar VP de Soluções de Cliente, onde se concentra em ajudar os clientes a adotar a tecnologia de Insights de Tempo de Execução da empresa e traduzir suas capacidades em ganhos de produtividade de negócios e desenvolvedores mensuráveis.

Lightrun é uma plataforma de engenharia de confiabilidade nativa em IA projetada para dar aos desenvolvedores e agentes de IA visibilidade direta sobre como o software se comporta enquanto está em execução. Sua tecnologia pode capturar dinamicamente logs, instantâneos, métricas, rastros, valores de variáveis e contexto de execução de aplicativos ao vivo sem exigir alterações de código ou reimplementações. A empresa está estendendo cada vez mais essa inteligência de tempo de execução para o desenvolvimento de software assistido por IA por meio do Lightrun MCP, que usa o Protocolo de Contexto de Modelo para fornecer assistentes de codificação e ferramentas agênticas com contexto de aplicativo ao vivo em vez de confiar apenas em código fonte estático. Isso permite que os sistemas de IA investiguem problemas de produção, validem hipóteses contra o comportamento de execução real e apoiem a análise de causa raiz, incorporando controles de empresa, como acesso baseado em função e redação de dados sensíveis.

Sua carreira abrangeu desenvolvimento de software e arquitetura, engenharia de cliente de nuvem na Google, engenharia de soluções globais e agora soluções de cliente na Lightrun. Como essa combinação de construção de software e trabalho direto com clientes empresariais moldou sua compreensão do que separa uma demonstração impressionante de um agente de IA de um sistema que pode ser confiável em produção?

Há uma grande diferença entre mostrar o que um agente de IA pode fazer e provar que pode ser confiável em um ambiente empresarial. Isso ocorre porque os agentes são apenas uma parte de um sistema pronto para produção. O framework ao seu redor é igualmente importante. Ele deve impor acesso de privilégio mínimo, monitorar a atividade, preservar um registro de auditoria, prevenir ações inaceitavelmente arriscadas e trazer um humano quando necessário.

Os sistemas agênticos são intrinsicamente diferentes do software tradicional, pois os desenvolvedores não prescrevem exatamente como o sistema funcionará. Nós definimos um objetivo, fornecemos ferramentas e orientação, e o modelo determina como proceder. Essa flexibilidade é poderosa, mas também torna o comportamento do sistema mais difícil de prever.

Para as empresas, especialmente aquelas em setores regulamentados, fluxos de trabalho de produção que geralmente funcionam ou levam um tempo imprevisível para serem concluídos são inviáveis. Ambientes de produção contêm dados sensíveis, código fonte e propriedade intelectual, então as organizações precisam ser capazes de prevenir que os agentes exponham essas informações ou tomem rotas criativas, mas inaceitáveis, para alcançar seus objetivos. Isso está se tornando cada vez mais importante, pois cada semana traz um novo exemplo de um sistema de IA que, em sua busca por alcançar um objetivo, acaba vulnerável a ou causa uma exploração de segurança.

A maioria dos líderes com quem falo ainda avalia os agentes da mesma forma que avaliariam um novo funcionário: por capacidades, julgamento e saída. A verdadeira pergunta não é se o agente é inteligente o suficiente. É se o sistema ao seu redor pode capturar e conter os momentos em que não é.

Muitas empresas inicialmente acreditavam que construir um agente de IA era basicamente uma questão de escrever um prompt eficaz. O que as organizações não entenderam sobre os requisitos de engenharia, arquitetura e operacionais por trás dos agentes prontos para produção?

Acho que o maior mal-entendido foi uma crença quase ingênua no poder da IA para resolver qualquer desafio, desde que receba um prompt bem escrito, contexto relevante e ferramentas adequadas. As equipes conectaram seu LLM ao código, documentação, tickets e telemetria histórica, e então esperavam que ele raciocinasse com precisão para a decisão certa.

O que elas não construíram foi um modelo de verificação para cada etapa do raciocínio da IA. Uma das grandes forças da IA é que ela usa raciocínio probabilístico, encontrando e tomando uma das muitas rotas possíveis para alcançar um destino. Em ambientes de produção complexos e interconectados, essa força introduz um risco sério: uma única decisão pode desencadear regressões downstream, falhas silenciosas ou outros comportamentos inesperados que ameaçam a resiliência operacional de um sistema em execução.

A parte perigosa é que o agente pode continuar a parecer funcionar corretamente enquanto produz respostas incorretas, mas plausíveis, construídas a partir de dados parciais ou suposições enraizadas em informações desatualizadas. É por isso que os agentes de produção precisam de avaliação contínua que continue a ser executada após o lançamento, manipulação explícita de dados ausentes e falhas de ferramentas, e verificação ao vivo de uma decisão antes de concluir uma ação de alto impacto.

Ao olhar para a primeira onda de agentes internamente desenvolvidos pelas empresas, quais são os erros arquitetônicos mais comuns que você está vendo, e quais problemas podem ser corrigidos incrementalmente em vez de exigir uma reconstrução completa?

A preocupação central que continuo a encontrar é a validação. Os agentes podem se tornar uma caixa preta: eles coletam informações de uma variedade de fontes e então tomam decisões que parecem razoáveis em princípio, mas podem não ser apropriadas para as realidades de um ambiente de produção complexo e bagunçado.

Isso aponta para uma mudança fundamental, e é algo que discutimos constantemente na Lightrun enquanto ajudamos os clientes a construir automações agênticas para suas organizações de engenharia. As equipes precisam reconstruir o próprio fluxo agêntico e colocar portas nas ações do agente, para garantir que o uso das ferramentas seja submetido à supervisão, auditoria e revisão. Fornecer ao agente uma forte retroalimentação – incluindo observabilidade de tempo de execução ao vivo – concentra seu contexto no que está realmente acontecendo agora. É esse acesso que permite que o agente valide suas próprias decisões de design, análise de causa raiz e recomendações de mitigação de erros contra a realidade de produção, em vez de contra suposições baseadas em análise estática de código ou telemetria antiga.

Uma reconstrução dramática não é a única opção. O que pode ser feito incrementalmente, e isso não é revolucionário, mas é essencial, é investir nas habilidades que guiam o comportamento do agente. Habilidades cuidadosamente elaboradas e avaliadas empurram o agente na direção de um fluxo de trabalho determinístico. As equipes não precisam reprojeter todo o sistema para obter esse benefício. Elas precisam tratar o design de habilidades com a mesma rigorosidade que dariam a qualquer outra lógica de produção.

Por que alguns agentes performam bem durante testes controlados, mas começam a produzir resultados inconsistentes, incompletos ou enganosos quando expostos a usuários reais, dados em mudança, ferramentas externas e ambientes de produção complexos?

Os testes controlados removem a maioria da variabilidade que definirá a realidade de produção com a qual a IA precisa lidar. Os dados são curados, o comportamento da ferramenta é previsível, as permissões são conhecidas, e cobrimos um caminho que antecipamos. Quando você libera um agente para interagir com usuários reais e seus efeitos em sistemas ao vivo, você não está comparando coisas semelhantes.

Os usuários introduzem solicitações ambíguas e executam ações concorrentes, o estado do sistema está em constante fluxo, o agente frequentemente precisa trabalhar a partir de dados parciais, e as ferramentas externas trazem sua própria latência e modos de falha em cima disso. Porque o modelo é probabilístico, cada nova variável cria outro lugar onde o fluxo de trabalho pode divergir ou compor um erro anterior.

A parte perigosa é que o agente pode continuar a parecer funcionar corretamente enquanto produz respostas incorretas, mas plausíveis, construídas a partir de dados parciais ou suposições enraizadas em informações desatualizadas. É por isso que os agentes de produção precisam de avaliação contínua que continue a ser executada após o lançamento, manipulação explícita de dados ausentes e falhas de ferramentas, e verificação ao vivo de uma decisão antes de concluir uma ação de alto impacto.

A Lightrun dá grande ênfase em dar aos sistemas de IA acesso ao contexto de tempo de execução. Qual informação o contexto de tempo de execução fornece que os logs, métricas e rastros convencionais podem perder, e por que essa informação é particularmente importante para diagnosticar falhas de agente?

A observabilidade convencional mostra os sintomas externos do comportamento do sistema, frequentemente agregados, amostrados ou filtrados por meio de dashboards e alertas que são acionados por limites. Eles geralmente dependem de decisões feitas pelos desenvolvedores no momento em que o código foi escrito: o que será de interesse no futuro? O que vale a pena registrar ou medir? O contexto de tempo de execução desacopla a visibilidade dessa necessidade de saber antecipadamente o que pode ser de interesse e fornece dados granulares mostrando o que está acontecendo sob o capô e como chegamos lá.

A verdadeira lacuna é entre dados estáticos e dinâmicos. Os logs, métricas e rastros convencionais são estáticos e produzem uma conta histórica do que aconteceu. O contexto de tempo de execução da Lightrun é dinâmico. Ele dá ao agente a capacidade de colocar nova instrumentação em código em execução, sob demanda, e observar os valores exatos de variáveis, argumentos de função, estado de objeto, pilha de chamadas ou condições de branch à medida que ocorrem.

Essa distinção é particularmente importante para diagnosticar falhas em código gerado por agente, porque essas são frequentemente silenciosas. Um agente pode escolher a ferramenta errada, passar o argumento errado ou agir com base em uma suposição desatualizada, e ainda concluir sua tarefa sem acionar qualquer erro. Uma falha como essa não será mostrada na telemetria estática, porque ninguém sabia antecipadamente instrumentar para isso. Comportamento inesperado requer uma investigação dinâmica direta no sistema em execução, colocando nova instrumentação exatamente onde o modelo do agente divergiu da realidade, em vez de confiar no que já estava sendo registrado.

É isso que torna o contexto de tempo de execução dinâmico a camada de verificação natural para decisões geradas por IA na engenharia.

Como o Protocolo de Contexto de Modelo (MCP) e camadas de integração semelhantes podem permitir que os agentes de codificação aprendam com o comportamento de execução real sem dar-lhes acesso excessivo ou inseguro a sistemas de produção?

O MCP e outros controles de acesso a ferramentas externas (por exemplo, wrappers de CLI) permitem que um agente chame uma capacidade específica e dimensionada, em vez de ter acesso amplo a um sistema e ser confiável para se comportar. Um agente conectado por meio de um servidor MCP para contexto de tempo de execução pode solicitar evidências somente leitura, o valor de uma variável, um caminho de chamada, se um limite foi excedido, sem tocar no acesso de gravação, sem a capacidade de reimplementar nada e sem precisar de credenciais permanentes para o ambiente subjacente.

Quando redesenhando um agente de primeira geração, como as empresas devem abordar permissões de ferramenta, memória, recuperação de dados, avaliação, supervisão humana e procedimentos de fallback como partes de uma arquitetura coesa em vez de recursos separados?

Você não pode acoplar essas peças independentemente, porque cada uma muda as outras. Os melhores lugares para começar são o framework, a estrutura que controla o loop do agente e a orquestração geral do fluxo de trabalho que liga vários agentes e outros atores. Para um fluxo de trabalho de análise de causa raiz, por exemplo, as equipes devem decidir qual evidência é necessária, quais sistemas o agente pode inspecionar, se ele pode publicar uma conclusão ou apenas rascunhá-la, quando um humano deve aprovar a próxima etapa e o que acontece se a evidência de tempo de execução não estiver disponível.

Uma vez que esse contrato esteja claro, a estrutura e o framework fornecem os mecanismos com os quais impor essas diretrizes. Gateways MCP podem ser aproveitados para limitar o acesso do agente a capacidades específicas relevantes para seu propósito. Ferramentas podem ser concedidas com privilégio mínimo. A memória pode ser supervisionada, com dados sensíveis redigidos deterministicamente. A recuperação pode ser projetada em torno da evidência de que o fluxo de trabalho precisa.

A avaliação, a supervisão e o fallback, então, fecham o loop. O sistema deve medir se as conclusões estão corretas e apoiadas, trazer um humano quando o risco ou a incerteza cruzam um limiar definido e parar ou recuar para uma recomendação somente leitura quando não puder reunir evidências suficientes. Um registro de auditoria compartilhado deve conectar o gatilho, as permissões, a evidência, as chamadas de ferramentas, as aprovações, a ação e o resultado. É isso que torna esses componentes uma arquitetura de produção em vez de seis recursos separados.

Quais salvaguardas devem cercar os agentes que podem inspecionar aplicativos ao vivo ou participar de fluxos de trabalho de engenharia de confiabilidade do site, particularmente em ambientes regulamentados onde controles de acesso, privacidade, auditoria e estabilidade operacional são críticos?

Essa foi uma das questões centrais de design quando construímos o Lightrun AI SRE. Um AI SRE opera perto de alguns dos sistemas mais sensíveis de uma organização, então o projetamos como um ator operacional privilegiado, não como um assistente de bate-papo. Uma decisão importante foi separar o plano de inspeção do plano de ação. O AI SRE coleta evidências por meio de integrações somente leitura e instrumentação de tempo de execução sandboxed da Lightrun, com acesso restrito por identidade, locatário, serviço e ambiente. Ele pode inspecionar a execução ao vivo e gerar evidências ausentes, mas a camada de inspeção de tempo de execução não pode modificar o estado do aplicativo.

Em um ambiente regulamentado, essa fronteira precisa ser apoiada por RBAC, SSO, isolamento de locatário, redação de PII, controles de retenção e um registro de auditoria que mostre quais ferramentas e evidências apoiaram cada conclusão. Também precisamos de limites operacionais em torno de quanto dados podem ser coletados, com que frequência o tempo de execução pode ser consultado e quais ações exigem aprovação. Se as evidências estiverem ausentes ou uma conclusão não puder ser verificada, o AI SRE deve dizer isso e passar a decisão para um humano, em vez de agir como se soubesse mais do que realmente sabe. O objetivo é autonomia controlada: útil o suficiente para acelerar uma investigação, mas contida o suficiente para permanecer segura para o sistema ao vivo.

À medida que as empresas avançam além de agentes experimentais, quais medições devem determinar se um agente está genuinamente pronto para produção, e como você espera que a relação entre os agentes de IA e os engenheiros humanos evolua nos próximos anos?

Eu julgaria a prontidão para produção pela frequência com que as ações de um agente de IA produzem os resultados desejados, suas conclusões se sustentam contra o que realmente era verdade em produção, conclusões não apoiadas são capturadas antes de qualquer ação e se o agente falha visivelmente e com segurança quando as evidências não estão presentes. Para agentes de engenharia, a precisão da conclusão verificada, a cobertura de evidências, o tempo para confirmar a causa raiz, a taxa de fallback bem-sucedida e os resultados pós-ação são as métricas principais nas quais devemos nos concentrar.

Nos próximos anos, espero que os agentes assumam mais da coleta de evidências e da primeira investigação, bem como da supervisão dos fluxos de trabalho agênticos e do aprendizado contínuo com experiência e feedback, enquanto os engenheiros estabelecem políticas, resolvem ambiguidades, aprovam ações de alto risco e orientam os sistemas agênticos autoaperfeiçoantes. A confiança será estendida fluxo de trabalho a fluxo de trabalho. Agentes que possam traçar suas conclusões de volta à evidência ao vivo e claramente divulgar o que não puderam verificar ganharão maior autonomia. Aqueles que não poderão permanecerão limitados a tarefas de baixo risco e baixa importância, independentemente de quão fluente eles soam. Obrigado pela ótima entrevista, leitores que desejam aprender mais devem visitar Lightrun.