Post histórico. Descreve a arquitetura do v1, incluindo o classificador de regex ponderado e o modelo de branch único disparado pelo CI. Boa parte do que este post descreve foi deliberadamente removida no v2; veja Deletando nosso classificador de regex e CI local-first: a virada para entender o que substituiu e por quê.
Quando um pipeline de CI falha, alguém do time tem que parar o que está fazendo, ler os logs, descobrir o que quebrou, corrigir, fazer push e esperar o pipeline passar. Esse ciclo se repete várias vezes por dia na maioria dos times de engenharia.
Agentes de IA podem automatizar esse loop inteiro. Aqui está a abordagem do Stitch.
Passo 1: Detectar a falha
Stitch roda como um job downstream no seu pipeline de CI. Quando um job upstream falha, o Stitch ativa. Ele não faz poll nem webhook. É disparado pelo próprio sistema de CI, o que significa latência zero e nenhuma dependência externa.
Passo 2: Ler e parsear os logs
Logs de CI são bagunçados. Contêm códigos de cor ANSI, timestamps, barras de progresso e milhares de linhas de saída. O Stitch tira o ruído e extrai as assinaturas de erro relevantes.
Ele agrupa erros por tipo: falhas de lint, erros de type check, falhas de teste, problemas de dependência, erros de build. Cada categoria tem uma estratégia de diagnóstico diferente.
Passo 3: Diagnosticar a causa raiz
É aqui que o modelo de IA justifica seu custo. O Stitch envia o contexto de erro limpo para um modelo de linguagem junto com os arquivos de fonte relevantes. O modelo não vê o repositório inteiro. Vê só os arquivos referenciados no trace do erro, mais suas dependências imediatas.
Esse contexto escopado é intencional. Previne alucinação de código irrelevante e mantém o uso de tokens previsível.
Passo 4: Gerar e validar a correção
O modelo produz um patch. O Stitch aplica localmente e re-executa as checagens que falharam. Se as checagens passam, a correção é commitada e enviada. Se falham, o Stitch reporta o diagnóstico e a tentativa para que um humano assuma com contexto completo.
Essa etapa de validação é crítica. Uma correção gerada por IA que não é testada é só uma sugestão. O Stitch trata toda correção como hipótese que precisa ser verificada.
Passo 5: Agrupar e deduplicar
Quando vários jobs falham pela mesma causa raiz, o Stitch agrupa. Se cinco arquivos de teste falham por um import faltando, o Stitch corrige o import uma vez e reporta a correção para todos os cinco jobs. Sem commits duplicados, sem trabalho redundante.
Trilhos de proteção
O Stitch opera dentro de fronteiras estritas:
- Branch único por pipeline. Todas as correções para uma execução de pipeline vão em um branch, um merge request.
- Sem force pushes. Nunca.
- Acesso a arquivos escopado. O agente só lê arquivos referenciados nos traces de erro.
- Auto-merge configurável. Desligado por padrão. Você revisa o MR antes de ele entrar.
O resultado
Times usando o Stitch reportam menos trocas de contexto para falhas triviais de CI. O ciclo corrigir-push-esperar para problemas comuns como erros de lint, imports faltando e incompatibilidades de tipo cai de 15 minutos para menos de 2. Mais importante, desenvolvedores continuam focados no trabalho que importa.
Pipelines de CI sempre vão quebrar. A questão é se um humano precisa estar no loop em toda falha.