La primera versión de Stitch hacía lo que prometía. Agregabas dos jobs a tu configuración de CI, stitch-monitor y stitch-heal, apuntabas a una imagen Docker pública y, la próxima vez que se rompía una regla de lint o un test, aparecía un merge request con un parche. Para el subconjunto de fallos que manejaba bien, la experiencia era casi mágica.
Lo lanzamos. Lo usamos en nuestros propios repositorios. Y en pocos meses armamos una lista honesta de las cosas que salieron mal. Este post es esa lista.
Vivía en el lugar equivocado
Stitch v1 era un ciudadano de tu sistema de CI. Corría como un job aguas abajo, se activaba al fallar un job aguas arriba y hacía todo su trabajo dentro del entorno del pipeline. Suena prolijo. Tuvo consecuencias que subestimamos.
Cada arreglo requería una vuelta completa de pipeline. Tu CI corría, fallaba, Stitch corría, commiteaba, empujaba, tu CI corría de nuevo. Incluso en un runner rápido, el loop de feedback era de minutos, a veces de decenas de minutos. Para el tipo de error que Stitch pretendía manejar, un import faltante, un desacuerdo del formateador, una anotación de tipo que al test runner no le gustaba, el arreglo en sí tardaba un segundo y la verificación tardaba una eternidad. El humano seguía esperando a la máquina, solo que en otra habitación.
Asumía que el agente vivía en otro lado
v1 hablaba con un modelo de lenguaje por API. Enviamos una integración con OpenRouter, un GitHubAdapter, una clase StitchAgent. La historia de onboarding era “trae tu propia API key”. Sonaba a pedido chico. En la práctica significaba que cada equipo que quería probar Stitch tenía que crear una cuenta en un proveedor, generar una key, guardarla en secretos de CI y presupuestar tokens.
Mientras tanto, cada vez más desarrolladores ya tenían Claude Code o Codex en la laptop, ya autenticados, ya pagados desde su suscripción personal o de equipo. Stitch v1 no sabía hablar con ninguno. Le pedía a los usuarios que pagaran dos veces.
Sobre-ingenió las partes que podía ver
v1 venía con un clasificador por regex. Un motor ponderado que leía logs de CI, los pasaba por ciento cincuenta patrones y ordenaba errores en nueve categorías: lint, formateo, tipos, build, config de CI, test, tipos complejos, lógica, desconocido. Cada categoría tenía un puntaje de confianza. Cada categoría tenía una estrategia de arreglo.
Fue satisfactorio de construir. Fue también, en su mayor parte, puro teatro. El agente del otro lado de la API era capaz de leer un log crudo y deducir qué había salido mal. Nuestro clasificador era, en el mejor de los casos, una forma de mantener el prompt corto. En el peor, una capa de traducción que introducía sus propios bugs. Cuando el agente mejoró, nosotros conservamos el clasificador. Ya lo habíamos construido.
Empujaba antes de saber
El auto-merge era un flag. Apagado por defecto, pero publicitado. Un arreglo aterriza, la re-ejecución pasa, el merge request puede cerrarse solo. En la práctica, ese flag es un tiro en el pie. Que el CI pase es evidencia de que la suite de tests está contenta, no de que el parche fuera el correcto. Vimos casos donde el agente silenciaba un test que fallaba cambiando la aserción, llegaba a verde y el equipo perdía la señal por completo. La respuesta de v1 era “revisá cada MR”. La respuesta de v2 tenía que ser distinta.
Escalaba mal para el caso chico
v1 asumía que el equipo tenía una plataforma de CI corriendo en algún lado que pudiera hospedar su imagen Docker, que tenía presupuesto para cómputo extra en cada fallo y que alguien tenía autoridad para agregar jobs a la configuración del pipeline. Para un startup de tres ingenieros, eso eran tres obstáculos antes del primer arreglo. Para un desarrollador solo en un proyecto paralelo, era una pared.
Los casos de fallo en los que Stitch era mejor, los arreglos de cinco minutos, eran los casos donde el equipo chico más necesitaba ayuda. Y eran exactamente los equipos a los que v1 no llegaba.
Lo que conservamos
No todo. Pero bastante.
La idea central, que los agentes de IA pueden leer logs que fallan, entender el problema y producir un parche puntual, era correcta. La insistencia en la validación, que un parche que no re-ejecuta limpio no es un arreglo, era correcta. La noción de escalar después de intentos acotados era correcta. Eso pasó a v2 sin cambios.
La forma alrededor no. El próximo post de la serie es sobre hacia dónde la llevamos.