Como o Kronos Automatiza a Resposta a Incidentes de Produção

“Outros modelos continuavam apontando para a mesma coisa repetidamente, mesmo depois de termos corrigido. Quando testamos o Enter Pro, ele descobriu qual era a causa real.”

A WhyVenv construiu o Kronos, um agente autônomo de resposta a incidentes para o Quackathon, para ajudar engenheiros a irem de erros de produção à causa raiz mais rapidamente.

---

O Pager é Apenas o Começo

Quando a produção falha, o alerta raramente é a parte difícil.

O Grafana pode dizer que algo está fora do ar. Os logs podem dizer que algo falhou. Um painel pode piscar em vermelho alto o suficiente para acordar alguém às 2h da manhã.

Mas depois disso, o trabalho real começa.

Um engenheiro ainda precisa abrir os logs, entender o erro, pesquisar na base de código, adivinhar qual função importa, decidir se o problema é urgente e descobrir se o próximo passo correto é uma issue no GitHub, um patch ou uma escalada completa.

Essa lacuna entre saber que algo quebrou e entender o que quebrou é onde a resposta a incidentes se torna dolorosa.

Foi também aí que Dawood Khan encontrou a ideia para o Kronos.

Dawood estudou IA, mas depois da faculdade se aproximou da engenharia de sistemas. Seu interesse não era abstrato. Ele tinha visto como os sistemas de produção falham, como as equipes respondem e quanta investigação manual ainda existe entre um alerta e uma correção.

Em um evento do Grafana em Hyderabad, o problema ficou ainda mais claro. Os engenheiros descreviam o mesmo padrão: o sistema cai, alguém recebe a ligação e então a equipe começa o trabalho familiar de rastrear a falha manualmente.

O Quackathon se tornou o momento de construir algo diferente. Desenvolvido pela WhyVenv, o Kronos conquistou o Segundo Lugar no Quackathon, destacando-se no desafio Track 01: Software - The Sentient Workspace por transformar a resposta a incidentes de produção em um fluxo de trabalho baseado em agentes.

---

O Que a WhyVenv Construiu

O projeto da WhyVenv foi o Kronos, um agente autônomo de resposta a incidentes construído para a trilha Sentient Workspace do Quackathon.

A ideia era simples, mas ambiciosa:

O Kronos recebe erros de produção, lê os logs, recupera o código relevante, pede a um modelo de IA para diagnosticar a causa raiz provável e, em seguida, decide o que deve acontecer a seguir.

Às vezes, isso significa abrir uma issue no GitHub.

Às vezes, dependendo da gravidade do problema, significa tentar uma correção.

O objetivo não é apenas notificar o engenheiro de que a produção está quebrada. O objetivo é dar ao engenheiro uma vantagem inicial no trabalho que normalmente se segue ao alerta.

Nas palavras de Dawood durante a entrevista, os alertas do Grafana facilitavam saber quando algo estava fora do ar. O problema era tudo o que vinha depois: descobrir o que causou o problema, onde o bug estava e qual ação a equipe deveria tomar.

O Kronos foi construído para automatizar essa camada intermediária.

---

A Visão de Engenharia por Trás do Kronos

“A parte de que mais me orgulhei foi a etapa de recuperação. Em vez de usar apenas ASTs ou embeddings, trabalhamos a partir dos logs de rastreamento, porque é assim que os engenheiros costumam encontrar o problema.”

A parte de que Dawood mais se orgulhou não foi o painel, a integração com o GitHub ou mesmo o diagnóstico por IA.

Foi a etapa de recuperação.

Muitos sistemas de codificação por IA tentam entender uma base de código por meio de embeddings, análise de AST ou carregamento de contexto amplo. O Kronos seguiu um caminho mais nativo para engenheiros: começar a partir dos logs de rastreamento e usá-los para estreitar a busca.

Essa escolha importa.

Quando engenheiros depuram falhas de produção, eles raramente começam pedindo a um modelo de IA para ler todo o repositório. Eles olham para o erro. Eles seguem o stack trace. Eles fazem um grep no código. Eles vão do sintoma à origem.

O Kronos foi projetado com base nesse mesmo instinto.

O sistema usa logs como ponto de entrada, recupera o código que parece mais relevante e só então traz o modelo de IA para o fluxo de trabalho. Isso faz com que o modelo seja menos um oráculo que tudo vê e mais um revisor trabalhando a partir de um pacote focado de evidências.

Dawood foi claro ao dizer que a abordagem ainda precisa de refinamento antes de ser confiável em grande escala. Mas para a demonstração, funcionou. Mais importante, refletiu um instinto sério de produto: os melhores sistemas de IA não substituem o fluxo de trabalho de engenharia às cegas. Eles aprendem com a forma como os engenheiros já resolvem problemas.

---

Construindo a Stack de Observabilidade Com o Enter Pro

O Kronos precisava funcionar com ferramentas que a equipe não havia utilizado profundamente antes.

Grafana. Prometheus. Loki. Painéis. Logs. Métricas. Alertas.

Para uma equipe de hackathon, isso é muita infraestrutura para entender antes mesmo que o produto real possa começar a funcionar.

Foi aqui que o Enter Pro se tornou útil para a WhyVenv.

A equipe usou o Enter Pro ao longo de todo o projeto para pesquisa, refinamento de ideias e depuração. Dawood e seus colegas de equipe o usaram para entender a stack de observabilidade, descobrir como os componentes se encaixavam e superar problemas de integração quando o sistema não estava se comportando como esperado.

Um momento se destacou.

A equipe estava travada em entender por que seus alertas de dados não estavam chegando corretamente. Eles haviam tentado outros modelos de IA, mas Dawood sentiu que alguns deles continuavam dando voltas no mesmo ponto, mesmo depois que a equipe já o havia corrigido.

Quando testaram o Enter Pro, ele os ajudou a identificar a causa real de forma mais direta.

Esse é o tipo de momento que importa em uma maratona de desenvolvimento. Não uma resposta polida de demonstração. Não uma sugestão genérica. Um empurrão concreto através de um bloqueador real.

Para a WhyVenv, o Enter Pro não era apenas um lugar para gerar código. Era uma forma de raciocinar sobre sistemas desconhecidos rapidamente o suficiente para continuar construindo.

---

Dois Dias de Foco

Dawood havia planejado o projeto antes de a equipe começar o desenvolvimento sério.

Ele sabia o que queriam construir. Ele havia pensado na arquitetura básica. Ele tinha uma noção aproximada de como o trabalho deveria ser dividido.

Então o ritmo real do hackathon assumiu o controle.

O primeiro dia não foi só código. A equipe passou um tempo junta, conversou, brincou e encontrou seu ritmo. O desenvolvimento real veio depois disso: uma maratona concentrada onde dividiram o trabalho, pesquisaram partes desconhecidas, implementaram o fluxo principal e refinaram o produto até que ele fizesse sentido.

A arquitetura começou simples:

relatório de falha -> código relevante -> diagnóstico de LLM -> issue ou correção.

Depois, cada parte se tornou mais nítida à medida que a equipe construía.

Essa simplicidade é parte do motivo pelo qual o Kronos é atraente. Ele não começa com uma teoria complicada de software baseado em agentes. Ele começa com um fluxo de trabalho que todo engenheiro de plantão entende: algo quebrou, encontre a causa, decida o que fazer a seguir.

---

O Que o Kronos Sugere Sobre Agentes de IA

O Kronos não é um chatbot sentado ao lado de uma base de código.

Ele está mais próximo de um agente de fluxo de trabalho: um sistema que recebe um sinal do mundo real, reúne as evidências corretas, pede raciocínio apenas onde o raciocínio é útil e, em seguida, direciona o resultado para as ferramentas que os engenheiros já usam.

Essa distinção importa.

Dawood é sensível aos problemas de custo e controle em torno dos sistemas de IA. Na entrevista, ele falou sobre o uso de tokens, chamadas de modelo caras e a importância de não deixar um agente cuidar de tudo quando a lógica determinística de backend pode fazer parte do trabalho de forma mais eficiente.

Esse é um instinto maduro para quem está construindo com IA em 2026.

O futuro dos agentes de IA não será apenas sobre o uso de modelos mais fortes. Será também sobre saber quando não usá-los. Quais partes devem ser código? Quais partes devem ser recuperação? Quais partes devem ser raciocínio de modelo? Quais partes devem permanecer sob revisão humana?

O Kronos, mesmo como um projeto de hackathon, aponta para essa questão.

---

O Que Vem a Seguir

O projeto ainda tem perguntas a responder antes de se tornar pronto para produção:

• Quão bem a abordagem de recuperação escala em bases de código maiores?

• Como a gravidade e a autonomia devem ser calibradas?

• Quando um agente deve abrir uma issue em vez de tentar uma correção?

• Quanto contexto é suficiente para um modelo diagnosticar um incidente real?

• O que os humanos devem aprovar antes que qualquer coisa chegue à produção?

Essas não são perguntas pequenas. São exatamente as perguntas que fazem o Kronos valer a atenção.

Porque os incidentes de produção não vão desaparecer. A única questão é se toda resposta precisa começar com pânico manual.

O Kronos imagina um primeiro passo diferente: um onde o sistema que vê a falha também pode começar a entendê-la.

É para apoiar isso que o Enter existe.

Não apenas código mais rápido. Movimento mais rápido de um ponto de dor real para um produto funcional.

E para a WhyVenv, esse movimento foi suficiente para transformar um padrão doloroso de engenharia em um dos projetos vencedores do Quackathon.

---

Explore o Kronos.

Esta história faz parte da nossa Série de Construtores do Quackathon, onde analisamos um projeto de cada vez para entender o que os desenvolvedores criaram com o Enter Pro, por que o construíram e o que seu trabalho nos diz sobre o futuro da criação de software impulsionada por IA. Fique atento.