A primeira versão do Stitch fazia o que prometia. Você adicionava dois jobs à sua config de CI, stitch-monitor e stitch-heal, apontava para uma imagem Docker pública e, na próxima vez que uma regra de lint ou um teste quebrasse, um merge request aparecia com um patch. Para o subconjunto de falhas que ele lidava bem, a experiência chegava perto do mágico.
Entregamos. Usamos nos nossos próprios repositórios. E ao longo de alguns meses, compilamos uma lista honesta das coisas que erramos. Este post é essa lista.
Ele morava no lugar errado
Stitch v1 era um cidadão do seu sistema de CI. Rodava como job downstream, ativado por falha upstream, e fazia todo o trabalho dentro do ambiente do pipeline. Parece limpo. Teve consequências que subestimamos.
Toda correção exigia um round trip completo de pipeline. Seu CI rodava, falhava, o Stitch rodava, commitava, dava push, seu CI rodava de novo. Mesmo num runner rápido, o loop de feedback era em minutos, às vezes dezenas de minutos. Para o tipo de erro que o Stitch tinha que lidar, um import faltando, uma divergência de formatter, uma anotação de tipo que o test runner não gostou, a correção em si levava um segundo e a verificação levava uma eternidade. O humano continuava esperando pela máquina, só que em outra sala.
Ele assumia que o agente morava em outro lugar
O v1 falava com um modelo de linguagem via API. Entregamos uma integração OpenRouter, um GitHubAdapter, uma classe StitchAgent. A história de onboarding era “traga sua própria API key”. Isso parecia um pedido pequeno. Na prática, significava que todo time que quisesse experimentar o Stitch tinha que criar conta num provedor, gerar uma chave, guardar nos secrets do CI e orçar tokens.
Enquanto isso, mais e mais desenvolvedores já tinham Claude Code ou Codex no laptop, já autenticados, já pagos pela assinatura pessoal ou do time. O Stitch v1 não sabia falar com nenhum desses. Pedia para o usuário pagar duas vezes.
Ele fez overengineering nas partes que dava para ver
O v1 entregou um classificador de regex. Uma engine ponderada que lia logs de CI, passava por cento e cinquenta padrões e separava erros em nove categorias: lint, formatting, types, build, CI config, test, complex types, logic, unknown. Cada categoria tinha um score de confiança. Cada categoria tinha uma estratégia de correção.
Era satisfatório construir. Também era, em boa parte, teatro. O agente do outro lado da API era capaz de ler um log bruto e descobrir o que deu errado. Nosso classificador era, no melhor dos casos, uma forma de manter o prompt curto. No pior, uma camada de tradução que introduzia seus próprios bugs. Quando o agente melhorou, mantivemos o classificador. Já tínhamos construído.
Ele dava push antes de saber
Auto-merge era uma flag. Desligada por padrão, mas divulgada. Uma correção entra, o re-run passa, o merge request pode fechar sozinho. Na prática, essa flag é um pé-na-jaca. CI passando é evidência de que a suíte de testes está feliz, não de que o patch era o certo. Vimos casos em que o agente silenciou um teste falho mudando a asserção, ficou verde, e o time perdeu o sinal por completo. A resposta do v1 era “revise todo MR”. A resposta do v2 precisava ser outra.
Ele escalava mal para o caso pequeno
O v1 assumia que o time tinha uma plataforma de CI rodando em algum lugar capaz de hospedar a imagem Docker, orçamento para compute extra em toda falha e alguém com autonomia para adicionar jobs na config do pipeline. Para uma startup de três engenheiros, eram três obstáculos antes da primeira correção. Para um desenvolvedor solo num projeto de lado, era um muro.
Os casos de falha em que o Stitch era melhor, as correções de limpeza de cinco minutos, eram exatamente os casos em que o time menor mais precisava de ajuda. E eram exatamente os times que o v1 não alcançava.
O que mantivemos
Nem tudo. Mas bastante coisa.
A ideia central, de que agentes de IA podem ler logs com falha, entender o problema e produzir um patch direcionado, estava certa. A insistência em validação, de que um patch que não re-roda limpo não é correção, estava certa. A noção de escalar depois de tentativas limitadas estava certa. Essas atravessaram para o v2 sem mudança.
A forma em volta não. O próximo post da série é sobre para onde levamos.