Um pivot de produto raramente começa com um slide. Costuma começar com uma reclamação que não vai embora.
Para o Stitch, a reclamação era latência. Mesmo quando o v1 funcionava perfeitamente, o ciclo de feedback ainda era um round trip de pipeline. Decoramos, documentamos, fizemos as pazes com isso. Os usuários não. As pessoas que experimentaram o Stitch e gostaram continuavam jogando a mesma pergunta de volta: por que estou esperando meu CI achar um import faltando se eu poderia ter rodado o mesmo linter em um segundo na minha máquina?
A resposta que continuávamos dando para nós mesmos era “porque o agente precisa do ambiente de CI”. A resposta honesta, depois que escrevemos, era “porque a gente decidiu que o agente devia viver lá”. Essas coisas não são a mesma.
A observação
Desenvolvedores já estão rodando agentes de IA localmente. Claude Code fica dentro do terminal. Codex também. Ambos estão autenticados, ambos configurados, ambos já com acesso ao repositório que o desenvolvedor está editando.
Nada disso está no ambiente de CI. Para chegar lá, você precisa reconstruir um subconjunto disso, mal. API keys, registries de imagem, dependências cacheadas, secrets montados. Tudo para aproximar, num runner, uma coisa que o desenvolvedor já tem na frente.
A virada, quando finalmente falamos em voz alta, foi embaraçosamente simples. Pare de embutir o agente no pipeline. Rode o pipeline localmente, ao lado do agente que o desenvolvedor já tem. Deixe os dois conversarem direto.
O que isso desbloqueia
Assim que você diz “o Stitch roda localmente”, muitos problemas do v1 deixam de ser problemas.
Latência colapsa. Jobs rodam na mesma máquina que o editor. Um job de lint que esperava noventa segundos por um runner na fila roda em meio segundo. A correção que demorava três ciclos de pipeline para verificar leva três rodadas locais. Feedback medido em segundos, não minutos.
API keys somem. O agente já está autenticado pela assinatura do Claude Code ou Codex do desenvolvedor. O Stitch não precisa de chave própria, não guarda nenhuma, não pede nenhuma. O onboarding é npx stitch-agent run claude e é isso.
Sua config de CI existente é a config. Não há nada a adicionar no .gitlab-ci.yml ou em .github/workflows/*.yml. O Stitch lê o arquivo que você já escreveu e roda os mesmos jobs na sua máquina. O pipeline que você mantém no repo segue sendo a fonte da verdade.
Jobs de infraestrutura ficam remotos. Deploys, publishes, image pushes, nada disso deve rodar num laptop. O v2 detecta pelo nome do job e pula. Você tem execução local para os jobs de verificação, seu CI segue com os jobs de infra. Nada duplicado, nada quebrado.
Privacidade deixa de ser slide de vendas. Execução local significa que seus logs, seu código, suas correções nunca saem da máquina, a menos que você configure um canal de notificação que envie para algum lugar. Não há backend do Stitch para vazar nada porque não há backend do Stitch.
O que isso restringe
Local-first não é vitória de graça. Significa que o Stitch roda onde suas ferramentas rodam. Se seu CI requer uma imagem Docker específica para compilar um binário, sua máquina local precisa conseguir fazer o mesmo, ou o job não pode ser verificado localmente. Na prática isso é tranquilo para toolchains de linguagem típicas e doloroso para ambientes de build exóticos.
Também significa que o Stitch é uma ferramenta por desenvolvedor, não um serviço de time. Não há dashboard compartilhado, nem métricas da organização, nem control plane central. É um trade deliberado. O trade é “seu CI, sua máquina, seu agente, seu ritmo”. Se o que você quer é um serviço gerenciado de correção-no-merge, o Stitch não é a forma para você.
A segunda percepção
A percepção menor e mais silenciosa que saiu desse pivot foi sobre para quem o Stitch é.
O v1 continuava assumindo um time com orçamento de pipeline. O v2 funciona igualmente bem para um desenvolvedor solo num projeto de fim de semana. O código não se importa. O mesmo comando npx, a mesma experiência de agente-no-terminal, a mesma zero config. Estávamos otimizando para o cliente que gostaríamos de ter em vez do desenvolvedor que víamos tentando o Stitch e desistindo.
Local-first deixou o produto acessível para qualquer um que já tivesse um repo e um agente. O que, cada vez mais, é todo mundo.
O próximo post é menor e mais técnico: um classificador que passamos três meses construindo e deletamos numa tarde.