Dos meses en público, años bajo el capó

La mayoría de los motores "nativos de IA" atornillan un panel de chat a un editor. RakuAI trata al modelo como una entrada de control en cada fotograma, y a los dos meses, esa tesis ya es código en producción, no diapositivas.

El plan para este sábado era bajar el ritmo y pensar. Tres commits en todo el fin de semana, el número más bajo desde que empecé el registro público. Los agentes están corriendo más despacio a propósito; mi atención está en la arquitectura y no en entregar código nuevo. El código termina el fin de semana más o menos donde lo empezó, que es el estado correcto para el tipo de trabajo que estaba haciendo.

Hace dos meses el repositorio público del runtime era un README vacío. El motor y la cartera de patentes detrás de él se remontan mucho más atrás que eso. El tipo de fin de semana que vale la pena describir es aquel en el que el autor hace balance. Así que eso es esto.

Lo que el motor realmente es, hoy

Si tuviera que describir Raku en un párrafo a alguien que no ha estado siguiendo el registro, la descripción sería:

Un runtime de RA multiplataforma, escrito en C++ y expuesto a través de una API en C estable, con bindings de SDK para Unity y Unreal. Apunta principalmente a gafas de RA y corre en el hardware que haya disponible hoy (actualmente entrando en funcionamiento para el passthrough de Meta Quest, con builds de vista previa para escritorio y móvil). Está diseñado desde los cimientos bajo la premisa de que la IA es un asunto del runtime, no una función del editor. Se admite el anclaje submilimétrico. OpenXR es el objetivo de conformidad allí donde existen estándares. El código se construye con agentes de codificación autónomos en el equipo de desarrollo, trabajando a través de una cola pública de issues.

Ese párrafo habría sido una declaración de misión aspiracional el primer día. Ahora es una descripción de lo que hay en el repositorio.

Lo que me sorprendió de los últimos dos meses

Tres cosas.

El flujo de trabajo impulsado por agentes escaló más allá de lo que esperaba. Al empezar tenía la preocupación de que los agentes autónomos produjeran un código que funcionara en PRs aislados y se convirtiera en papilla a través de muchas fusiones. La papilla no ha ocurrido. El código es más coherente a los dos meses que códigos que he heredado de equipos humanos a los dos años. La razón es la disciplina sobre la que he estado escribiendo cada fin de semana (cola más pequeña, revisión más temprana, emparejamiento multi-proveedor para independencia de revisión, documentación como entrada). Esas disciplinas funcionan.

El giro de hardware fue menos costoso de lo que temía. Pasar de AR1+ como objetivo de producto a AR2 Gen1 a principios de octubre fue una decisión con la que estuve varios días porque el costo parecía grande. El costo real fue un par de PRs (un barrido de renombrado exhaustivo, un repaso de documentación). La razón por la que el costo fue pequeño es la arquitectura modular establecida desde el principio. Los subsistemas que no necesitaban saber sobre el límite de clase de dispositivo no tuvieron que cambiar. Los que sí lo necesitaban, cambiaron limpiamente a través de sus superficies bien definidas. Ese es el dividendo de trazar la arquitectura temprano.

Las conversaciones de asociación están ocurriendo antes de lo que planeaba. Esperaba estar en modo “construir el motor, lanzar una demo, luego tener conversaciones de asociación” hasta fin de año. La secuencia real ha sido “construir el motor, tener conversaciones de asociación en el camino que informen qué construir después, luego lanzar demos que se ajusten a lo que esas conversaciones necesitan”. NTT QONOQ. Meta. Las próximas todavía no las voy a nombrar. Las conversaciones son más afiladas que las demos en este momento, que es un buen lugar donde estar.

Dónde se ha asentado la arquitectura

Una lista breve de las decisiones arquitectónicas que ya no espero revisar:

• El runtime es C++ expuesto a través de una API en C estable. Otros bindings de lenguaje se apoyan sobre la API en C, no directamente sobre C++.
• El SDK es multi-binding desde el primer día. Unity y Unreal son de primera clase. Godot está en la hoja de ruta. Web-nativo está en la hoja de ruta. La API en C es el cuello de botella. Los bindings no lo son.
• Los subsistemas son DLLs. Cada uno tiene una superficie pública; nada dentro de un subsistema alcanza los internos de otro subsistema. Las superficies son PRs revisados.
• La IA es un asunto del runtime, no una función del editor. El trabajo de IA que vive en el motor corre en el paso de simulación de cada fotograma. El trabajo de LLM en la nube que vive en el motor se integra en el pipeline de voz en tiempo de ejecución. Ninguno de los dos es un panel en una herramienta de autoría.
• OpenXR es el estándar allí donde el estándar encaja. El código específico de proveedor se sitúa detrás de flags de funciones y patrones de proveedor. Adoptar un nuevo dispositivo objetivo conforme con OpenXR es una capa de pegamento específica del proveedor, no una reescritura del runtime.
• El proceso de desarrollo es multi-proveedor por diseño. El modelo que escribe una pieza de código no puede ser el modelo que la revisa. El laboratorio cuyo modelo es actualmente el mejor en un rol determinado obtiene ese rol hasta que otro laboratorio sea mejor.

Lo que todavía espero revisar:

• La división exacta del trabajo entre la inferencia en el dispositivo y la intención del LLM en la nube. Esto se afinará a medida que madure el trabajo de TFLite y a medida que socios reales ejerciten la interfaz del LLM en la nube. La línea actual es provisional.
• La forma del formato de archivo de definición de experiencias. Los huesos están ahí. El esquema evolucionará. Espero al menos un salto de versión mayor antes de que el formato se estabilice.
• La ubicación de la sincronización de estado para RA multijugador. Hoy tenemos un canal de deltas de baja latencia. Si la respuesta correcta a largo plazo es una malla de igual a igual, un servidor autoritativo alojado, o algún híbrido, todavía no está decidido. Las demos de dos jugadores que se lanzan en diciembre informarán esa decisión.

El camino hacia la preparación para producción de diciembre

He estado apuntando calladamente a un hito de diciembre en el que el motor esté “listo para producción para que los socios construyan demos serias encima.” Eso no es un lanzamiento público. Es la barra interna en la que estoy dispuesto a invitar a un equipo socio a empezar a construir sobre el runtime sin advertirles de media docena de aristas ásperas.

Lo que todavía tiene que ocurrir para superar esa barra:

• Los subsistemas de IA para el runtime (árboles de comportamiento, malla de navegación, simulación de multitudes, sistemas sensoriales, árboles de decisión). Actualmente esbozados en documentos de diseño; la implementación llega en diciembre y el primer fin de semana de enero.
• Limpieza de build de Windows MSVC. En realidad no he compilado el runtime bajo Visual Studio 2026 desde octubre. Estoy bastante seguro de que eso va a ser una pelea. Escribiré sobre ello cuando lo haga.
• Un paquete canónico de ejemplos que demuestre una experiencia de RA no trivial de principio a fin a través de los bindings de Unity y Unreal, con el pipeline de voz y el LLM en la nube conectados.
• Una vía de sincronización federada para distribuir actualizaciones de modelos a dispositivos en el campo. La pieza criptográfica necesita ser de calidad de producción, no de calidad de stub.
• El actualizador del runtime. Necesitamos poder enviar un nuevo build al kit de desarrollo de un socio y que se instale limpiamente.

Esa es la lista. Seis semanas para superarla. El volumen de commits de diciembre va a ser alto.

Lo que quiero que los constructores y socios se lleven de esto

Si has estado leyendo el registro público durante dos meses, has visto el motor tomar forma en tiempo real. El ritmo es alto; la disciplina es real; las decisiones arquitectónicas están documentadas. Esa es la cultura de ingeniería con la que se construye este motor. Es la cultura de ingeniería con la que trabajarás si construyes sobre él.

Si eres un socio pensando si iniciar una conversación seria: la conversación es más afilada que las demos ahora mismo, y eso es a propósito. Prefiero escuchar lo que tu producto realmente necesita y dejar que eso moldee lo que se construye, en lugar de construir una demo y luego tratar de ajustarla a tus necesidades después. La ventana para moldear lo que entrega diciembre está abierta hasta finales de noviembre.

Si eres un desarrollador esperando estabilidad: la estabilidad es el entregable de diciembre. El motor está hoy en una evolución lo bastante activa como para que no recomendaría construir código dependiente serio sobre él todavía. Dentro de dos meses la recomendación será diferente.

Sábado tranquilo. Dos meses después. De vuelta a construir el próximo fin de semana.