Toda ferramenta próxima de CI lançada nos últimos dezoito meses chega com o mesmo pitch: conecta teu repo, entrega teu pipeline, deixa nosso agente consertar as falhas. A forma do pedido é idêntica, mesmo que os produtos não sejam. Gitar quer teu repo na nuvem deles. Nx Cloud quer que tu reorganize teu grafo de build no monorepo deles. Dagger quer que tu reescreva teu YAML no SDK deles. Cada um tem uma razão defensável. Nenhuma dessas razões tira do teu time o custo da migração.
O Stitch foi construído em torno de outra observação. O desenvolvedor já tem o pipeline, já é dono da máquina e, cada vez mais, já tem um agente de IA autenticado dentro do terminal. A tarefa não é introduzir um novo plano de controle. A tarefa é conectar as três coisas que já existem.
Este post fala das partes da comparação que não cabem em uma matriz de features.
O mercado se divide em três
Quando tu olha os produtos de perto, a categoria AI-CI não é um único mercado. São três.
- Plataformas de refactor na nuvem como Gitar. Sobe o código no ambiente deles, deixa o agente deles fazer mudanças em larga escala, baixa o resultado. Otimizadas para modernização pontual em escala.
- SaaS de grafo de build como Nx Cloud. Reestrutura o repo num workspace, empurra o grafo para o cache deles, recebe execução distribuída e cache remoto. Otimizadas para monorepos grandes com builds caros.
- Engines de pipeline programáveis como Dagger. Substitui o YAML por código, roda o pipeline na engine deles dentro de containers, ganha reprodutibilidade e portabilidade. Otimizadas para times cujo YAML de CI virou ingerenciável.
O Stitch não é nenhum dos três. É uma quarta categoria: um loop de verificação local-first que lê a tua config de CI existente e roda na tua máquina com o agente de IA que tu já usa.
Matriz de capacidades
| Capacidade | Stitch | Gitar | Nx Cloud | Dagger + IA |
|---|---|---|---|---|
| Usa tua config de CI existente | Sim | Não | Não | Não |
| Roda jobs em local | Sim | Só nuvem | Nuvem + local | Containers |
| Agente de IA plugável | Qualquer CLI | Só built-in | Só built-in | Só built-in |
| Requer infra nova | Nenhuma | Conta SaaS | Workspace Nx | SDK do Dagger |
| Integração nativa com Claude Code | Vem com uma skill | Não | Não | Não |
| Preço | Grátis, MIT | Planos pagos | OSS grátis + Cloud pago | Engine OSS grátis + Cloud pago |
A matriz subestima o que está acontecendo de verdade. A parte interessante é o que cada linha implica para um time de engenharia três meses depois.
O que “usa tua config de CI existente” significa de verdade
Se uma ferramenta lê .github/workflows/*.yml ou .gitlab-ci.yml direto, teu CI continua sendo a fonte da verdade. O pipeline que tu manda para produção é o pipeline que o loop de verificação roda. Drift é impossível por construção.
Se uma ferramenta exige traduzir teu pipeline para um formato novo (SDK do Dagger, grafo de projeto Nx, YAML SaaS do fornecedor), agora tu tem dois pipelines. Um tu empurra para o CI. Um a ferramenta local entende. Toda mudança em um precisa ser espelhada no outro. Na prática, o espelho fica desatualizado. Na prática, a ferramenta local diverge devagar da produção. Na prática, “passa em local” deixa de significar “passa no CI”.
A migração não é o custo. A manutenção contínua de duas configs é o custo. O Stitch desvia disso se recusando a ser dono da config.
Execução local não é só uma história de latência
Ferramentas só-nuvem vendem escala. A leitura honesta é: vendem escala porque nuvem é o único modo que oferecem. Não existe um CLI local que tu possa rodar num laptop sem um round trip de rede. Isso tem três consequências que ninguém coloca numa página de vendas.
- Teu código sai da máquina. Cada iteração manda diffs para um backend SaaS. Em ambientes regulados, isso é uma revisão de compliance.
- Tu paga por minuto de compute. Um workflow de feedback rápido num runner lento fica caro rápido.
- Tu herda a disponibilidade deles. Quando o SaaS tem um incidente, teu loop de verificação para.
Local-first inverte os três. Os jobs do Stitch rodam na máquina onde mora o editor. Nada sai a menos que tu configure um canal de notificação que mande. Não existe backend do Stitch para cair.
”Agente de IA plugável” é a única resposta honesta
Gitar, Nx Cloud e os features de IA parafusados no Dagger Cloud vêm todos com um único agente proprietário. A escolha é do fornecedor, o custo é a fatura do fornecedor, a cadência de upgrade do modelo é o roadmap do fornecedor.
O Stitch não tem agente. Ele invoca o agente que tu já usa: Claude Code, Codex, qualquer coisa compatível com CLI. As credenciais são tuas. A escolha do modelo é tua. Quando a Anthropic lança um Claude mais rápido ou a OpenAI lança um Codex mais barato, tu adota no mesmo dia, sem release do Stitch.
Isso importa porque o mercado de agentes de IA se move mais rápido do que qualquer fornecedor de CI consegue lançar. Trancar o agente dentro da ferramenta de CI é uma aposta: que o fornecedor de CI vai acompanhar os modelos de fronteira. Até agora, nenhum acompanha.
Custo de infraestrutura é a verdadeira pergunta de preço
A linha de preço esconde o número mais importante. “Grátis, MIT” no Stitch significa que o único gasto é tua assinatura do agente de IA que tu já tem. Uma linha SaaS a partir de 20 dólares por usuário por mês, ou um plano Nx Cloud, ou um plano Dagger Cloud, são contas por assento que crescem com o time, em cima da assinatura do agente de IA.
Para um time de cinco pessoas que já usa Claude Code, o Stitch soma zero. As ferramentas concorrentes somam uma linha anual de quatro dígitos antes do loop de verificação rodar uma única vez.
Onde o Stitch perde
Comparações honestas precisam dessa seção.
- Se tu precisa de um serviço gerenciado de fix-on-merge com dashboards no nível da organização, o Stitch não tem essa forma. Roda por desenvolvedor.
- Se teu CI exige imagens de build exóticas que não rodam num laptop, a execução local não vai verificar esses jobs. O Stitch detecta e pula; tu mantém o CI para o resto.
- Se teu problema é “modernizar este código Java 8 para Java 21”, uma plataforma de refactor como Gitar é feita para isso. O Stitch não.
- Se teu problema é “nosso YAML é ilegível”, trocar por código Dagger pode ser o movimento certo. O Stitch não resolve isso.
A matriz não é “Stitch ganha em tudo”. A matriz é “Stitch ganha onde o problema é verificação pré-push com um loop de fix de IA sobre o pipeline que tu já tem”.
A aposta
A aposta por trás do Stitch é: a máquina do desenvolvedor é o lugar certo para o loop de verificação, e o agente de IA que o desenvolvedor já tem é o lugar certo para os fixes. Toda outra ferramenta da categoria aposta no oposto: o lugar certo é a nuvem do fornecedor, com o agente do fornecedor, no preço do fornecedor.
Se a aposta estiver certa, as ferramentas local-first ganham em latência, custo, privacidade e liberdade de agente. Se a aposta estiver errada, as ferramentas na nuvem ganham em escala e controle central. Achamos que a aposta está certa porque os agentes já estão na máquina do desenvolvedor. A parte difícil não é mais “onde rodamos a IA?”. A parte difícil é “parar de forçar ela para outro lugar”.