Dos mil agentes se reescriben en dos semanas: cómo Prime Agent llevó TypeScript a Rust

Un ejército de dos mil, y ninguno es humano

Prime Agent, el agente de programación que solo se lanzó oficialmente en agosto de 2026, acumuló en dos meses más de 300.000 descargas y procesó más de 8 billones de tokens. El 9 de octubre, su desarrollador Prime Intellect anunció algo aún más llamativo: la herramienta se reescribió a sí misma. El paso de TypeScript a Rust se completó en dos semanas, y quienes hicieron el trabajo fueron más de dos mil agentes autónomos.

No es el eslogan de "la IA te escribe el código". Durante toda la portabilidad, el equipo humano hizo sobre todo una cosa: preparar los criterios de aceptación para que los agentes pudieran medir por sí mismos si lo habían hecho bien. El resto, orquestación, escritura de código, revisión y verificación, se entregó a las máquinas.

Costo y escala: mover 200 mil millones de tokens

Según el blog oficial, esta reescritura coordinó más de 2.000 agentes trabajando en paralelo en más de 10.000 sandbox de Prime, y consumió más de 200 mil millones de tokens desde el endpoint GLM-5.3 de Prime Inference. La fase que realmente escribió Rust la completaron 1.981 agentes, con unos 192,99 mil millones de tokens; la fase de tres días de subida de rendimiento sumó otros 228 agentes y unos 35,7 mil millones de tokens.

Estos números son en sí mismos una señal. Que el modelo abierto GLM-5.3 se convierta en el motor de inferencia principal de un enjambre de agentes de nivel producción no es lo mismo que "un modelo subió otro punto en un benchmark". Demuestra que, en escenarios de ingeniería prolongados, masivos y que exigen llamadas a herramientas estables, la relación costo-eficacia de los modelos de pesos abiertos ya es aceptable para proyectos reales.

Orquestación: el agente raíz no escribe código de producto

Lo más digno de copiar no es "usó dos mil agentes", sino su forma de repartir el trabajo. Toda la reescritura la dirigió un único agente raíz, que a su vez no escribió ni una línea de código de producto. Solo hacía tres cosas: dividir las tareas en un grafo con orden topológico, seguir el progreso de cada tarea y fusionar el trabajo terminado.

Cada tarea atraviesa cuatro roles en orden:

• Planificador: escribe la especificación, el diseño de la función y la "respuesta de referencia", que se toma directamente del comportamiento existente de la versión TypeScript.
• Implementador: escribe código Rust en un worktree independiente, para que distintas funciones avancen en paralelo.
• Revisor: cambia de modelo y de contexto para buscar de forma adversarial los defectos de este cambio.
• Verificador: compila el código y ejecuta pruebas de consistencia en un sandbox totalmente nuevo.

Si falla la revisión o la verificación, la tarea vuelve al implementador con las conclusiones. Solo cuando ambas pasan se permite fusionar el cambio. Prime Intellect separó a propósito "generación" y "evaluación", por una razón directa: si dejas que el agente que escribió el código juzgue su propio resultado, tenderá de forma natural a favorecerse.

Las verdaderas barandas: cuatro tipos de controles de consistencia

El proceso por sí solo no basta; también hacen falta criterios objetivos de acierto y error. El equipo construyó cuatro tipos de comprobaciones de paridad, cada una cubriendo una faceta distinta de la misma función:

• Pruebas diferenciales de TUI: ejecutar los dos binarios, TypeScript y Rust, bajo el mismo modelo con guion, comparando la pantalla de la terminal fotograma a fotograma, cubriendo arranque, menús, llamadas a herramientas, reanudación de sesión, subagentes y recuperación tras fallos.
• Consistencia del harness: comparar las transcripciones de sesión generadas por cada lado y las peticiones que cada uno envía al proveedor del modelo.
• Consistencia del protocolo: verificar cada tipo de mensaje del protocolo del demonio contra la implementación en TypeScript.
• Auditoría funcional: donde los guiones no llegan, los agentes comprueban componente por componente y marcan cada uno como "consistente", "parcialmente consistente" o "faltante".

Con estas reglas objetivas, los agentes pueden juzgar su propio progreso y frenar regresiones antes de fusionar, lo que reduce la necesidad de revisión humana. El equipo también es sincero: los bugs que se escaparon fueron los que ningún test cubría, y solo salieron a la luz tras el uso diario interno.

Resultados: arranque en frío 14 veces más rápido, 80 % menos de memoria

En los datos comparativos oficiales, la demora desde el arranque en frío hasta poder escribir cae de 737,8 milisegundos en la versión TypeScript a 55,8 milisegundos, una mejora de 14,18 veces; el arranque en caliente mejora 13,34 veces; la memoria de todo el árbol de procesos baja de 607,4 MB a 106 MB, un ahorro de alrededor del 80 %; y el tamaño de instalación se reduce de 172,1 MB a 59,6 MB. La primera salida visible llega a los 23,6 milisegundos. La fase de subida registró en total 144 experimentos y fusionó 69 cambios válidos. Una advertencia: esta comparación cara a cara usa la propia suite de ejecución del equipo, y el equipo también señala la falta de un benchmark común, así que las cifras hay que leerlas con cautela.

El cambio estructural puede durar más que la velocidad. El código se dividió en nueve crates, con dependencias unidireccionales impuestas por Cargo; el archivo fuente más grande pasó de unas 15.000 líneas a unas 2.500, y ya ningún archivo supera las 5.000 líneas. Cada sesión corre en su propio proceso de trabajo, así que un fallo no afecta a los demás. El soporte de Windows llegó como efecto secundario de una abstracción de plataforma más limpia, y el catálogo de modelos se obtiene ahora en tiempo de ejecución, de modo que un modelo nuevo ya no depende de un lanzamiento.

Por qué Rust

Los puntos débiles de TypeScript que enumera el equipo son concretos: los tipos son opcionales y desaparecen en tiempo de ejecución; los errores se propagan como excepciones no comprobadas; el trabajo que consume CPU, como renderizar o analizar sesiones grandes, compite con la entrada de teclado por el mismo bucle de eventos; y cada proceso debe mantener una runtime de JavaScript y recolección de basura. Para un demonio que permanece residente y ejecuta un proceso de trabajo por sesión, el código nativo sin GC es la principal fuente de mejora en memoria y tiempo de arranque.

Y cuando el código lo escriben sobre todo agentes, el valor de las "garantías en tiempo de compilación" se amplifica. Las enumeraciones exhaustivas, la propiedad y los tiempos de vida, más los lints estrictos de Clippy, eliminan toda una clase de bugs antes de que el código llegue a ejecutarse. En otras palabras, el compilador asume parte del criterio que antes recaía en un revisor humano.

Qué significa esto para distintas personas

Si diriges un equipo de ingeniería, lo reutilizable no es el número "dos mil agentes", sino el método: primero convertir los criterios de aceptación en controles objetivos y ejecutables de forma automática, luego repartir generación y evaluación entre modelos y contextos distintos, y por último dejar que los agentes avancen solos dentro de las barandas. Primer Intellect ya está convirtiendo este patrón de cuatro roles en un flujo de trabajo reutilizable, con el argumento de que una "fábrica de enjambres bien definida" es más fiable que armar una a medida para cada proyecto.

Si solo eres un usuario común, esto explica una cosa: la velocidad de actualización de herramientas como Prime Agent se parecerá cada vez menos a la del software tradicional. Cuando un producto puede reescribirse a sí mismo, el significado del número de versión cambia. También nos recuerda que, ante conclusiones como "la refactorización aceleró 14 veces", conviene ir primero a la nota al pie para ver quién lo midió y con qué se comparó. Los agentes pueden escribir código útil, pero también pueden escribir elogios de sí mismos llenos de confianza.