Cómo Claude Code reescribió Bun en Rust: guía de seis pasos para una migración de código a gran escala
En el pasado, las migraciones de lenguajes de programación a gran escala eran el tipo de proyectos que los equipos de ingeniería posponían durante años. Estas migraciones eran costosas, disruptivas y conllevaban grandes riesgos. Una empresa podía pasar varios trimestres manteniendo dos versiones simultáneamente, solo para obtener un reemplazo con un comportamiento inconsistente respecto al original. Claude Code está cambiando esta realidad. Anthropic ha compartido recientemente su proceso para realizar migraciones de código a gran escala utilizando agentes de IA. El caso más notable es el de Jarred Sumner, creador de Bun, quien migró el núcleo de Bun de Zig a Rust. En menos de dos semanas, el flujo de trabajo de Claude Code generó más de un millón de líneas de código, y el conjunto de pruebas existente de Bun superó las pruebas de integración continua antes de la fusión. Este proyecto no se completó simplemente pidiendo al modelo que "reescribiera Bun en Rust" y esperando una respuesta
Cómo Claude Code reescribió Bun en Rust: guía de seis pasos para una migración de código a gran escala
Introducción
En el pasado, las migraciones de lenguajes de programación a gran escala eran el tipo de proyectos que los equipos de ingeniería posponían durante años. Estas migraciones eran costosas, disruptivas y conllevaban grandes riesgos. Una empresa podía pasar varios trimestres manteniendo dos versiones simultáneamente, solo para obtener un reemplazo con un comportamiento inconsistente respecto al original.
Claude Code está cambiando esta realidad.
Anthropic ha compartido recientemente su proceso para realizar migraciones de código a gran escala utilizando agentes de IA. El caso más notable es el de Jarred Sumner, creador de Bun, quien migró el núcleo de Bun de Zig a Rust. En menos de dos semanas, el flujo de trabajo de Claude Code generó más de un millón de líneas de código, y el conjunto de pruebas existente de Bun superó las pruebas de integración continua antes de la fusión.
Este proyecto no se completó simplemente pidiendo al modelo que "reescribiera Bun en Rust" y esperando una respuesta perfecta. Se basó en un sistema cuidadosamente diseñado que incluía manuales de reglas, mapeo de dependencias, colas mecánicas, revisores adversariales, compiladores, pruebas de humo y verificaciones de coherencia de comportamiento.
La lección fundamental es directa: para migraciones de esta escala, los desarrolladores no deberían pasar la mayor parte de su tiempo corrigiendo archivos individuales. Deberían mejorar el proceso de generación, revisión y verificación de esos archivos.
El creador de Bun utilizó IA para reescribir más de un millón de líneas de código
Jarred Sumner construyó originalmente Bun con Zig. Este lenguaje permitió al desarrollador independiente obtener control de bajo nivel y rendimiento similar al de C, sin enfrentar toda la complejidad del ecosistema de los lenguajes de sistemas grandes.
Esta elección ayudó a Bun a crecer rápidamente en sus inicios. Sumner mencionó que escribió la primera versión en aproximadamente un año, desde un pequeño apartamento en Oakland, antes de que existieran los modelos de codificación modernos.
Para 2026, Bun se había convertido en un runtime, gestor de paquetes, ejecutor de pruebas y herramienta de empaquetado ampliamente utilizado para JavaScript y TypeScript. Sus herramientas de línea de comandos obtenían decenas de millones de descargas mensuales, y productos como Claude Code dependían en gran medida de Bun.
El crecimiento también hizo que las viejas compensaciones de ingeniería fueran imposibles de ignorar.
Bun combinaba un motor de JavaScript con recolección de basura con memoria nativa gestionada manualmente. En Zig, los desarrolladores debían razonar explícitamente sobre asignaciones, limpieza, rutas de error y ciclos de vida de objetos. El equipo de Bun invirtió grandes esfuerzos en sanitizers, pruebas de fuzz, compilaciones de verificación de seguridad y pruebas de pérdidas de memoria, pero los errores de uso después de liberación, doble liberación, pérdidas y errores de ciclo de vida seguían apareciendo.
Rust ofrecía una base diferente. Su sistema de propiedad, verificador de préstamos y limpieza automática podían convertir muchos problemas de memoria en tiempo de ejecución en errores en tiempo de compilación.
Históricamente, este beneficio no justificaba una reescritura completa. Bun contenía cientos de miles de líneas de código Zig, además de numerosas integraciones nativas. Una reescritura tradicional podría consumir un año o más de un pequeño equipo de ingeniería, retrasando al mismo tiempo el desarrollo de funciones y las correcciones de seguridad.
Claude Code hizo viable una migración completamente mecánica.
11 días de Zig a Rust
Sumner utilizó una versión preliminar de Claude Fable 5 y los flujos de trabajo dinámicos de Claude Code para ejecutar la migración.
Escritura y revisión principales
El proceso se ejecutó durante 11 días. Aproximadamente 50 flujos de trabajo dinámicos manejaron diferentes etapas, incluyendo:
- Creación de una guía de portabilidad de Zig a Rust
- Mapeo del ciclo de vida de la memoria
- Conversión de archivos
.ziga archivos.rs - Revisión de cada archivo generado
- Corrección de errores del compilador
- Restauración de comandos individuales de Bun
- Ejecución del conjunto completo de pruebas
- Refactorización y limpieza del código generado
En el punto máximo de rendimiento, el flujo de trabajo producía aproximadamente 1300 líneas de código por minuto. Cada unidad de código generada pasaba por la verificación de dos revisores adversariales independientes, y luego un reparador aplicaba los cambios confirmados.
La solicitud de extracción final agregó más de un millón de líneas de código en más de 2000 archivos modificados.
Antes de la fusión, el conjunto de pruebas existente de Bun pasó en CI. Después de la fusión, aparecieron 19 problemas de regresión, que Anthropic informó que se corrigieron por completo. La versión en Rust se lanzó con Claude Code en junio de 2026.
Este resultado no demuestra que el millón de líneas inicialmente generado fuera correcto. Sumner dejó claro que las primeras traducciones no funcionaban. La clave del éxito fue el sistema de retroalimentación, que transformó gradualmente la salida no funcional en código compilado, probado y compatible en comportamiento.
El costo de la migración fue de aproximadamente $165,000 (según precios de API)
La migración de Bun consumió aproximadamente:
- 5900 millones de tokens de entrada no almacenados en caché
- 690 millones de tokens de salida
- Alrededor de $165,000 según los precios de API
Es una cantidad significativa, pero sigue siendo muy inferior al costo tradicional de una migración que requeriría varios ingenieros a tiempo completo durante años.
Anthropic estima que una migración de un millón de líneas anteriormente podría haber llevado cuatro años, consumiendo entre $3 y $4 millones en recursos de ingeniería. La IA ha cambiado la lógica del negocio, porque una migración ya no necesita resolver una crisis de supervivencia para justificar su costo.
Errores de memoria persistentes, un ecosistema de lenguaje envejecido, procesos de compilación costosos o cuellos de botella recurrentes de mantenimiento ahora pueden ser suficientes para que valga la pena evaluar una migración.
Sin embargo, la comparación debe hacerse con cuidado. El costo de los tokens no es el costo total del proyecto. El equipo también necesita planificación humana, infraestructura, pruebas, revisión de código, trabajo de seguridad y mantenimiento posterior a la fusión.
Por qué Bun migró de Zig a Rust
Esta migración se debió principalmente a consideraciones de fiabilidad, no a la velocidad bruta.
Bun ya funcionaba bien en Zig. El problema era cómo coordinar de forma segura la memoria nativa gestionada manualmente con el runtime de JavaScript con recolección de basura.
Las categorías comunes de fallos incluían:
- Errores de uso después de liberación
- Errores de doble liberación
- Pérdidas de memoria en rutas de excepción
- Punteros inválidos causados por callbacks reentrantes
- Código de limpieza omitido
- Suposiciones de ciclo de vida difíciles de aplicar de forma consistente
En Rust seguro, muchos de estos errores no pueden compilarse. Los valores tienen propiedad clara, la limpieza de recursos está vinculada al ciclo de vida del objeto, y el compilador verifica las referencias antes de que el programa se ejecute.
El objetivo de esta migración era preservar la arquitectura, las estructuras de datos, el comportamiento y el rendimiento existentes de Bun. Intencionadamente se acercó más a una portabilidad mecánica que a un rediseño completo.
Esta decisión fue crucial. Si se rediseña el sistema y se cambia de lenguaje al mismo tiempo, la comparación de comportamiento se vuelve extremadamente difícil.
Segundo caso: 165,000 líneas de código Python a TypeScript
Jarred Sumner no es el único ingeniero de Anthropic que utiliza Claude Code para migraciones importantes.
Mike Krieger, codirector de Anthropic Labs y cofundador de Instagram, migró una base de código Python interna a aproximadamente 165,000 líneas de TypeScript en un fin de semana.
La migración principal consumió alrededor de 27 millones de tokens, e involucró:
- Cientos de agentes inteligentes
- Ocho etapas de control
- Tres rondas de revisión adversarial
- Verificación final de coherencia
- Comparación de salidas comando por comando con la versión en Python
- Pruebas de extremo a extremo generadas por IA
La herramienta original necesitaba entregarse como un único archivo binario. Con la cadena de herramientas de Python, la compilación en cada plataforma tomaba unos ocho minutos, y la matriz de compilación completa retrasaba cada lanzamiento unos 30 minutos.
Después de la migración a TypeScript:
- El tiempo de compilación se redujo a aproximadamente dos segundos
- La velocidad de inicio del binario aumentó aproximadamente seis veces
- Se pudo eliminar el pipeline de despliegue independiente
Krieger no dependía de un conjunto de pruebas exhaustivo entre lenguajes existente. En cambio, Claude
Se creó un marco de pruebas de coherencia que abarca siete escenarios reales y, a continuación, se compararon los resultados de salida entre la implementación antigua y la nueva.
Claude también diseñó pruebas adicionales de extremo a extremo, las ejecutó durante cuatro noches consecutivas, corrigió los casos fallidos y repitió el proceso. Esto permitió descubrir sutiles diferencias de comportamiento no previstas en los escenarios originales.
Por qué las migraciones de código a gran escala son adecuadas para agentes de IA
Las migraciones grandes resultan intimidantes porque implican una enorme cantidad de cambios repetitivos. Precisamente estas características las hacen adecuadas para flujos de trabajo con agentes inteligentes.
El trabajo se puede paralelizar
Un código base grande suele dividirse en archivos, paquetes, crates, módulos o grupos de dependencias. Agentes inteligentes independientes pueden procesar simultáneamente unidades que no dependen entre sí.
El grafo de dependencias determina qué unidades pueden avanzar en paralelo y cuáles deben esperar.
El código existente actúa como especificación
La implementación original ya contiene el comportamiento requerido, los casos límite, las estructuras de datos y los detalles de integración.
El modelo no necesita crear funciones del producto; su tarea es preservar el sistema existente en un nuevo lenguaje o marco de trabajo.
Las pruebas ofrecen una evaluación objetiva
Los agentes inteligentes funcionan mejor cuando pueden evaluar mecánicamente su propia salida.
El compilador, el conjunto de pruebas, la comparación de diferencias de salida, los puntos de referencia o los marcos de pruebas de coherencia proporcionan señales concretas al sistema. El agente inteligente puede mejorar continuamente sin necesidad de que un humano evalúe cada intento intermedio.
Las colas de tareas se generan automáticamente
Un error de compilación se convierte en la siguiente tarea, una prueba fallida se convierte en la siguiente tarea, y un bloqueo del programa también se convierte en la siguiente tarea.
Esto convierte la gran tarea de migración en una cola que se puede reducir iterativamente.
Los fallos repetidos permiten mejorar las reglas
Cuando un revisor encuentra el mismo problema en varios archivos, la mejor solución no es corregir manualmente cada archivo uno por uno.
Se debe actualizar el manual de reglas y regenerar los lotes afectados. Esto evita que el mismo error vuelva a aparecer en trabajos posteriores.
Principio fundamental: corregir el proceso, no los archivos individuales
La idea más importante en el flujo de trabajo de Anthropic es tratar el código generado como producto de la salida del sistema.
Supongamos que 200 archivos traducidos contienen el mismo error de propiedad. Corregirlos manualmente podría resolver los errores visibles, pero el flujo de trabajo podría volver a generar el mismo error.
Un método más eficaz es:
- Identificar el patrón de fallos repetidos.
- Determinar qué regla de migración lo provocó.
- Actualizar el manual de reglas.
- Regenerar solo los archivos afectados.
- Volver a ejecutar el ciclo de revisión y validación.
El código mejora porque el proceso de producción se ha optimizado.
Esto es similar a la ingeniería de software habitual. Un defecto de producción recurrente debería llevar a mejorar las pruebas, las reglas de tipo, las comprobaciones estáticas o el proceso, no solo a aplicar otro parche aislado.
Requisito previo: construir un mecanismo de evaluación fiable
Antes de iniciar una migración a gran escala, es necesario definir cómo demostrará el equipo la corrección de la nueva implementación.
Sin un mecanismo de evaluación, no se puede establecer una condición de finalización fiable.
El mecanismo de evaluación debe evaluar la implementación original y la implementación objetivo en las mismas condiciones. Las pruebas existentes pueden depender de funciones privadas o mecanismos internos específicos del lenguaje, que desaparecen durante la migración.
Anthropic recomienda tres pasos preparatorios:
- Clasificar las pruebas existentes. Separar las pruebas que verifican el comportamiento público de aquellas que dependen de la implementación interna.
- Reescribir las pruebas para que sean portables. Convertir el comportamiento observable externamente en aserciones que funcionen en ambos sistemas.
- Validar el mecanismo de evaluación. Confirmar que la implementación original pasa las pruebas y luego romper el programa deliberadamente para asegurarse de que el mecanismo de evaluación falla.
Un conjunto de pruebas que no puede detectar fallos conocidos no es válido como mecanismo de evaluación para una migración.
Bun tiene una ventaja significativa: la mayor parte de su conjunto de pruebas está escrito en TypeScript, no en Zig, por lo que el mismo conjunto de pruebas puede verificar la implementación en Rust.
Para proyectos sin esta ventaja, se pueden utilizar herramientas de pruebas pareadas para comparar las entradas y salidas reales entre ambas versiones.
El marco de migración de código en seis pasos de Anthropic
Anthropic ha resumido la experiencia de estos proyectos en el siguiente proceso de seis pasos.
Primer paso: crear el manual de reglas, el grafo de dependencias y el inventario de carencias
La primera fase crea los documentos compartidos que seguirán todos los agentes posteriores.
Construir el manual de reglas
El manual de reglas define cómo se mapean los conceptos del lenguaje origen al lenguaje destino.
Para migraciones que mantienen la estructura, el manual de reglas puede incluir:
- Mapeo de tipos
- Manejo de errores
Convenciones de reglas
- Reglas de nomenclatura
- Reglas de memoria y propiedad
- Especificaciones de sustitución de la biblioteca estándar
- Patrones de concurrencia
- Disposición de archivos y módulos
- Reglas para la interfaz de funciones externas
- Patrones que requieren revisión humana
En un rediseño estructural, el manual de reglas se acerca más a un documento de arquitectura.
Jarred Sumner, mediante conversaciones con Claude y revisiones manuales, elaboró la guía de migración de Bun. El producto final tenía cientos de líneas.
Crear el mapeo de dependencias
El repositorio debe dividirse según el orden de dependencias.
Un script determinista puede generar el mapeo de dependencias examinando importaciones, manifiestos, archivos de compilación y relaciones de símbolos. Este resultado ayuda al orquestador a determinar qué archivos se pueden convertir de forma independiente y cuáles requieren procesamiento conjunto.
Redactar el inventario de carencias
El lenguaje origen y el lenguaje destino siguen reglas diferentes.
Para la migración de Zig a Rust, la principal carencia es la propiedad de la memoria. Para la migración de Python a TypeScript, la forma implícita de los objetos y las interfaces deben convertirse en contratos explícitos.
El inventario de carencias debe registrar los aspectos que la simple traducción no puede resolver, e incluye específicamente:
- Suposiciones ocultas del lenguaje origen
- Abstracciones faltantes en el lenguaje destino
- Comportamiento en tiempo de ejecución que debe hacerse explícito
- Bibliotecas no compatibles
- Código específico de plataforma
- Límites inseguros
- Áreas que requieren rediseño o decisión humana
El manual de reglas debe crearse antes que el inventario de carencias, ya que este último depende en parte de lo que las reglas normales no pueden manejar.
Segundo paso: someter las reglas a pruebas de estrés
No traduzcas miles de archivos de inmediato.
Primero, selecciona unos pocos archivos complejos y representativos para una ejecución de prueba única y a pequeña escala. El objetivo es detectar fallos en las reglas antes de que se propaguen por todo el repositorio.
En la prueba de Bun:
- El primer agente tradujo tres archivos según el manual de reglas.
- Otro agente tradujo los mismos archivos desde la perspectiva de un ingeniero senior de Rust.
- Un agente comparador verificó las diferencias.
- Los revisores marcaron las reglas de migración faltantes o incorrectas.
- Los archivos traducidos se descartaron.
El resultado de esta fase es un manual de reglas optimizado, no código de producción.
Para migraciones de rediseño, la prueba equivalente consiste en que un revisor adversarial ataque el documento de diseño y luego se realice una ejecución única de extremo a extremo.
Tercer paso: traducir por completo
Una vez que las reglas han sido validadas mediante la ejecución de prueba, el repositorio se puede procesar a través de una cola paralela.
Una configuración típica de unidad incluye:
- Un implementador
- Dos revisores adversariales independientes
- Un reparador
- Una cola mecánica
- Un manual de reglas compartido
- Un inventario de carencias compartido
La cola debe admitir la reanudación tras una interrupción. Se debe poder determinar si el trabajo está completo comprobando archivos o registrando artefactos, sin depender de la memoria de un solo agente.
Los agentes siempre deben marcar el trabajo incompleto de manera consistente, por ejemplo:
TODO(port): explicar por qué esta parte no se puede traducir de forma segura
No es necesario utilizar el modelo más caro para cada unidad. Los modelos de menor configuración pueden manejar traducciones de alto volumen, mientras que los modelos más potentes se reservan para revisores, decisiones arquitectónicas y modificaciones de reglas.
Cuarto paso: compilar
La primera compilación completa convierte los errores del compilador en una cola de trabajo estructurada.
Dependiendo del costo de la compilación,
el compilador puede ejecutarse dentro de cada bucle de agente o mediante un orquestador separado.
Para el proyecto Bun, compilar todo el espacio de trabajo es costoso, por lo que durante la traducción de archivos, el agente Claude no ejecuta comandos cargo al azar. El flujo alternativo es:
- El orquestador ejecuta el compilador.
- Los mensajes de error se escriben en una lista compartida.
- La lista se clasifica por módulo o causa raíz.
- Los agentes reparadores procesan grupos de errores en paralelo.
- Los revisores verifican las correcciones.
- El orquestador reconstruye el proyecto.
Esto evita que decenas de agentes inicien simultáneamente compilaciones igualmente costosas.
Los errores sistémicos del compilador deben actualizar las reglas. Por ejemplo, el lenguaje de destino podría rechazar dependencias cíclicas que el compilador fuente tolera mediante carga diferida. Esto es un problema a nivel de proceso, no simplemente una colección aislada de errores en archivos.
Paso 5: Ejecutar el programa
Una compilación exitosa solo demuestra que el lenguaje de destino acepta el código.
La siguiente fase utiliza pruebas de ejecución básica y pruebas de humo para detectar fallos, errores de inicialización, recursos faltantes, suposiciones inválidas y fallos de integración.
Los casos fallidos aún deben clasificarse por causa.
Si 40 pruebas de humo fallan debido al mismo patrón de inicialización incorrecto, se debe corregir la regla de migración y regenerar el código afectado, en lugar de asignar 40 soluciones independientes.
Paso 6: Coincidir con el comportamiento original
El nivel final es la coherencia de comportamiento.
Ejecute simultáneamente los conjuntos de pruebas portátiles, herramientas de verificación de coherencia, comparación de resultados y puntos de referencia relacionados de ambas bases de código.
Para cada caso fallido:
- Proporcione al agente de reparación la evidencia del fallo y dos esquemas de implementación.
- Solicite al agente de reparación que identifique la diferencia de comportamiento.
- Un revisor adversarial examine la modificación propuesta.
- Procese por lote las compilaciones de alto costo mediante un único flujo de compilación.
- Vuelva a ejecutar las pruebas afectadas.
- Promueva los fallos recurrentes a cambios de reglas.
La base de código original es siempre el punto de referencia de hecho, a menos que el proyecto tenga la intención explícita de cambiar el comportamiento.
La falta de un conjunto de pruebas no omite este paso. El equipo puede usar Claude para crear herramientas de verificación de coherencia externas basadas en escenarios reales y validar la efectividad de dichas herramientas mediante comportamientos deliberadamente incorrectos.
Inicio rápido del kit de migración de Anthropic
Anthropic ha publicado un kit de inicio público que contiene indicaciones genéricas, plantillas y scripts basados en el flujo de migración.
Este repositorio es material de referencia, no un producto de migración completamente gestionado. Sus indicaciones son plantillas de refactorización, no un registro exacto del proceso del proyecto Bun.
1. Instalar Claude Code
En sistemas macOS o Linux:
curl -fsSL https://claude.ai/install.sh | bash
En sistemas Windows PowerShell:
irm https://claude.ai/install.ps1 | iex
Antes de ejecutar scripts de instalación remotos, revise el contenido del script y las políticas de seguridad de su organización.
2. Clonar el kit de migración
Ejecute en el repositorio que se va a migrar:
git clone https://github.com/anthropics/code-migration-kit-with-claude-code.git ./migration-kit
3. Agregar la habilidad de migración
Este paso opcional copia la habilidad de migración al directorio local de habilidades de Claude Code:
cp -r migration-kit/skill ~/.claude/skills/code-migration
Actualice la ruta del kit de herramientas en el archivo SKILL.md instalado siguiendo las instrucciones.
Repositorio.
4. Ejecutar la evaluación de viabilidad
Primero, use la indicación de viabilidad de solo lectura del kit de herramientas:
prompts/00-feasibility.md
El resultado debe responder tres preguntas:
- ¿Debería migrarse este proyecto?
- ¿La migración mantiene la estructura o rediseña?
- ¿Pueden la implementación original y la implementación objetivo ser evaluadas de manera justa?
"No migrar" es un resultado válido.
5. Preparar herramientas de evaluación y reglas de seguridad
Antes de comenzar la traducción:
- Construya o valide herramientas de evaluación entre lenguajes.
- Copie la configuración recomendada de Claude en el repositorio de destino.
- Prohíba comandos destructivos o de alto costo cuando corresponda.
- Confirme que el repositorio fuente tenga una copia de seguridad recuperable.
- Utilice ramas aisladas, árboles de trabajo controlados y credenciales con permisos mínimos.
Luego ejecute las indicaciones de migración en orden, sin saltar directamente a la traducción a gran escala.
Problemas que surgieron en los primeros intentos de Bun
La migración de Bun no comenzó sin contratiempos.
Cuando muchos agentes comenzaron a trabajar en un mismo repositorio, sus operaciones de Git interferían entre sí. Un agente ejecutaba git stash, otro usaba git stash pop y otro restablecía el árbol de trabajo.
Sumner cambió el flujo de trabajo para que los agentes no pudieran ejecutar comandos destructivos de Git libremente. Posteriormente, dividió el trabajo en cuatro fragmentos de flujo de trabajo, cada uno con un árbol de trabajo independiente, coordinando múltiples agentes por separado.
Este ejemplo destaca un punto clave: los permisos de los agentes deben coincidir con el diseño del flujo de trabajo.
Los agentes de codificación con acceso amplio al shell pueden:
- Eliminar o sobrescribir trabajo
- Restablecer cambios no confirmados
- Activar repetidamente compilaciones de alto costo
- Modificar archivos no relacionados
- Filtrar secretos a través de comandos o registros
- Interferir con otros agentes
La capa de orquestación debe limitar los comandos, definir la propiedad de los archivos, serializar las operaciones de alto costo y facilitar la recuperación.
Mejores prácticas para la migración de código asistida por IA
Las lecciones aprendidas publicadas por Anthropic se pueden resumir en unas pocas reglas prácticas.
No siga ciegamente guías genéricas
Cada base de código tiene diferentes sistemas de compilación, cobertura de pruebas, comportamiento en tiempo de ejecución, restricciones de implementación y tolerancia al riesgo.
Use el marco de seis pasos como punto de partida y luego haga que Claude se ajuste según el repositorio real.
Céntrese en patrones, no en fallos individuales
Los agentes de reparación pueden manejar fallos individuales. El valor humano es mayor cuando se utiliza para identificar patrones recurrentes, reglas faltantes, suposiciones inseguras y problemas arquitectónicos.
Haga que la revisión sea adversarial
El agente implementador no debe ser su único revisor.
Proporcione contexto independiente a los revisores e indíqueles que asuman que el código generado es incorrecto. Su tarea es encontrar por qué el código falla, se desvía o infringe el manual de reglas.
Mecanice la verificación
Utilice compiladores, pruebas, herramientas de linting, diferencias de salida, puntos de referencia y scripts deterministas como herramientas de evaluación.
La revisión subjetiva de "parece correcto" no puede verificar de manera segura cambios de millones de líneas.
Use modelos diferentes para roles diferentes
Las tareas de traducción de alto volumen pueden asignarse a modelos más pequeños o más económicos. Los modelos más potentes deben encargarse de la creación de reglas, la arquitectura, los fallos ambiguos y la revisión.
Invierta en esfuerzo humano temprano
El trabajo humano de mayor valor debe completarse antes de la generación a gran escala:
Defina el caso de negocio
- Construya el mecanismo de revisión
- Elabore el manual de reglas
- Mapee las dependencias
- Audite el proyecto piloto
- Establezca permisos y límites
Una vez que estos fundamentos sean sólidos y confiables, la mayor parte del trabajo restante se convierte en tareas mecánicas de cola.
Mantenga la cola recuperable
Las migraciones que deben ejecutarse durante días deben poder soportar interrupciones, reinicios, fallos del modelo y cortes de infraestructura.
El estado de finalización debe determinarse en función de artefactos persistentes en disco, confirmaciones, resultados de pruebas y estado de la cola, no de una única conversación larga.
Resultados después de la migración de Bun
Anthropic informó que el código de Bun escrito en Rust ya está en producción.
Esta migración no eliminó todas las compensaciones. Aproximadamente el 4% del código Rust todavía está en bloques unsafe, concentrado principalmente en operaciones pequeñas de punteros en los límites con C y C++.
Sin embargo, la nueva implementación trajo mejoras significativas:
- Se corrigieron fugas de memoria detectables
- El uso de memoria en una prueba comparativa de compilación repetitiva se redujo de 6.745 MB a 609 MB
- En plataformas Linux y Windows, el tamaño del binario se redujo en un 19%
- Las optimizaciones entre lenguajes mejoraron el rendimiento de cargas de trabajo específicas entre un 2% y un 5%
Estos resultados demuestran claramente el valor de la migración. El objetivo no es generar grandes cantidades de código escrito por IA, sino construir un sistema más seguro, más eficiente y más fácil de mantener, preservando el comportamiento original.
Escenarios adecuados para la migración con IA
Los flujos de trabajo con agentes son adecuados para migraciones a gran escala cuando se cumplen las siguientes condiciones:
- La base de código original puede usarse como especificación completa
- El comportamiento puede verificarse mediante medios externos
- Se pueden crear pruebas o escenarios equivalentes
- El trabajo puede dividirse en unidades repetibles
- El lenguaje de destino tiene ventajas claras
- La organización puede tolerar ramas experimentales grandes
- Expertos humanos pueden revisar la arquitectura y los casos límite
- El entorno de herramientas puede estar restringido y ser auditado
Puede no ser adecuado en los siguientes casos:
- El comportamiento original no se comprende suficientemente
- No se puede verificar la corrección
- El proyecto confunde migración con rediseño completo del producto
- La aprobación regulatoria requiere verificación humana de cada cambio
- El código contiene secretos o sistemas que no pueden exponerse de manera segura
- El equipo no tiene sentido de propiedad después de fusionar el código generado por IA
Poder generar rápidamente millones de líneas de código no hace que la migración sea automáticamente razonable.
Preguntas frecuentes
¿Claude Code realmente migró Bun de Zig
¿Se reescribió en Rust?
Sí. Jarred Sumner utilizó el flujo de trabajo dinámico de Claude Code y un modelo Claude en versión preliminar para migrar el núcleo de Bun de Zig a Rust. El proceso generó más de un millón de líneas de código en menos de dos semanas, seguido de compilación, pruebas, revisión y correcciones posteriores a la fusión.
¿Cuánto costó la migración de Bun?
Según el informe de Anthropic, se consumieron aproximadamente 5900 millones de tokens de entrada no almacenados en caché y 690 millones de tokens de salida. Según los precios de la API, el costo del modelo se estima en unos 165 000 dólares estadounidenses, sin incluir los costos de personal e infraestructura.
¿Pasó todas las pruebas antes de la fusión de la migración?
Anthropic indicó que, antes de la fusión, el conjunto de pruebas existente de Bun ya se había superado en el entorno de integración continua. Después de la fusión, se detectaron 19 problemas de regresión, que posteriormente se corrigieron.
¿Por qué Bun migró de Zig a Rust?
El objetivo principal fue mejorar la seguridad de la memoria y reducir los problemas recurrentes de ciclo de vida, como la limpieza, el uso después de liberación, la doble liberación y las fugas de memoria. El sistema de propiedad y tipos de Rust puede detectar muchos de estos problemas en tiempo de compilación.
¿Puede Claude Code migrar automáticamente cualquier código base?
No. Una migración exitosa requiere evaluadores rigurosos, reglas claras, análisis de dependencias, permisos controlados, colas repetibles, revisión adversarial y supervisión humana. Algunos proyectos simplemente no deberían migrarse.
¿Qué es la revisión adversarial de código?
Un revisor adversarial recibe los cambios generados en un entorno independiente, y su función es encontrar defectos, no aprobar cambios. El rol del implementador y del revisor son diferentes, lo que reduce el riesgo de que el autor defienda su propio trabajo.
¿Necesito un conjunto de pruebas existente?
Idealmente, se debe contar con un conjunto de pruebas existente sólido, especialmente si puede verificar el comportamiento público independientemente del lenguaje de implementación. Si no se dispone de ello, el equipo puede construir un marco de validación para comparar las diferencias entre escenarios reales y salidas del sistema nuevo y el antiguo.
¿Es el kit de herramientas de migración de Anthropic el flujo de trabajo completo que usó Bun?
No. Anthropic describe ese repositorio como un kit de inicio generalizado y reestructurado. La migración real de Bun utilizó componentes más específicos, incluido un manual extenso de reglas del proyecto y flujos de trabajo dinámicos personalizados.
Herramientas relacionadas
- Claude Code: Herramienta inteligente de codificación de Anthropic para la gestión de repositorios, terminales, pruebas y flujos de trabajo de desarrollo.
- Bun: Entorno de ejecución, gestor de paquetes, empaquetador y ejecutor de pruebas para JavaScript y TypeScript.
- Rust: Lenguaje de programación de sistemas centrado en el rendimiento, la seguridad de tipos y la seguridad de la memoria.
- Zig: Lenguaje de programación de bajo nivel que enfatiza el control explícito y la semántica de lenguaje simple.
- GitHub: Plataforma de control de versiones y colaboración para gestionar las solicitudes de fusión de la migración de Bun y el kit de herramientas de migración de Anthropic.
- Plugin de modernización de Claude Code: Plugin oficial de Anthropic para evaluar y modernizar sistemas heredados.
Enlaces relacionados
- Guía de migración de código a gran escala de Anthropic: Proceso oficial de seis pasos y dos casos de estudio de migración.
- Reescritura de Bun en Rust: Registro detallado de Jarred Sumner sobre la arquitectura, flujo de trabajo, revisión, fallos y resultados.
- Solicitud de fusión de la reescritura de Bun en Rust: Solicitud de fusión ya aprobada que contiene la migración masiva de Zig a Rust.
- Kit de herramientas de migración de Claude Code: Indicaciones, plantillas, scripts y flujos de trabajo de referencia oficiales para la migración de lenguajes.
- Documentación de Claude Code: Documentación oficial sobre instalación, configuración, seguridad y flujos de trabajo.
- Plugin de modernización de código: Plugin oficial de Claude Code para la evaluación y transformación de sistemas heredados.
Pruebas de equivalencia de comportamiento.
- Guía oficial de Rust: Documentación oficial sobre propiedad, préstamo, tipos, concurrencia y desarrollo de aplicaciones en Rust.
Resumen
El éxito de la migración de Bun con Claude Code no se debió a que generara de una sola vez un millón de líneas de código perfectas. La clave del proyecto radicó en que el equipo construyó un sistema de producción riguroso en torno al modelo: manual de reglas, mapeo de dependencias, lista de carencias, proyecto piloto, cola de traducción paralela, revisión adversarial, ciclo de compilación, pruebas de humo y verificación de coherencia de comportamiento.
El mismo método ayudó a Anthropic a migrar una gran base de código Python a TypeScript en un fin de semana. En ambos casos, la importancia de la validación objetiva superó con creces la velocidad bruta de generación.
La IA puede reducir significativamente el costo y el ciclo de las migraciones a gran escala, pero solo si el proceso es interrumpible y recuperable, los permisos están controlados, y los defectos recurrentes mejoran continuamente las reglas del código generado.
El verdadero avance no es que la IA pueda escribir un millón de líneas de código, sino que un ciclo cuidadosamente diseñado pueda generar, cuestionar, probar y corregir ese código repetidamente hasta que el comportamiento del nuevo sistema sea completamente equivalente al del antiguo.