Anthropic reescribió la Messages API en Rust con Claude: la carga de CPU cayó entre un 40% y un 50%

Anthropic ha reescrito en Rust la Messages API, la interfaz mediante la cual los desarrolladores acceden a Claude. Según Katelyn Lesse, del equipo de Anthropic, que lo contó en el podcast Latent Space, entre los participantes del proyecto no había ni un solo desarrollador de Rust. El código lo escribió el propio Claude.

Las personas elaboraron el plan y comprobaron si el comportamiento de la implementación antigua y el de la nueva coincidían con tráfico real. El resultado, según lo resumió en X el autor Somi: la carga de CPU bajó entre un 40% y un 50%. La publicación acumuló más de 182 mil visualizaciones porque golpea uno de los dogmas más arraigados del sector: «nunca reescribas todo desde cero».

Quién hizo qué: el modelo escribe, las personas aceptan el trabajo

La división del trabajo importa aquí más que el lenguaje. Claude se encargó de escribir el código. Los ingenieros se ocuparon de dos cosas: el plan de reescritura y el criterio de aceptación. Ese criterio fue la comparación de la versión antigua y la nueva con peticiones reales. Si ambos servicios producen un resultado equivalente con el mismo tráfico, la nueva implementación se da por válida. Para ello no hace falta dominar los modismos de Rust; basta con saber describir con precisión qué debe hacer el servicio y verificarlo con datos.

Esto explica por qué «cero desarrolladores de Rust» no suena a disparate. Antes, la principal barrera para cambiar de lenguaje era la falta de gente capaz de escribir y revisar el código. Aquí la barrera se desplaza de la escritura a la verificación. El equipo dispone de una referencia: un sistema en producción que funciona, y la nueva versión debe comportarse exactamente igual que él. Ese planteamiento encaja bien con los modelos: la tarea está claramente definida y el resultado se comprueba de forma automática.

Qué significa un 40–50% menos de CPU

Para una API que atiende un enorme número de peticiones, el tiempo de procesador se traduce directamente en costes de infraestructura. Si con la misma carga el servicio consume la mitad de CPU, hacen falta menos servidores o la misma flota soporta más tráfico. Es una deducción nuestra a partir de la cifra, no una declaración de Anthropic: el resumen no dice cuánto dinero ahorró la compañía.

Hay otro aspecto llamativo. La táctica de «reescribir un servicio crítico en un lenguaje compilado con control estricto de memoria» se conoce desde hace tiempo. Antes costaba meses de trabajo de especialistas, y la mayoría de los equipos la descartaba. Si la mayor parte del código la escribe un modelo, el coste del experimento baja y la rentabilidad se ve de otra manera. El veredicto de Somi, «el consejo de no hacer una gran reescritura ha muerto», suena contundente, pero un solo caso no refuta la regla. Solo muestra en qué condiciones la regla deja de aplicarse.

Lo que no aparece en el resumen

La fuente es una publicación breve con un enlace al podcast, no un informe técnico. De ella no se deducen varias cosas importantes:

• qué parte exacta de la Messages API se reescribió: toda la pila o solo algunos componentes;
• cómo cambiaron la latencia y el rendimiento (throughput), y no solo la carga de CPU;
• cuánto tiempo llevó el trabajo y cuántas iteraciones necesitó Claude;
• qué discrepancias se encontraron entre la versión antigua y la nueva al compararlas y cómo se resolvieron;
• cómo mantendrá el equipo código en un lenguaje que nadie domina en él.

El último punto es el más incómodo. Un código que ninguna persona ha leído a fondo habrá que mantenerlo, depurarlo cuando aparezcan errores poco frecuentes y ampliarlo con nuevas funciones. Mientras Claude siga a mano, es abordable. Pero el coste a largo plazo de este enfoque no se aprecia a partir de un único caso.

Conclusión práctica

La receta que se puede aprovechar no depende de Rust. Primero hay que fijar el comportamiento del servicio existente: recopilar peticiones y respuestas reales y configurar la comparación entre dos implementaciones. Después, el plan y la aceptación quedan en manos de las personas, y el trabajo en borrador lo asume el modelo. Cuanto mejores sean el banco de pruebas y la ejecución en sombra del tráfico, más segura será la reescritura. Sin ellos, el modelo simplemente generará rápido mucho código sin verificar. Antes de repetir la experiencia de Anthropic, conviene esperar a la versión completa del relato y ver cómo resolvió el equipo las cuestiones que el resumen no recoge.