Kristin Isaac, CEO e Co-Fundadora da Strudel – Série de Entrevistas

Kristin Isaac, CEO e Co-Fundadora da Strudel, é uma líder de tecnologia empresarial veterana que ocupou cargos seniores no LinkedIn, Udemy, ESPN e Disney antes de lançar a Strudel. Ela agora se concentra em resolver um dos principais pontos de fricção nas organizações de software: a lacuna entre o suporte ao cliente e a engenharia. Na Strudel, ela está construindo uma plataforma impulsionada por IA que ajuda as equipes de suporte técnico a resolver problemas complexos mais rapidamente, conectando solicitações de suporte diretamente à inteligência de engenharia. Sua experiência em escalonar equipes, criar estratégias de marketing e impulsionar o crescimento em organizações globais ajudou a moldar o rápido crescimento inicial e a forte posição da Strudel no mercado de ferramentas de desenvolvedor e IA empresarial.

Strudel é uma plataforma de IA projetada para automatizar o suporte técnico avançado, analisando logs, dados de produção, repositórios de código e histórico de suporte para identificar causas raiz e recomendar soluções. Seu objetivo é reduzir o tempo e o esforço de engenharia necessário para resolver casos de suporte difíceis, especialmente os tipos de escaladas que normalmente consomem recursos técnicos seniores. Ao ligar o suporte diretamente a problemas técnicos subjacentes, a Strudel está se posicionando como uma ferramenta que pode tornar as operações de suporte empresariais mais rápidas, eficientes e escaláveis.

Você ocupou cargos de liderança em organizações como LinkedIn, Udemy e Disney antes de fundar a Strudel em 2025. Quais experiências desses cargos eventualmente a convenceram de que as equipes de engenharia precisavam de um novo tipo de plataforma de “inteligência de engenharia” impulsionada por IA, e como essa percepção moldou a fundação da Strudel?

Cada empresa em que trabalhei tinha uma versão diferente do mesmo problema. Na Disney, as apostas eram enormes – se uma plataforma de streaming fosse interrompida durante um grande lançamento, não era apenas um golpe na receita, era um momento de marca. No LinkedIn, a escala era implacável. Havia milhares de serviços gerando ruído, e até as melhores equipes lutavam para acompanhar. Na Udemy, eu vi uma equipe enxuta fazer coisas heroicas com ferramentas limitadas.

O que conectava todos os três e à experiência de meus co-fundadores, Shai Rubin e Brian Kaufman, liderando equipes de engenharia, era que os engenheiros estavam gastando mais tempo reconstruindo o contexto do que realmente resolvendo problemas. Alguém é chamado às 2h da manhã, e antes que possam começar a diagnosticar, estão vasculhando threads do Slack, dashboards, tickets do Jira, logs de implantação – apenas tentando entender o que mudou e quando. Eles estão basicamente jogando detetive antes de poderem fazer seu trabalho real. Isso é um desperdício de pessoas incrivelmente talentosas.

Eu continuei pensando: deve haver uma maneira mais inteligente de trazer à tona o que realmente importa, quando importa. Essa é realmente a semente da Strudel.

Muitas empresas medem o impacto financeiro do tempo de inatividade em termos de receita perdida ou penalidades de SLA. Em sua experiência, quais são alguns dos custos menos visíveis de interrupções que as organizações consistentemente subestimam?

O número da receita entra no deck da diretoria, mas o impacto de receita imediato é apenas uma fração do que a interrupção realmente custa. Os que eu vi as organizações consistentemente perderem se encaixam em algumas categorias.

A primeira é a confiança do cliente. As penalidades de SLA são uma construção legal – elas não capturam o cliente que silenciosamente cancela a assinatura ou o prospecto de empresa que viu a página de status no momento errado e escolheu um concorrente. Esse dano é lento, invisível e permanente de uma maneira que um cheque de reembolso simplesmente não é.

A segunda é a rotatividade e burnout de engenheiros. A fadiga de estar de plantão é real. Quando os melhores engenheiros são repetidamente puxados para incidentes de alto estresse – especialmente aqueles que poderiam ter sido evitados – eles começam a questionar se este é o lugar certo para construir sua carreira. Substituir um engenheiro sênior custa qualquer coisa entre uma e duas vezes o salário anual quando você fatora na contratação, treinamento e conhecimento institucional perdido. Ninguém coloca isso no pós-morte.

A terceira é o custo de oportunidade. Cada hora que uma equipe de engenharia gasta lutando contra incêndios é uma hora não gasta construindo um produto. Isso é difícil de colocar em uma planilha, mas quando somado ao longo de meses, silenciosamente explode sua estrada.

Os engenheiros são frequentemente tirados de construir novos recursos para responder a incidentes de produção. Como essa luta constante contra incêndios afeta a inovação do produto e o desenvolvimento de longo prazo?

Isso cria um imposto sobre a capacidade da equipe de engenharia de construir. Cada equipe tem uma quantidade finita de largura de banda, e quando uma parte significativa disso continua sendo redirecionada para incidentes, o efeito composto sobre o desenvolvimento de produtos é severo. Compromissos de estrada são perdidos. A dívida técnica não é paga. Recursos são enviados com menos rigor porque há pressão para recuperar o tempo perdido.

O que é particularmente prejudicial é a imprevisibilidade disso. Uma equipe pode planejar sua sprint com boas intenções, e então um incidente importante explode em uma terça-feira e tudo o mais se torna secundário. Esse tipo de imprevisibilidade sustentada torna quase impossível construir uma cultura de trabalho profundo – o que em última análise impulsiona os melhores resultados de engenharia.

Isso também cria um ciclo auto-reforçado. O investimento adiado significa mais incidentes, o que significa mais luta contra incêndios, o que significa ainda menos tempo para investir nos problemas subjacentes. Na Strudel, uma grande parte do que estamos construindo é especificamente para as equipes de SRE que vivem isso todos os dias.

A Strudel conecta dados de suporte ao cliente, logs, sistemas de produção e repositórios de código para identificar causas raiz mais rapidamente. Como a IA reúne esses diferentes sinais técnicos de uma maneira que as ferramentas de monitoramento tradicionais não podem?

As ferramentas de monitoramento tradicionais são fundamentalmente sistemas de alerta. Elas são ótimas para dizer que algo cruzou um limite – um pico de latência, uma taxa de erro aumentando, um pod quebrando. O que elas não podem fazer é raciocinar entre domínios.

Elas não sabem que o pico da taxa de erro no seu serviço de pagamentos aconteceu quatro minutos após uma implantação em uma dependência, e que um ticket de suporte ao cliente mencionando falhas de checkout entrou por volta da mesma época, e que a última vez que esse padrão apareceu nos logs foi seis meses atrás durante uma migração de banco de dados.

Essa correlação entre domínios é o que a IA possibilita. Podemos tratar um ticket do Zendesk, um commit do GitHub, um traço do Datadog (DDOG ) e um log do CloudWatch como parte de uma história unificada, em vez de pontos de dados isolados. A IA traz à tona não apenas o que está quebrado, mas o provável porquê e onde – e isso é fundamentado em evidências que um engenheiro humano pode realmente verificar e agir. Não estamos pedindo às equipes que confiem em uma caixa preta. Estamos dando a elas uma hipótese bem fundamentada e uma vantagem.

Você descreve a Strudel como entregando “inteligência de engenharia”. O que esse conceito significa na prática, e como ele difere de plataformas de observabilidade ou AIOps convencionais?

Kristin: A observabilidade é fundamentalmente sobre instrumentação e visibilidade – garantir que a telemetria esteja lá e que as equipes possam consultá-la. AIOps, na maioria de suas implementações atuais, é sobre reduzir o ruído de alerta por meio da correlação e detecção de anomalias baseadas em ML. Ambos são genuinamente valiosos, e nos integramos a eles.

Mas a inteligência de engenharia é uma camada acima. Estamos pegando o que a AIOps faz e expandindo sobre isso. Onde a AIOps diz que algo está errado, a inteligência de engenharia ajuda a entender por que está errado, onde começou e o que fazer sobre isso – puxando sinais de toda a pilha, incluindo fontes que as ferramentas de AIOps tradicionais nem sequer olham, como tickets de suporte ao cliente ou alterações de código. O objetivo não é apenas reduzir o ruído. É dar à sua equipe uma imagem completa e ação para que possam resolver o problema mais rapidamente e voltar a construir.

Pense nisso como a diferença entre um detector de fumaça e um investigador de incêndio. A observabilidade e a AIOps são o detector de fumaça – essencial, mas param no alarme. A inteligência de engenharia é o que vem depois: aqui está o que aconteceu, aqui está por quê, aqui está onde começou.

Agentes de IA estão sendo cada vez mais implantados para automatizar fluxos de trabalho técnicos complexos. Qual papel você vê os agentes de IA desempenhando no diagnóstico e resolução de incidentes de software nos próximos cinco anos?

Acho que a pergunta mais interessante não é o que os agentes farão – é o que os engenheiros pararão de fazer. Os melhores engenheiros com quem trabalhei não entraram nesse campo para gastar suas noites triando alertas ou procurando em logs por uma alteração de configuração que alguém fez em uma sexta-feira à tarde. Isso não é por que eles se tornaram bons em seu trabalho. Mas é o que uma grande parte de seu tempo é consumida.

Nos próximos cinco anos, acho que os agentes assumem muito desse trabalho – o trabalho de padrão de reconhecimento, montagem de contexto, trabalho repetitivo. Isso libera as pessoas para se concentrar nos problemas complexos, nas decisões arquitetônicas, nas coisas que realmente exigem julgamento humano.

O que é emocionante para mim é que isso não é apenas um estado futuro – estamos vendo isso se desenrolar agora, incluindo na Strudel. Todo o nosso roadmap está orientado para remover o trabalho administrativo e de manutenção das placas dos engenheiros. E o que estamos descobrindo, honestamente, é que isso muda o que é possível para uma equipe. Você pode construir mais, se mover mais rápido e fazer isso com menos pessoas – porque as pessoas que você tem estão se concentrando em estratégia e complexidade, em vez de pagar seus direitos sobre o trabalho repetitivo. Isso parece um deslocamento significativo em como as equipes são construídas e estruturadas em frente.

Muitas interrupções originam-se de pequenos bugs ou alterações de configuração que passam pelo teste. Como os sistemas de IA podem identificar padrões sutis em código, logs ou sinais de infraestrutura cedo o suficiente para prevenir incidentes importantes?

Bem elaborada, a IA tem uma vantagem real aqui, e não é porque ela é mais inteligente do que seus engenheiros – é porque ela nunca esquece e nunca dorme. Um humano pode não conectar um padrão sutil de log hoje a algo que aconteceu seis meses atrás em uma parte completamente diferente do sistema. A IA pode. Ela está assistindo a tudo, o tempo todo, e tem uma memória muito mais longa e ampla do que qualquer indivíduo em sua equipe.

Isso dito, há algo mais que ouvimos dos clientes muito: a prevenção é apenas tão boa quanto os dados subjacentes. Se os logs forem inconsistentes, incompletos ou siloizados em uma dúzia de ferramentas que não falam umas com as outras, a IA está trabalhando com uma imagem fragmentada. Lixo para dentro, lixo para fora – isso ainda é verdade. Passamos muito tempo com os clientes ajudando a pensar sobre a qualidade dos dados e instrumentação porque a melhor IA do mundo não pode trazer um sinal que nunca foi capturado no lugar.

Então, a resposta é ambos: sim, a IA pode pegar as coisas mais cedo e conectar os pontos que os humanos perdem. Mas as equipes que obtêm o maior valor disso são aquelas que também fizeram o trabalho para garantir que seus dados sejam realmente dignos de serem raciocinados.

As empresas frequentemente investem pesadamente em ferramentas de detecção, mas ainda lutam com o tempo médio de resolução. Quais são as principais barreiras que impedem as organizações de fechar a lacuna entre a detecção de incidentes e a resolução real da causa raiz?

A detecção é basicamente um problema resolvido neste ponto. A maioria das equipes tem alertas. Elas sabem que algo está errado. A lacuna é tudo o que acontece em seguida.

Quando um engenheiro é chamado, ele não entra em uma situação clara com todo o contexto relevante montado. Ele entra em uma bagunça. Ele tem que descobrir o que mudou, quando mudou, qual sistema tocou, se há um impacto no cliente, se está relacionado a algo que aconteceu na semana passada. Ele está puxando do Slack, dos dashboards, dos logs de implantação, dos tickets de suporte – fazendo esse trabalho de montagem manualmente, sob pressão, frequentemente no meio da noite.

Essa montagem de contexto é o gargalo. Não é que os engenheiros e as equipes de suporte técnico não saibam como resolver problemas – é que estão gastando os primeiros 30 a 60 minutos de cada incidente apenas tentando entender o que estão realmente olhando. É aí que a Strudel vive. Nossa tese é que, se você puder entregar a um engenheiro uma imagem coerente, comprovada por evidências, do que aconteceu e por quê – exatamente quando precisam – você dramaticamente comprime essa lacuna. O trabalho de resolução ainda é deles. Nós apenas os levamos à linha de partida muito mais rápido.

À medida que os sistemas de IA começam a analisar dados de produção, código-fonte e logs operacionais, quais considerações de governança ou segurança as equipes de engenharia devem ter em mente ao implantar essas ferramentas?

A coisa com a qual me sinto mais forte aqui é esta: os humanos ainda devem revisar o código que vai para a produção.

Eu conversei com muitos engenheiros sobre isso, e uma coisa que ouço repetidamente é que a IA escreve bugs de forma eficiente e inteligente. Realmente inteligente, na verdade. De uma maneira que pode ser genuinamente difícil de capturar – mesmo para engenheiros seniores que revisam o código cuidadosamente. Os bugs não são sempre óbvios. Podem parecer perfeitamente razoáveis à primeira vista.

Então, à medida que a IA escreve mais e mais do código que acaba em produção, acho que vamos ver mais desses problemas sutis e difíceis de detectar escorregarem – não porque alguém foi descuidado, mas porque a natureza dos bugs gerados por IA é diferente. Mais difícil de detectar em revisão. Mais difícil de capturar em teste.

Honestamente? Essa é uma das razões pelas quais acho que o caso do que a Strudel faz só se torna mais forte com o tempo. Se mais bugs estão fazendo seu caminho para a produção, a capacidade de encontrá-los e resolvê-los mais rápido se torna mais importante, não menos. A questão de governança não é apenas sobre controles de acesso a dados e permissões – embora essas coisas importem e as equipes devem ser cuidadosas sobre quais dados estão dando acesso a qualquer sistema de IA. É também sobre manter os humanos nos pontos de verificação certos, especialmente em torno de qualquer coisa que toque a produção.

Olhando para o futuro, você acha que o futuro da engenharia de confiabilidade mudará para uma infraestrutura de IA em primeiro lugar, onde sistemas autônomos monitoram, diagnosticam e até consertam problemas antes que os humanos estejam cientes deles? Se sim, como esse fluxo de trabalho futuro parece para os engenheiros?

Acho que estamos indo nessa direção, mas sou pragmático sobre o cronograma. Sistemas totalmente autônomos resolvendo incidentes de produção sem qualquer conhecimento humano – isso não é onde estamos, e não acho que estejamos lá nos próximos anos. E acho que isso está bem.

O que acredito é que o loop fica muito mais apertado e muito menos doloroso. O futuro que estou animado não é um onde os humanos são removidos da equação – é um onde os humanos integrados ao processo gastam seu tempo nas partes que realmente exigem humanos. Chamadas de julgamento. Situações novas. Um incidente que você nunca viu antes. A IA lida com o padrão de reconhecimento, a montagem de contexto, a triagem de rotina. Os engenheiros lidam com as decisões.

Para os engenheiros em si, acho que parece: menos tempo de plantão no meio da noite para coisas que não precisavam acordá-los, e mais tempo construindo sistemas que não quebram em primeiro lugar. A luta contra incêndios não some completamente. Mas se torna a exceção, em vez do estado padrão de ser um engenheiro em uma empresa que executa software em escala. Esse é um futuro digno de ser construído.

Obrigado pela grande entrevista, leitores que desejam aprender mais devem visitar Strudel.