Un millón de líneas migradas con IA: la cuenta real
· 7 min de lectura
Bun migró más de un millón de líneas de Zig a Rust usando Claude Code en menos de dos semanas, con un consumo de 5.900 millones de tokens de entrada y 690 millones de salida: unos 165.000 dólares a precio de API. El 100 % de las pruebas existentes pasó antes de fusionar, y aun así aparecieron diecinueve regresiones después, ya corregidas.
Anthropic publicó el desglose de una migración que casi nadie enseña: cuánto costó, cuántos tokens consumió y qué se rompió después. El caso es Bun, el runtime de JavaScript, reescrito de Zig a Rust. Un millón de líneas producidas en menos de dos semanas. La cuenta de API: alrededor de 165.000 dólares. El número que te sirve a ti no es ese. Es el método.
Qué dicen los números que publicó Anthropic
El consumo de tokens está desglosado: 5.900 millones de tokens de entrada sin cachear y 690 millones de tokens de salida. Eso son los ~165.000 dólares a precio de API. Los resultados medibles que reporta Anthropic:
- El 100 % de la batería de pruebas existente de Bun pasando en integración continua antes de fusionar.
- Un benchmark de 2.000 compilaciones repetidas bajó de 6.745 MB de memoria a 609.
- El binario quedó un 19 % más chico en Linux y Windows.
- Entre un 2 y un 5 % más rápido sirviendo HTTP y en cargas reales como `next build` y `tsc`.
Son mejoras reales y verificables. Guarda ese "antes de fusionar", porque la siguiente sección lo matiza.
Este sistema es el que enseño dentro de la comunidad MÁQUINA IA: las estaciones, los gates y el código que lo sostiene.
El dato que casi nadie repite
Después de fusionar, aparecieron diecinueve regresiones. Anthropic dice que ya están todas corregidas. Esa frase es la más importante del reporte y es la que se cae de casi todos los resúmenes, porque estropea el titular. No convierte el proyecto en un fracaso: diecinueve regresiones en un millón de líneas migradas es una tasa que muchos equipos humanos firmarían. Lo que hace es corregir la lectura ingenua. "100 % de las pruebas pasando" no significa "cero errores". Significa que las pruebas que existían no cazaron esos diecinueve casos — porque una batería de pruebas solo cubre lo que alguien pensó en cubrir. Andrew Kelley, creador de Zig, publicó una crítica pública dura al proyecto. Su objeción de fondo es exactamente esta: si esas pruebas no bastaban para cazar los errores del código viejo, ¿por qué iban a bastar para un millón de líneas nuevas que ningún humano leyó completo? Las diecinueve regresiones son la respuesta empírica a su pregunta, y le dan parte de la razón.
El método que sí te puedes robar
Lo interesante no es el presupuesto de seis cifras. Es cómo se repartió el trabajo. Uno: paralelizar de verdad. La mayoría le pide cosas a la IA de a una, en una sola ventana, y concluye que la IA es lenta. El cuello de botella casi nunca es el modelo — es que estás haciendo cola contra ti mismo. En este proyecto el trabajo corrió en muchos flujos simultáneos sobre copias separadas del repositorio. Dos: separar quien implementa de quien revisa. El patrón es un bucle de implementar, revisar y corregir, con agentes distintos en cada papel. Un agente que revisa su propio trabajo tiende a aprobarlo. Tres — y esto es lo más copiable — revisar por categorías de error, no "revisar" en general. Anthropic detalla que se usaron ocho subagentes especializados, cada uno buscando una categoría concreta de fallo típico. No un revisor genérico ocho veces: ocho revisores con un solo defecto que cazar cada uno. Esa tercera idea funciona igual sin escribir una línea de código. Si le pides a un modelo "revisa este contrato", te devuelve una opinión general. Si le pides "busca solo cláusulas de renovación automática", encuentra las cláusulas de renovación automática. Y luego preguntas por las penalizaciones. Y luego por los plazos.
Lo que no está verificado
Circulan cifras sobre el número exacto de agentes concurrentes, la cantidad de commits y el ritmo de líneas por minuto. Vienen de publicaciones del fundador de Bun recogidas por prensa secundaria, no del reporte de Anthropic, así que aquí no las doy como oficiales. Las cifras de arriba —tokens, dólares, memoria, tamaño del binario, velocidad, las diecinueve regresiones— sí están en el reporte de Anthropic, y ese es el enlace de abajo.
El dato honesto
Este caso demuestra que una migración masiva asistida por IA es posible y verificable. No demuestra que salga gratis ni que salga perfecta. Costó seis cifras, requirió una batería de pruebas que ya existía y era buena, y aun así dejó diecinueve regresiones que hubo que cazar en producción. Si tu proyecto no tiene con qué verificar el resultado, lo que estás comprando con la IA no es velocidad: es deuda más rápida.
Preguntas frecuentes
- ¿Cuánto costó migrar Bun de Zig a Rust con Claude?
- Alrededor de 165.000 dólares a precio de API. Anthropic desglosa el consumo: 5.900 millones de tokens de entrada sin cachear y 690 millones de tokens de salida. La migración produjo más de un millón de líneas de código en menos de dos semanas, según el reporte publicado por la propia Anthropic.
- ¿La migración salió sin errores?
- No. El 100 % de la batería de pruebas existente de Bun pasaba en integración continua antes de fusionar, pero después de fusionar aparecieron diecinueve regresiones, que Anthropic reporta como ya corregidas. Es el dato que más se omite en los resúmenes y el que mejor explica el límite real de verificar solo con las pruebas que ya existían.
- ¿Qué mejoras medibles dejó la migración?
- Un benchmark de 2.000 compilaciones repetidas bajó de 6.745 MB de memoria a 609 MB. El binario quedó un 19 % más pequeño en Linux y Windows, y el rendimiento subió entre un 2 y un 5 % sirviendo HTTP y en cargas reales como next build y tsc. Todas esas cifras están en el reporte de Anthropic.
- ¿Qué es el patrón de implementador y revisor?
- Es separar el agente que escribe el código del agente que lo revisa, en un bucle de implementar, revisar y corregir. En este proyecto la revisión se repartió además en ocho subagentes, cada uno especializado en una categoría concreta de fallo típico en vez de revisar de forma genérica, lo que mejora mucho la detección.
- ¿Sirve este método si no programo?
- Sí, la idea central se traslada. En vez de pedir una revisión general de un documento, pides una revisión por categoría concreta y repites: primero las cláusulas de renovación automática, luego las penalizaciones, luego los plazos. Un revisor con un solo objetivo encuentra mucho más que un revisor al que le pides que mire todo a la vez.