«¿Sabes lo mejor de Rust? Que no te deja compilar chapuzas. ¿Sabes lo peor? Que todo lo que escribes al principio es una chapuza.» — Sr. Cangrejo, probablemente
¿Qué hay mejor que un agente de IA? Un agente de IA reescrito en Rust.
Si llevas más de cinco minutos en internet, conoces el meme. Da igual el proyecto: un editor de texto, un servidor DNS, una calculadora del IMC. Alguien aparecerá en los comentarios diciendo «deberías reescribirlo en Rust». Es el Rewrite It In Rust — RIIR para los amigos — y es tan inevitable como la gravedad.
Pues bien, voy a hacerlo de verdad. Voy a portar 8.300 líneas de un agente de IA de Python a Rust. Pero no porque el meme me lo pida (bueno, un poco sí). Lo hago porque necesito un conejillo de indias.
La tesis
Llevo semanas escribiendo sobre silent failures, sobre las cinco defensas contra alucinaciones, sobre cómo un LLM puede generar código que compila, pasa los tests, y es incorrecto. Le he puesto nombre y todo: desarrollo adversarial. Never trust, always verify.
Mucha teoría. Ahora toca demostrarlo.
Necesitaba un proyecto con tres características: alcance contenido (no una app nueva con requisitos cambiantes), fuente de verdad clara (el código Python que ya funciona), y suficiente complejidad para que las alucinaciones del LLM tengan donde esconderse. Un porte puro y duro cumple las tres. El input y el output esperado ya existen. Si la versión Rust no se comporta exactamente como la Python, hay un bug. Así de simple.
Y ya que voy a portar algo, ¿por qué no aprovechar para aprender Rust de verdad? El borrow checker, ownership, lifetimes… llevo años leyéndolo todo y tocando nada. Otro gallo cantaría si en vez de leer tutoriales por vigésima vez me peleo con un proyecto real.
El paciente
Se llama nanobot. Es un agente de IA personal derivado de OpenClaw: un bicho que conecta LLMs (Claude, GPT, DeepSeek, lo que le eches) a canales de chat — Telegram, Discord, Slack, email — y les da manos. Puede leer y editar ficheros, ejecutar comandos, buscar en la web, programar tareas con cron, y tiene memoria persistente entre conversaciones.
Funciona. Lleva meses funcionando. En Python.
¿El problema? Es single-threaded. Procesa un mensaje a la vez. Si le mandas tres mensajes seguidos, hace cola como en el Mercadona un sábado a las 12. Usa unos 50MB de RAM para, esencialmente, rutear JSON entre APIs. Y el código tiene el tipo de error handling que da vergüenza ajena: return f"Error: {str(e)}" por todas partes.
Dicho en cristiano: funciona, pero es una ñapa con patas. Candidato perfecto.
Por qué Rust (aparte del meme)
Podría arreglarlo en Python. Podría meterle asyncio con más ganas, tipar los errores con excepciones custom, optimizar la memoria. Sería lo sensato.
Pero sensato no me da un test bench para el desarrollo adversarial. Un refactor en Python no tiene fuente de verdad externa — el «antes» y el «después» comparten lenguaje, librerías, y sesgos del LLM. Un porte a otro lenguaje, sí. Si el output de Rust difiere del output de Python para el mismo input, alguien miente. Y eso es exactamente el tipo de verificación que quiero probar.
Además, Rust tiene propiedades que hacen el experimento más interesante:
- El compilador como primera defensa. Nulls, type mismatch, data races: categorías enteras de bugs que en Python pasan en silencio, en Rust no compilan. ¿Cuántas alucinaciones del LLM frena el compilador antes de que lleguen a un test? Quiero medirlo.
- Concurrencia real.
tokiopermite un spawn por conversación. En Python es un dolor. Esta es la mejora funcional que sí justifica el port. - Binario estático. Un ejecutable de 10MB en vez de un
pip installcon 47 dependencias. Para distribución, no tiene precio. - Que mola. Esto no es una razón técnica. Me la pela.
La aventura (y la invitación)
RustyClaw — así se llama el port — va a ser un experimento documentado en público. Cada módulo portado, un post. Con datos reales: cuántos tokens consumí, cuánto costó, cuántas veces la IA alucinó, cuánto tardé en pelearme con el borrow checker. Sin maquillar.
Si tardo 3 horas en algo que en Python haría en 10 minutos, lo diré. Si el LLM inventa un crate que no existe (spoiler: lo hará), lo documentaré. Si al final del port resulta que no ha merecido la pena, lo admitiré.
Todo el mundo dice «usé IA para escribir código». Nadie publica cuánto le costó, cuántas veces le mintió, y si el resultado aguanta en producción. Eso es exactamente lo que voy a hacer.
Y quiero que me acompañes. Porque esto va a ser una aventura — con sus peleas contra el compilador, sus momentos de «¿por qué no compila si es OBVIO?», y sus pequeñas victorias cuando un test diferencial pasa en verde. Va a ser divertido. O al menos, honesto.
El stack (la chuleta)
Si eres pythonista, la columna de la izquierda te sonará. Si eres rustacean, la de la derecha. Si no eres ninguno, bienvenido al caos.
| Capa | Python (nanobot) | Rust (rustyclaw) |
|---|---|---|
| Runtime async | asyncio |
tokio |
| HTTP | httpx |
reqwest |
| LLM routing | litellm |
No existe — router propio |
| Telegram | python-telegram-bot |
teloxide |
| Discord | websockets (raw) |
tokio-tungstenite (raw) |
| Config | pydantic |
serde + figment |
| CLI | typer |
clap |
| Errors | str(e) |
anyhow + thiserror |
| Logging | loguru |
tracing |
| Copiloto IA | — | Claude Code + Codex |
| Task runner | make |
just |
| Issues | — | linear CLI |
La fila que más duele es LiteLLM. En Python, te enruta a 100+ proveedores de LLM con una sola llamada. En Rust no existe nada parecido. Toca construir un router propio. La buena noticia: el 80% de los proveedores son compatibles con la API de OpenAI, así que con async-openai + base_url custom cubrimos casi todo. Anthropic necesita implementación a medida.
Unas ~300 líneas de Rust. Suena manejable. Suena.
Las tres últimas filas son el meta-stack: las herramientas con las que voy a construir el port. Claude Code para las sesiones interactivas donde necesito pensar en voz alta con el LLM. Codex para los portes mecánicos donde el contexto ya está claro y quiero velocidad. just en vez de make porque me apetece probar algo que no requiera tabs literales para funcionar (sí, en 2026 seguimos con eso). Y linear para gestionar el backlog sin salir de la terminal.
La estrategia anti-alucinaciones (la parte seria)
Aquí es donde la teoría del desarrollo adversarial se encuentra con la realidad. Un LLM asistiendo en un porte de esta magnitud es una máquina de inventar cosas plausibles.
El riesgo principal no es que el código no compile. Rust no te deja compilar basura. El riesgo es que compile, pase los tests, y haga lo incorrecto en silencio. Exactamente el silent failure que documenté hace dos semanas.
Cinco capas de defensa:
1. El compilador de Rust. Elimina nulls, type mismatch, data races. Primera línea de defensa gratuita. Pero que compile no significa que sea correcto.
2. Tests diferenciales. Mismo input → nanobot Python → output. Mismo input → rustyclaw Rust → output. Si no coinciden, hay un problema. La fuente de verdad es el código Python que ya funciona. Esta es la capa estrella del experimento.
3. Provenance tracking. Cada fichero portado lleva un header con el fichero Python de origen, la sesión de LLM que lo generó, y si pasó los tests diferenciales. Trazabilidad total.
4. Verificación de crates. Cada crate que el LLM sugiera → verificar manualmente en crates.io y docs.rs. Los LLMs inventan crates que no existen y APIs que no funcionan así. Con total seguridad y aplomo, como quien te dice que la capital de Australia es Sydney.
5. Logging de incidentes. Cada alucinación detectada → issue con label hallucination. Material para los posts y para no cometer el mismo error dos veces.
La regla de oro:
El sistema de verificación debe ser externo al generador.
Si el LLM genera el código, los tests y los fixtures, estás validando ficción con ficción. Los tests diferenciales contra el Python original son la capa que rompe el ciclo. Y la gracia de un porte es que esa capa existe de forma natural.
Does it matter?
Vamos con la pregunta incómoda. ¿Importa realmente portar esto a Rust?
| Métrica | Python | Rust (estimado) | ¿Importa? |
|---|---|---|---|
| Latencia de respuesta | ~200ms overhead | ~5ms overhead | No. El LLM tarda 2-5 segundos. |
| RAM | ~50MB | ~5MB | No. Mi servidor tiene 8GB. |
| Concurrencia | 1 mensaje a la vez | N mensajes en paralelo | Sí. |
| Startup | ~2s | ~50ms | Meh. |
| Binario | pip install + 47 deps |
Un ejecutable | Sí. |
| Type safety | str(e) everywhere |
Result<T, E> |
Sí. |
| Que mola | No | Sí | Subjetivo. |
Tres de siete. Siendo generosos, cuatro. La mejora de latencia y RAM es irrelevante porque el cuello de botella siempre es la llamada al LLM. La concurrencia sí importa si tienes múltiples usuarios. El binario estático es una mejora real. Y los tipos… después de ver cómo str(e) oculta bugs durante meses, eso sí importa.
¿Justifica semanas de trabajo? Como port aislado, probablemente no. Como banco de pruebas para el desarrollo adversarial con datos reales publicados, creo que sí. Al final de la serie tendremos números para decidir, no opiniones.
Los números, al desnudo
Cada sesión de trabajo queda registrada en un CSV en el repo:
date,llm,model,module,tokens_in,tokens_out,cost_usd,duration_min,loc_python,loc_rust,hallucinations,tests_pass
LLM usado, tokens consumidos, coste, duración, líneas portadas, alucinaciones detectadas, tests pasando. Todo público. Todo verificable.
Al final de la serie, cualquiera podrá sumar la columna de cost_usd y decidir si el RIIR mereció la pena. Cualquiera podrá contar las alucinaciones y decidir si el desarrollo adversarial funciona o es humo. Spoiler: no tengo ni idea de cuáles serán los números. Y eso es lo que lo hace interesante.
Acompáñame
- Repo: github.com/frr149/rustyclaw — código, issues, tracking
- Blog: Cada fase tendrá su post aquí, en la serie RustyClaw: Rewrite It In Rust
- Backlog: Público en Linear, visible en los issues de GitHub
¿Qué hay mejor que un AGI? Un AGI reescrito en Rust. Ya lo dice el meme. Ahora vamos a comprobarlo.
Read this article in English.
