Toda herramienta cercana a CI lanzada en los últimos dieciocho meses llega con el mismo pitch: conectá tu repo, entregá tu pipeline, dejá que nuestro agente arregle las fallas. La forma del pedido es idéntica aunque los productos no lo sean. Gitar quiere tu repo en su nube. Nx Cloud quiere que reorganices tu grafo de build en su monorepo. Dagger quiere que reescribas tu YAML en su SDK. Cada uno tiene una razón defendible. Ninguna de esas razones le saca a tu equipo el costo de la migración.
Stitch se construyó alrededor de otra observación. El desarrollador ya tiene el pipeline, ya es dueño de la máquina y, cada vez más, ya tiene un agente de IA autenticado adentro de su terminal. La tarea no es introducir un nuevo plano de control. La tarea es conectar las tres cosas que ya existen.
Este post va sobre las partes de la comparación que no entran en una tabla de features.
El mercado se parte en tres
Cuando mirás los productos de cerca, la categoría AI-CI no es un solo mercado. Son tres.
- Plataformas de refactor en la nube como Gitar. Subís el código a su entorno, dejás que su agente haga cambios a gran escala y bajás el resultado. Optimizadas para modernización puntual a escala.
- SaaS de grafo de build como Nx Cloud. Reestructurás el repo en un workspace, empujás el grafo a su cache y recibís ejecución distribuida y caching remoto. Optimizadas para monorepos grandes con builds caros.
- Motores de pipeline programables como Dagger. Reemplazás el YAML por código, corrés el pipeline en su motor dentro de contenedores y obtenés reproducibilidad y portabilidad. Optimizadas para equipos cuyo YAML de CI quedó inmantenible.
Stitch no es ninguna de las tres. Es una cuarta categoría: un loop de verificación local-first que lee la config de CI que ya tenés y la corre en tu máquina con el agente de IA que ya usás.
Matriz de capacidades
| Capacidad | Stitch | Gitar | Nx Cloud | Dagger + IA |
|---|---|---|---|---|
| Usa tu config de CI existente | Sí | No | No | No |
| Corre los jobs en local | Sí | Solo nube | Nube + local | Contenedores |
| Agente de IA enchufable | Cualquier CLI | Solo built-in | Solo built-in | Solo built-in |
| Requiere infra nueva | Ninguna | Cuenta SaaS | Workspace Nx | SDK de Dagger |
| Integración nativa con Claude Code | Trae una skill | No | No | No |
| Precio | Gratis, MIT | Planes pagos | OSS gratis + Cloud pago | Motor OSS gratis + Cloud pago |
La matriz subestima lo que pasa de verdad. La parte interesante es lo que cada fila implica para un equipo de ingeniería tres meses después.
Qué significa de verdad “usa tu config de CI existente”
Si una herramienta lee .github/workflows/*.yml o .gitlab-ci.yml directamente, tu CI sigue siendo la fuente de verdad. El pipeline que mandás a producción es el pipeline que corre el loop de verificación. La divergencia es imposible por construcción.
Si una herramienta te pide traducir tu pipeline a un formato nuevo (SDK de Dagger, grafo de proyecto Nx, YAML SaaS del proveedor), ahora tenés dos pipelines. Uno empujás a CI. Otro entiende la herramienta local. Cada cambio en uno hay que reflejarlo en el otro. En la práctica, el espejo se desactualiza. En la práctica, la herramienta local diverge lentamente de producción. En la práctica, “pasa en local” deja de significar “pasa en CI”.
La migración no es el costo. El mantenimiento permanente de dos configs es el costo. Stitch lo esquiva negándose a ser dueño de la config.
Ejecución local no es solo una historia de latencia
Las herramientas solo-nube publicitan escala. La lectura honesta es que publicitan escala porque la nube es el único modo que ofrecen. No hay un CLI local que puedas correr en una laptop sin un round trip de red. Eso tiene tres consecuencias que nadie pone en una página de ventas.
- Tu código se va de la máquina. Cada iteración manda diffs a un backend SaaS. Para entornos regulados, eso es una revisión de compliance.
- Pagás por minuto de cómputo. Un workflow de feedback rápido sobre un runner lento se pone caro rápido.
- Heredás su disponibilidad. Cuando el SaaS tiene un incidente, tu loop de verificación se frena.
Local-first invierte las tres. Los jobs de Stitch corren en la máquina donde vive el editor. Nada se va salvo que configures un canal de notificación que lo mande. No hay backend de Stitch que se pueda caer.
”Agente de IA enchufable” es la única respuesta honesta
Gitar, Nx Cloud y los features de IA atornillados a Dagger Cloud vienen con un único agente propietario. La elección es del proveedor, el costo es la factura del proveedor, la cadencia de actualización del modelo es el roadmap del proveedor.
Stitch no tiene agente. Invoca el agente que ya usás: Claude Code, Codex, cualquier cosa compatible con CLI. Las credenciales son tuyas. La elección de modelo es tuya. Cuando Anthropic saca un Claude más rápido o OpenAI saca un Codex más barato, lo aprovechás el mismo día, sin necesidad de un release de Stitch.
Esto importa porque el mercado de agentes de IA se mueve más rápido que cualquier proveedor de CI. Trabar el agente dentro de la herramienta de CI es una apuesta a que el proveedor de CI va a seguirle el ritmo a los modelos de frontera. Hasta ahora, ninguno lo hace.
El costo de infraestructura es la pregunta real de precio
La fila de precio esconde el número más importante. “Gratis, MIT” para Stitch significa que el único gasto es tu suscripción al agente de IA que ya tenés. Una línea SaaS desde 20 dólares por usuario al mes, o un plan de Nx Cloud, o un plan de Dagger Cloud, son facturas por asiento que crecen con el equipo, encima de la suscripción al agente de IA.
Para un equipo de cinco personas que ya usa Claude Code, Stitch suma cero. Las herramientas competidoras suman una línea anual de cuatro cifras antes de que el loop de verificación corra una sola vez.
Dónde pierde Stitch
Las comparaciones honestas necesitan esta sección.
- Si necesitás un servicio gestionado de fix-on-merge con dashboards a nivel organización, Stitch no tiene esa forma. Corre por desarrollador.
- Si tu CI requiere imágenes de build exóticas que no pueden correr en una laptop, la ejecución local no va a verificar esos jobs. Stitch los detecta y los saltea; igual necesitás CI para el resto.
- Si tu problema es “modernizar este código Java 8 a Java 21”, una plataforma de refactor como Gitar está hecha para eso. Stitch no.
- Si tu problema es “nuestro YAML es ilegible”, reemplazarlo con código Dagger puede ser el movimiento correcto. Stitch no resuelve eso.
La matriz no es “Stitch gana en todo”. La matriz es “Stitch gana donde el problema es verificación pre-push con un loop de fix de IA sobre el pipeline que ya tenés”.
La apuesta
La apuesta debajo de Stitch es que la máquina del desarrollador es el lugar correcto para el loop de verificación, y el agente de IA que ya tiene el desarrollador es el lugar correcto para los fixes. Toda otra herramienta de la categoría apuesta a lo opuesto: el lugar correcto es la nube del proveedor, con el agente del proveedor, al precio del proveedor.
Si la apuesta es correcta, las herramientas local-first ganan en latencia, costo, privacidad y libertad de agente. Si la apuesta es incorrecta, las herramientas en la nube ganan en escala y control central. Pensamos que la apuesta es correcta porque los agentes ya están en la máquina del desarrollador. La parte difícil ya no es “¿dónde corremos la IA?”. La parte difícil es “dejar de forzarla a otro lado”.