De Blade a Raku: un renombrado de sábado en todo el código

Un nombre es una promesa. Raku (facilidad, comodidad, el toque humano) es la promesa detrás de un runtime construido para que las experiencias de IA se sientan humanas, no mecánicas. Este es el fin de semana en que se hizo realidad.

El runtime tenía un nombre cuando empecé a construirlo. El nombre era un marcador de posición, del tipo que te permite dejar de preocuparte por el nombre y empezar a escribir código. Sabía que era un marcador de posición cuando lo elegí. El nombre real estaba esperando a que unas cuantas cosas se asentaran.

Este fin de semana el marcador de posición desapareció. El runtime ahora se llama Raku.

Por qué ahora

Tres razones.

El objetivo de producto se estabilizó. Cuando el runtime era AR1+ y luego AR2 Gen1 y luego quizás una de tres rutas de hardware distintas, nombrarlo según la familia de dispositivos no tenía sentido. Ahora que el giro hacia RA está asentado, el motor puede tener su propio nombre, que no depende de en qué dispositivo se lance.

Las conversaciones de asociación se están poniendo serias. Una conversación de asociación que se pone seria no puede sobrevivir a un nombre provisional en el código. Los proveedores no se asocian con código que se llama a sí mismo “BladeRuntime” en unos archivos y “AR1+Runtime” en otros. El renombrado es una condición previa para que esas conversaciones avancen más.

La marca tiene que significar algo. Raku en japonés significa facilidad, comodidad, disfrute. También es el nombre de una tradición de cerámica de té japonesa que valora la irregularidad y el toque humano por encima de la precisión mecánica. Ambas cosas son señales sobre para qué sirve el motor: experiencias fáciles de crear y que se sienten humanas, no mecánicas. El kanji 楽 aparece en el logotipo. La elección del nombre no es arbitraria. Es la primera pieza de la identidad de la empresa.

Qué implicó el cambio de marca

Un barrido por todo el código. Dos PRs completaron la mayor parte en ejecuciones de agentes consecutivas. Los agentes hicieron el trabajo mecánico, lo cual es bueno porque el trabajo mecánico era enorme. Aproximadamente:

• Cada referencia a “ar1-runtime” en código, documentación y CI cambió a “raku-runtime”
• Cada referencia a “Blade” en la marca y el empaquetado cambió a “Raku”
• La biblioteca nativa del runtime se renombró de ar1plus a raku
• Se actualizaron todos los prefijos de símbolos exportados
• Se actualizaron todos los nombres de objetivos de CMake
• Se actualizaron todas las referencias de rutas de include
• Se actualizaron todas las referencias cruzadas de la documentación
• Se actualizaron todos los readmes de aplicaciones de ejemplo
• Se cambiaron el logotipo y los recursos de marca

Dos PRs. Aproximadamente ciento diez archivos tocados entre ambos. Los dos se fusionaron sin romper el build, que era la métrica que importaba.

Lo que aprendí de hacerlo de esta manera

Tres cosas, cada una útil para cualquiera que planee un barrido en un código construido por agentes.

El agente hace el renombrado más rápido que yo, pero solo si el issue es preciso. El issue que produjo la mayor parte del renombrado decía exactamente qué símbolos cambian, qué rutas cambian, qué documentación cambia y qué patrones dejar en paz (entradas de changelog, registros históricos de decisiones, ramas archivadas). El agente siguió las instrucciones. El resultado fue un renombrado limpio. La versión del issue que probé dos días antes era menos precisa, y el renombrado volvió con treinta lugares donde el agente había renombrado con demasiada agresividad, incluyendo referencias en mensajes de commit antiguos que deberían haberse quedado por motivos arqueológicos.

Los PRs de renombrado quieren ser pequeños incluso cuando tocan todo. Los dos PRs que hicieron el renombrado no fueron sutiles. Cada uno tocó docenas de archivos. Eran pequeños en el sentido de que hacían solo una cosa. Cada PR era solo-renombrados, sin cambios funcionales mezclados. Mezclar un renombrado con incluso un pequeño cambio funcional hace que el PR sea imposible de revisar, porque el revisor humano tiene que leer cada línea para asegurarse de que el cambio funcional es solo el cambio funcional. Los renombrados puros se pueden revisar en quince minutos.

La marca tiene que estar lista antes de que el renombrado salga. La mitad del trabajo de este fin de semana no estuvo en el código. Fue elegir el nuevo nombre, registrar dominios, asegurar identificadores, acertar con el kanji, diseñar el logotipo. El renombrado del código es el último paso, no el primero. Si haces el renombrado del código y luego te das cuenta de que la marca no está lista, te quedas atascado con otra ronda de renombrado.

Lo que no cambió

La arquitectura no cambió. La API en C no cambió. La hoja de ruta no cambió. El objetivo de producto no cambió. Cualquiera que leyera el código el fin de semana antes del renombrado y el fin de semana después vería el mismo motor haciendo las mismas cosas.

Este fue el tipo correcto de renombrado. Fue un cambio de etiqueta, no una redirección.

Lo que los socios y constructores se llevan de esto

Si eres un integrador mirando el runtime ahora: en cualquier lugar donde veas “raku-runtime” en nuestros repositorios y empaquetado, es el mismo motor que se llamaba de otra manera el fin de semana pasado. No hay ruptura de compatibilidad. La API en C no ha cambiado. Los bindings del SDK no han cambiado. Las aplicaciones de ejemplo siguen funcionando.

Si buscas asociarte en un producto que se lance sobre este motor, el nombre ahora es estable. La conversación no tiene que empezar con “lo llamamos así por ahora, pero.” Puede empezar con “esto es lo que es Raku y para qué está construido.”

Si estás dentro de un equipo de dispositivos AR2 pensando en qué runtime apuntar en tu plataforma, el cambio de nombre también es una declaración sobre dónde está posicionado el motor en el mercado. Raku no es “el runtime AR1+ que creció.” Es su propia cosa, con su propia tesis, dispuesta a lanzarse en el hardware del socio que mejor encaje. El renombrado forma parte de esa declaración.

Fin de semana tranquilo, en el sentido de que nada funcional cambió. El tipo correcto de tranquilidad.