Post histórico. Describe la arquitectura de v1, incluyendo el clasificador por regex ponderado y el modelo de rama única disparado por CI. La mayor parte de lo que describe este post fue removido a propósito en v2; ver Borrando nuestro clasificador por regex y CI local-first: el giro para lo que lo reemplazó y por qué.
Cuando un pipeline de CI falla, alguien del equipo tiene que frenar lo que está haciendo, leer los logs, deducir qué se rompió, arreglarlo, empujar y esperar a que el pipeline pase. Este ciclo se repite varias veces al día en la mayoría de los equipos de ingeniería.
Los agentes de IA pueden automatizar todo ese loop. Así lo aborda Stitch.
Paso 1: Detectar el fallo
Stitch corre como un job aguas abajo en tu pipeline de CI. Cuando un job aguas arriba falla, Stitch se activa. No hace polling ni usa webhooks. Lo dispara el propio sistema de CI, lo que significa cero latencia y sin dependencias externas.
Paso 2: Leer y parsear los logs
Los logs de CI son un desastre. Contienen códigos de color ANSI, timestamps, barras de progreso y miles de líneas de salida. Stitch elimina el ruido y extrae las firmas de error relevantes.
Agrupa errores por tipo: fallos de lint, errores de type check, fallos de tests, problemas de dependencias, errores de build. Cada categoría tiene una estrategia de diagnóstico distinta.
Paso 3: Diagnosticar la causa raíz
Acá es donde el modelo de IA se gana el sueldo. Stitch manda el contexto de error limpio a un modelo de lenguaje junto con los archivos fuente relevantes. El modelo no ve todo el repositorio. Ve solo los archivos referenciados en el trace del error, más sus dependencias inmediatas.
Ese contexto acotado es intencional. Previene alucinaciones por código irrelevante y mantiene el uso de tokens predecible.
Paso 4: Generar y validar el arreglo
El modelo produce un parche. Stitch lo aplica localmente y vuelve a correr las verificaciones fallidas. Si las verificaciones pasan, el arreglo se commitea y se empuja. Si fallan, Stitch reporta el diagnóstico y el arreglo intentado para que un humano pueda retomar con contexto completo.
Este paso de validación es crítico. Un arreglo generado por IA que no se prueba es apenas una sugerencia. Stitch trata cada arreglo como una hipótesis que debe verificarse.
Paso 5: Agrupar y deduplicar
Cuando varios jobs fallan por la misma causa raíz, Stitch los agrupa. Si cinco archivos de test fallan por un import faltante, Stitch arregla el import una vez y reporta el arreglo para los cinco jobs. Sin commits duplicados, sin trabajo redundante.
Barandas
Stitch opera dentro de límites estrictos:
- Una rama por pipeline. Todos los arreglos para una corrida dada van a una rama, un merge request.
- Nada de force push. Nunca.
- Acceso a archivos acotado. El agente solo lee archivos referenciados en los traces de error.
- Auto-merge configurable. Apagado por defecto. Revisás el MR antes de que aterrice.
El resultado
Los equipos que usan Stitch reportan menos cambios de contexto para fallos triviales de CI. El ciclo arreglar-empujar-esperar para cuestiones comunes como errores de lint, imports faltantes y desajustes de tipos cae de 15 minutos a menos de 2. Más importante: los desarrolladores siguen enfocados en el trabajo que importa.
Los pipelines de CI siempre van a romperse. La pregunta es si hace falta un humano en el loop para cada fallo.