Bun explora migrar de Zig a Rust con un port asistido por IA: lo que dice la guía oficial publicada hoy

⏱️ Lectura: 18 min

El 5 de mayo de 2026 apareció en el repositorio oficial de Bun una rama llamada claude/phase-a-port con un archivo nuevo: docs/PORTING.md. El commit, identificado como 46d3bc29f270fa881dd5730ef1549e88407701a5, es la primera evidencia pública de que el equipo de Bun —desde diciembre de 2025 propiedad de Anthropic— está experimentando con la idea de migrar el runtime completo del lenguaje Zig al lenguaje Rust, usando agentes de inteligencia artificial como traductores principales del código fuente. Horas después, Jarred Sumner, creador y mantenedor principal de Bun, salió a aclarar en Hacker News que el experimento no es un compromiso de reescribir el runtime, sino una exploración técnica que podría descartarse por completo. La discusión escaló en pocas horas: 692 puntos y 511 comentarios en HN, una cobertura de The Register firmada por Tim Anderson, hilos en Lobsters y respuestas en cadena desde el ecosistema Zig.

📑 En este artículo

1. Qué pasó el 5 de mayo
2. Bun en 2026: cuán importante es el proyecto
3. Por qué Zig fue la elección original
4. La política no-IA de Zig y el bloqueo del fork
5. Phase A y Phase B: la guía oficial
   1. Fase A: capturar la lógica
   2. Fase B: hacer que compile
6. Cómo se traduce código entre lenguajes con agentes
7. La discusión pública: 692 puntos en HN
8. Conexión con la adquisición y el caso Claude Code
9. Qué viene después
10. Cómo seguir el experimento desde el código
11. Lección de fondo
12. Fuentes
    1. 📚 Artículos relacionados

Esta noticia cae apenas un día después de la cobertura sobre Bun bajo Anthropic y los miedos comunitarios que arrastra la adquisición. El port a Rust convierte una preocupación abstracta de gobernanza en una decisión técnica concreta y verificable. Vamos a desarmar el anuncio: qué dice exactamente la guía oficial, por qué Zig fue la elección original, qué fricción produjo la política no-IA del proyecto Zig, cómo está estructurado el experimento de traducción, y qué implicaciones reales tiene para el millón largo de proyectos que hoy dependen de Bun en producción.

Qué pasó el 5 de mayo

A las 14:08 UTC, el The Register publicó la nota titulada «Bun posts Rust porting guide, says rewrite is still half-baked». La pieza, basada en el commit público y en respuestas directas de Sumner en redes sociales, sintetiza el contexto en una línea que resume el conflicto: «Zig’s no-AI policy is at odds with view that most open source code will be AI-written in future». La frase de Sumner que resumió su postura sobre el ecosistema, citada por The Register, es contundente:

«I expect OSS to go the opposite direction: no human contribution allowed.»

Esa es una de las posiciones más radicales que ha expresado un mantenedor relevante hasta hoy sobre el futuro del open source y los agentes de código. La aclaración inmediata sobre el experimento concreto, también de Sumner, fue más mesurada:

«We haven’t committed to rewriting. There’s a very high chance all this code gets thrown out completely. I’m curious to see what a working version of this looks like, what it feels like, how it performs.»

La rama claude/phase-a-port no es una propuesta de merge; es un experimento que vive en paralelo a la rama principal main. El nombre mismo —incluir claude/ como prefijo— es revelador: el port se está realizando con un agente coordinador construido sobre Claude Code, el agente de programación de Anthropic.

Bun en 2026: cuán importante es el proyecto

Antes de discutir si tiene sentido reescribirlo, conviene establecer escala. Bun es un runtime alternativo a Node.js y Deno, lanzado como versión 1.0 en septiembre de 2023 por Jarred Sumner. Combina runtime de JavaScript, gestor de paquetes, bundler y task runner en un único binario. Sus números públicos a inicios de 2026 son significativos:

• 88.000 estrellas en GitHub, muy por encima de Deno y comparable con frameworks históricos.
• 7,2 millones de descargas mensuales desde el registro npm.
• Aproximadamente 3,1 millones de descargas semanales del paquete bun, con crecimiento interanual reportado del +85%.
• Empresas con uso documentado en producción incluyen Stripe, X (anteriormente Twitter), Midjourney y Tailwind CSS, que distribuye su CLI standalone como un binario construido con Bun.
• El propio Anthropic lo usa internamente para Claude Code, su producto de agente CLI.
• Aproximadamente 770.000 líneas de código en el repositorio principal, predominantemente en Zig.

A diferencia de Node, que está en C++ y cuyo desarrollo lleva más de quince años, o de Deno, que está escrito en Rust desde su origen, Bun apostó por Zig, un lenguaje de sistemas diseñado por Andrew Kelley a partir de 2016 para reemplazar C en escenarios donde se requiere control bajo nivel sin la complejidad sintáctica de Rust. Esa decisión fue distintiva durante años y forma parte de la identidad técnica del proyecto.

Por qué Zig fue la elección original

La elección de Zig por parte de Sumner respondía a tres factores que en su momento eran defendibles:

• Compilación rápida. Zig produce binarios sin las pesadas operaciones de monomorfización que Rust hace para cada genérico. En proyectos grandes como Bun esa diferencia se nota: los tiempos de iteración del desarrollador son sustancialmente menores.
• Control explícito de memoria sin borrow checker. Zig deja la responsabilidad al programador, lo que evita pelear con el verificador de préstamos, pero exige disciplina manual. Sumner ha argumentado que para un runtime con caminos calientes muy específicos, eso permite optimizaciones difíciles de expresar en Rust idiomático sin caer en unsafe.
• comptime y monomorfización selectiva. Zig permite ejecutar código en tiempo de compilación para generar variantes especializadas de funciones. Esto encaja con el patrón típico de un runtime, donde se quiere una implementación rápida para casos comunes y un fallback genérico para casos raros.

El precio de esa elección era estabilidad. Zig estaba —y sigue estando— en versión 0.16, lo que significa que tanto la sintaxis del lenguaje como la biblioteca estándar pueden cambiar entre versiones menores. El equipo de Bun mantiene un fork interno de Zig precisamente para amortiguar ese ritmo, además de incorporar mejoras propias. Una de esas mejoras —generación de código en paralelo, que cuadruplicaba la velocidad de compilación en modo debug— se convirtió, paradójicamente, en parte del detonante del experimento actual.

La política no-IA de Zig y el bloqueo del fork

Cuando Bun intentó proponer la mejora de compilación paralela al proyecto Zig upstream, dos obstáculos aparecieron al mismo tiempo. El primero fue técnico: el equipo core de Zig argumentó que la implementación paralela del análisis semántico podía exhibir comportamientos no deterministas en ciertos órdenes de evaluación, y que aceptar el cambio sin un análisis exhaustivo podía romper supuestos del compilador. El segundo fue de gobernanza: el proyecto Zig adoptó formalmente una política contra contribuciones asistidas por modelos de lenguaje grandes.

El argumento detallado de esa política fue publicado por Loris Cro, ingeniero del equipo Zig, en su blog kristoff.it el 29 de abril de 2026. Cro lo enmarca en lo que llama «contributor poker»: apostar el tiempo y la energía de los mantenedores en contribuyentes humanos que desarrollen pericia y confianza con el equipo. La cita central de su tesis es:

«From the perspective of contributor poker it’s simply irrational for us to bet on LLM users while there’s a huge pool of other contributors. To be able to provide impactful work a contributor needs to be familiar with the codebase and the problem space.»

El equipo Zig sostiene que las contribuciones generadas por LLMs presentan tres problemas recurrentes: pull requests con alucinaciones, código que no compila, y autores que consultan modelos en privado mientras niegan hacerlo en el hilo público. La política no prohíbe a desarrolladores usar IA en su flujo personal; prohíbe contribuciones donde el LLM es el autor efectivo del código.

Para Bun la política fue una pared. La mejora de compilación paralela, junto con varios parches adicionales, no podía mergearse upstream sin reescritura humana. Esto implica que cualquier mejora seguirá viviendo en el fork interno de Bun, multiplicando el esfuerzo de mantenimiento a medida que Zig sigue evolucionando independientemente. La pregunta empezó a ser: si el proyecto va a desviarse cada vez más del Zig upstream, ¿por qué no usar un lenguaje que sí acepte los flujos de trabajo modernos?

Phase A y Phase B: la guía oficial

PORTING.md divide el proceso en dos fases con objetivos muy distintos. La estructura está pensada para usar agentes de IA como motor de traducción, pero conserva control humano explícito.

Fase A: capturar la lógica

El objetivo de la fase A es producir un archivo .rs al lado de cada .zig que represente la misma lógica, sin que el código necesite compilar. La consigna es estructural: respetar el orden de los campos, los nombres de las funciones (en snake_case) y el flujo de control. Cada función traducida lleva un comentario que indica el grado de confianza:

// CONFIDENCE: high
fn parse_header(buffer: &[u8]) -> Option<Header> {
    // TODO(port): verificar manejo de end-of-stream
    // PERF(port): zig usaba un arena allocator de 4096 bytes
    // ...
}

Las restricciones explícitas que enumera la guía son sorprendentemente estrictas para un proyecto Rust. Citando textualmente:

«No tokio, rayon, hyper, async-trait, futures. No std::fs, std::net, std::process.»

Tampoco se permite async fn. Todo concurrencia se expresa con callbacks y máquinas de estado, «igual que en el Zig original». Los bloques unsafe requieren anotaciones // SAFETY: <razón> que reflejen los invariantes del código original. Los crates relacionados con el AST mantienen arenas; el resto usa el alocador global.

Estas restricciones son, en términos de comunidad Rust, profundamente no-idiomáticas. La mayoría de los proyectos Rust modernos asumen tokio para asíncrono, hyper para HTTP, rayon para paralelismo de datos. Renunciar a todo el ecosistema asíncrono de alto nivel no es una decisión accidental: el equipo de Bun necesita preservar el modelo de concurrencia del runtime original, donde el bucle de eventos está construido manualmente y los handles se pasan como argumentos explícitos.

Fase B: hacer que compile

La fase B toma los archivos producidos por la fase A y los hace compilar crate por crate. Aquí los tipos se ajustan, los imports se resuelven, los lifetimes se anotan, y el borrow checker se enfrenta. Esta es la parte donde la mayor parte del trabajo humano resulta inevitable.

El estado actual reportado por la comunidad es elocuente: aproximadamente el 80% de los archivos porteados tiene confianza marcada como medium, lo cual significa que la lógica probablemente está bien capturada, pero el código no compila. La fase B no ha empezado en serio. Sumner lo confirmó al moderar la discusión en HN:

«This whole thread is an overreaction. 302 comments about code that does not work.»

Cómo se traduce código entre lenguajes con agentes

El método operativo descrito implícitamente en PORTING.md y discutido en los hilos públicos es lo que en la comunidad se ha empezado a llamar «vibe-port»: un agente coordinador lee el archivo Zig, identifica las construcciones idiomáticas, las mapea a equivalentes en Rust según un libro de reglas, y produce el .rs con marcadores TODO/PERF para los puntos donde la traducción es ambigua. Un humano —o un segundo agente— revisa los marcadores antes de pasar a la fase B.

La ventaja teórica de este enfoque sobre una reescritura humana es la velocidad: 770.000 líneas de código se pueden traducir en días, no en años. La desventaja es que el código resultante puede ser correcto en lógica pero feo en estilo, lleno de unsafe para imitar punteros crudos del Zig original, con asignaciones manuales que un programador Rust expresaría con primitivas estándar.

Un comentario destacado en Lobsters sintetiza la crítica:

«Está absolutamente lleno de unsafe y producirá toneladas de código Rust no idiomático. Nunca conocí mantenedores felices con Rust en codebases de más de 100k líneas que tengan ese perfil.»

Otro punto crítico es la verificación: ¿cómo sabe el equipo que el código traducido se comporta igual al original? La respuesta probable es la batería de tests del runtime, que ya es muy extensa por la naturaleza del proyecto (cubrir compatibilidad con Node.js obliga a una cobertura amplia). Si los tests pasan idénticos en ambas implementaciones, la traducción se considera válida; si fallan, los marcadores TODO en el archivo son las pistas que un humano usa para investigar.

La discusión pública: 692 puntos en HN

El hilo en Hacker News ha sido el más activo de la semana en el espacio runtime/lenguaje. Las posiciones se distribuyen de forma reconocible:

• Defensores del experimento. Validan la curiosidad técnica de comparar lenguajes lado a lado. Argumentan que usar LLMs para PoCs de traducción es legítimo si el código se descarta después. Notar que algunos modelos manejan mejor Rust que Zig en código generado, lo cual sesga el experimento a favor del port.
• Escépticos del AI-coding. Preocupación por código sin comprensión humana profunda. Desconfianza en que un modelo genere Rust idiomático con borrow checker correcto a esta escala. Crítica a la falta de claridad sobre si esto es experimento real o cambio de dirección encubierto.
• Observadores del ecosistema. Apuntan que Rust tiene tiempos de compilación más lentos que Zig, lo cual es paradójico si la motivación inicial era acelerar la compilación. Otros notan que Rust no necesariamente tiene que arrastrar todo su ecosistema asíncrono pesado, y que evitando tokio/rayon —como hace la guía de Bun— se puede mantener un perfil de dependencias relativamente liviano.
• Sospecha post-adquisición. Aparecen comentarios que conectan este experimento con la cobertura previa sobre la degradación de Claude Code y los miedos a la «enshittification» de Bun. Para esta fracción de la comunidad, ver código generado por agentes Anthropic dentro del runtime que esos mismos agentes consumen confirma una espiral preocupante de auto-referencia: la herramienta usa la herramienta para reescribir la herramienta.

El comentario más votado en Lobsters, de un usuario llamado pyfisch, documenta con citas explícitas el uso extensivo de agentes LLM en pull requests recientes del repositorio de Bun, incluso en la rama principal. La línea entre «experimento aislado» y «metodología principal de desarrollo» es tenue.

Conexión con la adquisición y el caso Claude Code

Este movimiento técnico no se puede leer aislado del contexto corporativo. Anthropic compró Bun a finales de 2025. Cinco meses después, Claude Code mostró señales de degradación que despertaron alarmas comunitarias. El experimento de port a Rust llega justo cuando esas alarmas todavía están vigentes, y la postura pública de Sumner —«espero que el OSS vaya en la dirección opuesta: que no se permita contribución humana», según recogió The Register— pone gasolina al fuego.

Para una parte de los usuarios productivos de Bun la pregunta práctica es simple: ¿qué hago con mis pipelines si el runtime que despliego cada noche está siendo reescrito por agentes con el sello de la empresa que también vende el agente que escribe el código? La respuesta razonable, mientras el experimento esté en fase A, es ninguna acción urgente. La rama claude/phase-a-port no afecta la rama main. Los releases públicos de Bun siguen saliendo del Zig original.

Pero la pregunta que sí cambia con este anuncio es de otro orden: si el equipo decide promover el port a producción —lo cual depende fundamentalmente de los resultados de la fase B—, los usuarios estarán dependiendo de un runtime cuyo código fuente no fue escrito por humanos en su mayoría. Para escenarios de auditoría, compliance, certificaciones gubernamentales o seguridad sectorial, eso es una conversación nueva que pocas organizaciones tienen modelada.

Qué viene después

Tres escenarios concretos quedan abiertos:

• Escenario 1: El experimento se descarta. Sumner termina la fase B parcialmente, descubre que el código resultante es lento o lleno de bugs sutiles, y archiva la rama. Bun sigue en Zig. Costo: tiempo gastado, no más. Probabilidad estimada por el propio Sumner: alta.
• Escenario 2: Coexistencia de runtimes. La fase B se completa lo suficiente como para producir un binario funcional pero con desempeño inferior. Bun mantiene la versión Zig como producción estable y la versión Rust como experimento. Esto fragmentaría la comunidad de mantenedores en dos bases de código.
• Escenario 3: Migración completa. La fase B produce un runtime Rust con desempeño aceptable o superior, el equipo abandona la base Zig, y Bun pasa a ser oficialmente un proyecto Rust. Esto sería un terremoto para el ecosistema Zig (perdería su usuario más visible) y enviaría una señal fuerte sobre el lugar del AI-coding en el desarrollo serio de software.

Los plazos típicos para experimentos de este tamaño en la práctica de Sumner sugieren resoluciones en orden de semanas, no meses. La gente que sigue el repositorio de cerca podrá observar el avance directamente: la rama es pública, los commits son visibles, y el PORTING.md se actualiza con cada cambio metodológico. El thread de Hacker News probablemente se reactivará cada vez que aparezca un commit relevante.

Cómo seguir el experimento desde el código

Para desarrolladores que quieran seguirlo de cerca sin instalar nada, los puntos de observación son:

# Ver el árbol completo de la rama experimental
git clone --branch claude/phase-a-port https://github.com/oven-sh/bun.git bun-port
cd bun-port

# Comparar la cantidad de archivos zig vs rust
find . -name "*.zig" | wc -l
find . -name "*.rs" | wc -l

# Buscar marcadores TODO específicos del port
grep -r "TODO(port)" --include="*.rs" .
grep -r "PERF(port)" --include="*.rs" .

# Ver el grado de confianza por archivo
grep -h "CONFIDENCE:" --include="*.rs" -r . | sort | uniq -c | sort -rn

Para quien tenga una instalación de Bun en producción, no hay acción técnica requerida hoy. Los releases de la rama main se siguen produciendo desde Zig. Sin embargo, vale la pena empezar a documentar internamente la decisión: si alguna vez Bun pasa a producción Rust, querrás tener registrado el momento exacto, los flags de versión y el hash del commit del binario que estabas usando. La auditoría retrospectiva cuesta mucho más cuando se difiere.

Lección de fondo

Este episodio es un caso de estudio temprano de una pregunta que va a definir buena parte de la próxima década del software: ¿qué pasa cuando los agentes escriben código que va a producción a una escala que ningún equipo humano podría revisar línea por línea? La respuesta optimista dice que las pruebas, el control de versiones y la presión competitiva del ecosistema mantendrán la calidad. La respuesta pesimista dice que el código generado por agentes va a tener categorías nuevas de bugs sutiles —patrones de error que humanos no producirían— y que el ecosistema todavía no tiene herramientas para detectarlos.

Lo interesante de Bun es que la decisión se toma a la vista del público, en un repositorio open source, con un mantenedor que verbaliza explícitamente su postura. No es una empresa cerrada decidiendo internamente cómo escribe su backend; es un proyecto que millones de personas instalan, ejecutado por agentes que esos mismos millones consumen, en un lenguaje cuya gobernanza se opone a la práctica que el proyecto adopta. Las tensiones de la próxima década en el open source quedan condensadas en este experimento. Vale la pena seguirlo.

Fuentes

• Bun — sitio oficial
• Bun — repositorio principal en GitHub
• PORTING.md — guía oficial del port Zig → Rust (rama claude/phase-a-port)
• The Register — Bun posts Rust porting guide, says rewrite is still half-baked
• Hacker News — Bun is being ported from Zig to Rust
• Lobsters — Bun (the js runtime) is being vibe-ported from zig to rust
• kristoff.it — Contributor poker and AI (Loris Cro, abril 2026)
• Wikipedia — Bun (software)
• Wikipedia — Zig (programming language)
• Wikipedia — Rust (programming language)
• elsolitario.org — Anthropic y Bun: ¿el runtime seguirá el camino de Claude Code? (4 mayo 2026): https://elsolitario.org/2026/05/04/anthropic-bun-claude-code-runtime-2026/