23x más rápido: cómo migramos el toolchain de nuestro monorepo con IA

El contexto

Tenemos un monorepo en producción con 9 apps desplegadas en Cloudflare Workers. Todo TypeScript, ~1.670 archivos, gestionado con pnpm workspaces.

Nuestro toolchain de calidad de código era Biome para lint y formato, y tsc para type checking. Funcionaba. Pero había fricciones.

Tanto Biome como tsc necesitaban NODE_OPTIONS='--max-old-space-size=8192' para no quedarse sin memoria — 8 GB de heap para lintear y tipar un monorepo. Y tsc, siendo single-threaded, tardaba 25 segundos en hacer typecheck del monorepo completo. No es eterno, pero cuando estás iterando rápido, cada ciclo de feedback cuenta.

Por qué migrar

Llevábamos tiempo siguiendo el ecosistema de oxc — oxlint, oxfmt, y todo lo que están construyendo en Rust. La promesa era simple: herramientas que hacen lo mismo pero significativamente más rápido, con mejor uso de los núcleos de cpu disponibles.

Por el lado del type checking, TypeScript 7 (tsgo) es básicamente tsc reescrito en Go. Microsoft reportaba mejoras de 7-10x. Queríamos ver si esos números se sostenían en un proyecto real.

La pregunta no era si valía la pena, sino cuánto iba a costar en tiempo. Las migraciones de toolchain son ese tipo de tarea que todos saben que debería hacerse, pero que nadie quiere tomar porque es tedioso, toca muchos archivos, y el riesgo de romper algo en CI siempre está ahí.

La migración a oxlint + oxfmt

Lo que cambió

El cambio fue más directo de lo que esperábamos. En esencia:

1. Reemplazar Biome por oxlint y oxfmt — desinstalar @biomejs/biome, instalar oxlint y oxfmt
2. Configurar .oxlintrc.json — 129 reglas activas
3. Configurar .oxfmtrc.json — opciones de formato equivalentes a lo que teníamos en Biome
4. Actualizar scripts en package.json — de biome check a oxlint ., de biome format a oxfmt
5. Actualizar CI — cambiar el paso de lint en GitHub Actions
6. Actualizar config del editor — VS Code apuntando a las nuevas herramientas

El cambio más grande en volumen fue ajustar código que no pasaba las nuevas reglas de oxlint. No porque Biome fuera más permisivo, sino porque oxlint tiene reglas distintas con criterios distintos. Nada grave — mayormente imports, ordenamiento y patrones que oxlint prefiere de otra forma.

El resultado

oxlint lintea más archivos, con más reglas, en una fracción del tiempo. Y sigue mejorando — dos meses después, con un 32% más de archivos, es el doble de rápido que el día de la migración.

La migración a tsgo

Lo que cambió

Esta migración fue más quirúrgica:

1. Instalar @typescript/native-preview — el binario de tsgo
2. Cambiar el script — de NODE_OPTIONS='--max-old-space-size=8192' tsc a simplemente tsgo
3. Ajustar tsconfig.json — quitar baseUrl (tsgo no lo soporta igual), agregar ./ como prefijo a los paths
4. Actualizar CI — nuevas rutas de cache para .tsgo-cache
5. Fixes de tipos — tsgo es más estricto en algunos "edge cases" que tsc dejaba pasar

Lo más notable es que ya no necesitamos NODE_OPTIONS='--max-old-space-size=8192'. tsgo está escrito en Go — no corre en Node, no tiene ese problema.

El resultado

tsc es single-threaded — usa ~132% de CPU (un core y algo de overhead). tsgo aprovecha todos los cores disponibles. El resultado es un typecheck 33 veces más rápido que el original, sin ningún cambio en el código TypeScript en sí.

Los números finales

El pipeline completo de calidad de código (lint + typecheck), en tres momentos:

De 29 a 1.25 segundos. 23 veces más rápido.

Todos los benchmarks fueron medidos 3 veces con cache de herramienta limpio, en la misma máquina. Los números de la migración (enero 2026) reflejan ~1.260 archivos; los de hoy (marzo 2026), ~1.670 — un 32% más de código y aún así, significativamente más rápido. oxlint y tsgo siguen recibiendo actualizaciones agresivas de performance, y se nota.

El rol de Claude Code

Ambas migraciones fueron asistidas por Claude Code. No fue un "le pedí que lo hiciera y salió andando" — fue un proceso iterativo donde Claude Code hacía los cambios, corríamos las validaciones, ajustábamos y repetíamos.

Lo interesante de usar Claude Code para este tipo de tareas es que las migraciones de toolchain son exactamente el tipo de trabajo donde un agente de código brilla:

• Alto volumen, bajo riesgo creativo — hay que tocar muchos archivos pero los cambios son mecánicos
• Feedback loop claro — el lint pasa o no pasa, el typecheck pasa o no pasa
• Documentación disponible — las herramientas nuevas tienen docs públicas que el agente puede consultar

El PR de oxlint tocó más de 700 archivos entre configs, CI, ajustes de código, reformateo y documentación. El de tsgo fue más contenido — 9 archivos, pero con cambios delicados en tsconfig que requieren entender cómo resuelve paths el nuevo compilador.

¿Lo habría hecho sin IA? Sí, eventualmente. Pero la realidad es que este tipo de migraciones se postergan indefinidamente porque el costo percibido es alto y el beneficio, aunque real, no es un feature nuevo. Claude Code bajó esa barrera lo suficiente como para que lo hiciéramos en una tarde en lugar de dejarlo para "después".

Recomendaciones si estás considerando migrar

oxlint + oxfmt:

• Si ya usas Biome, la migración es directa. Las reglas no son 1:1 pero la cobertura es comparable
• Configura .oxlintrc.json desde el inicio — el default es conservador y probablemente quieras activar más reglas
• Si usas Tailwind CSS v4, mira oxlint-tailwindcss para reglas específicas

tsgo:

• Está en preview, pero para monorepos el salto es dramático
• El cambio más común es ajustar paths en tsconfig — tsgo no soporta baseUrl de la misma forma
• Si tu CI cachea .tsbuildinfo, cambia a .tsgo-cache
• Algunos tipos edge que tsc dejaba pasar, tsgo los marca como error. Es más estricto, y eso es bueno

En general:

• Mide antes y después. Los números concretos hacen que el equipo entienda por qué valió la pena
• Haz ambas migraciones por separado (PRs distintos). Si algo se rompe, quieres saber cuál fue

Las herramientas que usamos para escribir código mejoran a un ritmo que ya no se puede ignorar. oxlint y tsgo son más rápidos porque están escritos en lenguajes que aprovechan mejor el hardware. Claude Code hace viable migraciones que antes se postergaban por tediosas. El resultado es un ciclo de feedback más corto, un CI más rápido, y desarrolladores que pierden menos tiempo esperando.

De 29 segundos a 1. A veces el mejor feature que puedes entregar es menos tiempo esperando.