Empezando con Stitch 2.0

Stitch 2.0 es una CLI local-first. Lee la configuración de CI que ya está en tu repositorio, corre los mismos jobs en tu máquina y le pasa cualquier fallo a un agente de IA (Claude Code o Codex) para que lo arregle. Este post es la versión de cinco minutos de la documentación.

Requisitos previos

• Un repositorio con un .gitlab-ci.yml o un .github/workflows/*.yml. Stitch lee cualquier pipeline que ya tengas.
• Node 20 o más nuevo (o Bun, si eso es lo que usás).
• Claude Code o Codex instalado y autenticado en tu máquina. Ya lo vas a tener si usás cualquiera de esas herramientas día a día.

Esa es toda la lista de dependencias. Stitch no necesita una API key, una imagen Docker ni un token de plataforma. Corre como vos, en tu máquina, con el agente que ya está logueado.

Instalar y correr

No hay paso de instalación. El paquete está publicado en npm. Corrélo directo:

npx stitch-agent run claude

O, si preferís Codex:

npx stitch-agent run codex

En la primera corrida, Stitch va a detectar qué configuración de CI tenés, la va a parsear y te va a mostrar los jobs que está por correr. Los jobs de infraestructura (deploy, publish, release, image pushes) se filtran automáticamente. Los jobs de verificación (lint, typecheck, test, build) son los que corren en local.

La terminal pasa a una TUI interactiva. Vas a ver:

• Un stepper de pipeline arriba, avanzando por las fases de parse, execute y fix.
• Una tabla de jobs al medio, con estado en vivo por job.
• Un panel de driver al costado, mostrando qué está haciendo el agente cuando hay un arreglo en curso.

Podés mirar o irte. Stitch se detiene al primer pipeline completo en verde, al techo de intentos (por defecto tres por job) o ante lo primero que decida escalarte.

Qué pasa cuando un job falla

Stitch le pasa el job fallido a tu agente con un prompt corto y el contexto relevante. El agente hace lo suyo: lee los archivos del error, prueba un arreglo, le dice a Stitch que re-ejecute el job. Stitch valida re-ejecutando el mismo job. Si la re-ejecución pasa, el intento cuenta como arreglo. Si falla, el agente intenta de nuevo, hasta el techo por job.

El loop está acotado a propósito. Si tres intentos no logran el arreglo, Stitch frena y te muestra el estado: el último diagnóstico, el último parche, el último log. Vos retomás con contexto completo.

Commit y push

Cuando un ciclo de arreglo termina con todos los jobs en verde, Stitch puede commitear y empujar el resultado. Esto solo pasa si se cumplen dos condiciones:

1. Estabas en una rama limpia cuando Stitch arrancó. Si había cambios sin commitear, Stitch deja el working tree como está. Tu trabajo en progreso no se toca, nunca.
2. Pediste auto-commit. Apagado por defecto. El flag es --auto-commit.

Esto es deliberadamente conservador. La forma más rápida de perder confianza en una herramienta como Stitch es que pise tu trabajo local. Preferimos que te suscribas vos a que te preguntes qué pasó.

Modo watch

Para loops de iteración ajustados, Stitch puede quedarse corriendo y re-verificar cuando cambian archivos:

npx stitch-agent run claude --watch

En modo watch, guardar un archivo dispara una re-ejecución de los jobs afectados. Editás, guardás, ves verde o rojo en la TUI en segundos, sin salir de tu editor. Esto reemplaza el hábito de “pushear para ver si el CI está contento” por “guardar y ver”.

Configuración, si la querés

Cero config es el default y alcanza para la mayoría de los repositorios. Si querés ajustar el comportamiento, dejá un .stitch.yml en la raíz del repo:

max_attempts: 3
auto_fix: [lint, format, simple_types, config_ci]
escalate: [logic_errors, breaking_changes, dependency_conflicts]

No necesitás este archivo para usar Stitch. Existe para equipos que quieren una política explícita.

Qué no es Stitch

Stitch no reemplaza tu CI. El pipeline remoto sigue corriendo al hacer push. Stitch solo te da una versión más rápida, local y asistida por IA de la misma cosa, para que llegues al push con confianza en vez de esperanza.

Stitch no entrena con tu código. No llama a casa. No hay telemetría para apagar porque no hay nada reportando a ningún lado. Los logs y los arreglos se quedan en local salvo que configures explícitamente un canal de notificación.

Stitch no necesita suscripción propia. El único servicio pago en el loop es el agente (Claude Code o Codex), y eso se factura en la cuenta que ya tenés.

A dónde ir después

El repositorio está en GitHub en x24labs/stitch. Los issues se siguen ahí. El paquete de npm es stitch-agent. El resto está en el código y en los posts anteriores de la serie, que explican por qué v2 tiene la forma que tiene.

Si la probás y algo se rompe, abrí un issue. El punto de local-first es que tenés todo lo que hace falta para reproducir el problema enfrente tuyo.