Un pivot de producto rara vez arranca con una slide. Suele arrancar con una queja que no se va.
Para Stitch, la queja era latencia. Incluso cuando v1 funcionaba perfecto, el ciclo de feedback seguía siendo una vuelta completa de pipeline. La maquillamos, la documentamos, hicimos las paces con ella. Los usuarios no. Quienes probaron Stitch y les gustó nos seguían devolviendo la misma pregunta: ¿por qué espero a que mi CI encuentre un import faltante si podría haber corrido el mismo linter en un segundo en mi máquina?
La respuesta que nos veníamos dando era “porque el agente necesita el entorno de CI”. La respuesta honesta, cuando la escribimos, fue “porque decidimos que el agente viviera ahí”. No son lo mismo.
La observación
Los desarrolladores ya corren agentes de IA en local. Claude Code vive dentro de la terminal. Codex también. Los dos están autenticados, los dos están configurados, los dos ya tienen acceso al repositorio que el desarrollador está editando en ese momento.
Nada de eso está en el entorno de CI. Para llevarlo ahí, tenés que reconstruir un subconjunto, mal. API keys, registros de imágenes, dependencias cacheadas, secretos montados. Todo para aproximar, en un runner, algo que el desarrollador ya tiene enfrente suyo.
El giro, cuando por fin lo dijimos en voz alta, era vergonzosamente simple. Dejar de meter el agente en el pipeline. Correr el pipeline en local, al lado del agente que el desarrollador ya tiene. Dejar que hablen directo.
Qué desbloquea esto
Una vez que decís “Stitch corre en local”, muchos problemas de v1 dejan de ser problemas.
La latencia colapsa. Los jobs corren en la misma máquina que el editor. Un job de lint que antes esperaba noventa segundos por un runner en cola corre en medio segundo. El arreglo que antes tardaba tres ciclos de pipeline en verificarse tarda tres corridas locales. Feedback medido en segundos, no en minutos.
Las API keys desaparecen. El agente ya está autenticado a través de la suscripción a Claude Code o Codex del desarrollador. Stitch no necesita su propia key, no almacena una, no pide una. El onboarding es npx stitch-agent run claude y listo.
Tu configuración de CI existente es la configuración. No hay nada que agregar a .gitlab-ci.yml o a .github/workflows/*.yml. Stitch lee el archivo que ya escribiste y corre los mismos jobs en tu máquina. El pipeline que guardás en tu repo sigue siendo la fuente de verdad.
Los jobs de infraestructura se quedan remotos. Deploys, publicaciones, pushes de imágenes, nada de eso debería correr en una laptop. v2 los detecta por nombre de job y los saltea. Tenés ejecución local para los jobs de verificación, tu CI conserva los jobs de infra. Nada duplicado, nada roto.
La privacidad deja de ser una slide de ventas. Ejecución local significa que tus logs, tu código fuente y tus arreglos nunca salen de la máquina salvo que configures un canal de notificación que los mande a algún lado. No hay backend de Stitch por donde filtrar nada porque no hay backend de Stitch.
Qué restringe esto
Local-first no es gratis. Implica que Stitch corre donde corren tus herramientas. Si tu CI requiere una imagen Docker específica para compilar un binario, tu máquina local tiene que poder hacer lo mismo, o el job no se puede verificar en local. En la práctica esto está bien para cadenas de herramientas típicas y es doloroso para entornos de build exóticos.
También significa que Stitch es una herramienta por desarrollador, no un servicio de equipo. No hay dashboard compartido, ni métricas a nivel organización, ni plano de control central. Es un trade deliberado. El trade es “tu CI, tu máquina, tu agente, tu ritmo”. Si lo que querés es un servicio administrado de fix-on-merge, Stitch no es la forma para vos.
La segunda intuición
La intuición más chica y silenciosa que salió de este pivot fue sobre para quién es Stitch.
v1 asumía un equipo con presupuesto de pipeline. v2 funciona igual de bien para un desarrollador solo en un proyecto de fin de semana. Al código no le importa. El mismo comando npx, la misma experiencia de agente en terminal, la misma cero configuración. Habíamos estado optimizando para el cliente que deseábamos tener en vez de para el desarrollador que seguíamos viendo probar Stitch y rebotar.
Local-first volvió al producto accesible para cualquiera que ya tuviera un repo y un agente. Lo cual, cada vez más, es todo el mundo.
El próximo post es más chico y más técnico: un clasificador que pasamos tres meses construyendo y borramos en una tarde.