La mayor parte de la reescritura de v1 a v2 fue sobre forma externa. Local en vez de remoto, TypeScript en vez de Python, CLI en vez de job de CI. La parte que vale la pena escribir aparte es interna. v2 salió con mucho menos código que v1, y la mayor parte de lo que falta se borró a propósito.
La mayor eliminación individual fue nuestro clasificador de errores.
Qué hacía
El clasificador de v1 era un motor de regex ponderado. Leía logs de CI, los pasaba por aproximadamente ciento cincuenta patrones y ordenaba errores en nueve baldes: lint, formateo, tipos, build, config de CI, contratos de tests, tipos complejos, lógica y un comodín llamado unknown. Cada clasificación venía con un puntaje de confianza. Cada balde mapeaba a una estrategia de arreglo.
La landing page de Stitch v1 listaba orgullosa las nueve categorías. Pensábamos que era una feature.
Por qué lo construimos
El clasificador era una respuesta a un problema real. Las llamadas al modelo de lenguaje cuestan tokens. Los logs de CI son enormes. Si mandás el log entero, desperdiciás contexto y obtenés peores resultados porque el modelo tiene que encontrar la señal solo. Si preprocesás el log, quitás el ruido, aislás el error relevante y etiquetás su tipo, ahorrás tokens y le das al modelo ventaja.
Así que construimos un preprocesador. Corría antes del modelo. Producía un payload compacto que decía “este es un error de tipo en archivo X línea Y, acá está el traceback, acá están las cinco líneas alrededor del call site”. El modelo producía el arreglo. Funcionaba.
Por qué tenía que irse
Dos cosas cambiaron.
Los modelos mejoraron leyendo logs crudos. Claude y GPT se volvieron más baratos por token y más afilados parseando salida no estructurada. La brecha entre “mandale al modelo un error extraído quirúrgicamente” y “mandale al modelo el log y que se arregle” se cerró. El paso de extracción dejó de justificar su costo.
Nuestro clasificador empeoró en comparación. Teníamos patrones para TypeScript y Python y Go. No teníamos patrones para Elixir ni Rust ni el framework que un usuario estaba corriendo esta semana. Cuando entraba un log que nuestro regex no matcheaba, lo ruteábamos al balde unknown y dejábamos que el modelo se encargara igual. Esa fue la pista. Si el fallback funcionaba, el camino especializado era opcional. Si el camino especializado era opcional, también era una fuente de bugs que manteníamos sin motivo.
La toma de conciencia que rompió todo fue en el contexto local de v2. En la máquina de un desarrollador, correr stitch run claude significaba que estábamos llamando a Claude Code, que es un agente plugueable con herramientas para leer archivos, correr comandos y razonar sobre errores. Mandarle un payload pre-clasificado era como mandarle a un ingeniero senior un reporte de bug pre-llenado e insistir en que use nuestra plantilla. No la necesitaba. La plantilla solo agregaba fricción.
Qué lo reemplazó
Dos cosas. Una mucho más simple que antes, la otra ni siquiera está en la misma capa.
Stitch v2 sigue haciendo un poquito de preprocesamiento, pero es grueso y honesto. Mira los nombres de los jobs y decide si correrlos. Un job llamado deploy-prod es infra, skip en local. Un job llamado lint es verify, corré en local. Es una decisión de una línea por job. No pretende saber cuáles van a ser los errores.
El diagnóstico real se mudó al agente. Cuando un job falla, Stitch le pasa el log al agente con un prompt corto, deliberadamente aburrido: acá está el job, acá está el log, acá está el repo, por favor arreglalo. El agente hace lo que haría en una sesión interactiva. Lee archivos, corre comandos, prueba cosas. Stitch valida el resultado re-ejecutando el job.
El código total removido fue de miles de líneas. La capacidad total perdida fue cero. Los diagnósticos mejoraron porque el agente tenía acceso a todo el repo en vez de a un extracto de cinco líneas.
La lección
La lección es incómoda, pero aparece una y otra vez en herramientas construidas alrededor de agentes de IA: las abstracciones que construís para ayudar al modelo a menudo dejan de ayudar cuando el modelo se vuelve lo suficientemente bueno. Si sos dueño del preprocesador y también del prompt, vas a llegar a un punto donde el preprocesador está empeorando el prompt. No lo vas a notar porque lo construiste vos.
La única forma en que nos dimos cuenta fue permitiéndonos borrarlo y ver qué pasaba. No pasó nada. Ese era el punto.
Próximo post de la serie: Stitch 2.0 está saliendo. Qué instalás realmente y qué hace.