Empezando la cadencia semanal

El contenido generativo en un navegador está bien. El contenido generativo anclado a la pared de tu cocina real es el producto. Este es el motor que se construye para recibir dirección de tu modelo en cada paso de simulación: día cero, en público.

Este sábado empieza la cadencia semanal regular en este blog. Las cuatro entradas debajo de esta fueron los sábados de documentos de diseño de principios del verano: plantilla de agentes, suite de demos, estructura de carpetas, la última reflexión antes de que empezara el código. La cadencia de aquí en adelante es semanal. De lo que trata el blog no es nuevo.

Llevo más de una década pensando en gafas de RA, experiencias espaciales ancladas al mundo real, y la forma correcta del runtime que las dirige. Parte de ese pensamiento se convirtió en patentes a principios de la década de 2010, el patrimonio sobre el factor de forma de gafas que todavía ancla la PI detrás de lo que estamos construyendo ahora. Parte se convirtió en prototipos que nunca vieron la luz. La mayor parte corrió en segundo plano mientras yo hacía otro trabajo.

Lo que cambió el año pasado es que el resto del mundo finalmente se puso al día. La computación es suficientemente pequeña. La óptica es suficientemente buena. Los LLM en la nube son suficientemente reales. La inferencia en el dispositivo es suficientemente rápida. El producto que era una idea adelantada una década a su tiempo es, finalmente, un producto que se puede lanzar.

Así que empecé a lanzar. La tanda actual de código lleva varios meses. Los commits viven en repositorios privados que ahora estoy sacando a la luz mientras los limpio y consolido la base de código. Este blog es el registro público de aquí en adelante.

Cómo se verán los próximos meses

La forma del plan de este sábado, como muestra de lo que viene:

• El runtime: un borrador de la especificación de gafas inteligentes AR1+ está sobre el escritorio esta mañana. Versiones en PDF, PowerPoint y Markdown para que un LLM pueda razonar sobre ella, un socio pueda leerla, y un diseñador pueda revisarla. El punto es la especificación, no el formato. El formato es para los lectores.
• Un main.cpp y un esqueleto de bucle principal del runtime, recién subido.
• Un header de rastreador de latencia y un stub de implementación. La latencia va a ser la métrica que defina este motor.
• Un flujo de build con CMake en CI para que cada push obtenga un build limpio desde una máquina limpia.
• Una guía de incorporación para Copilot para que los agentes del equipo sepan cómo funciona el equipo.

El repositorio del SDK también recibió su propio andamiaje este sábado. Un ejemplo temprano de HelloAR para Unity. Un ejemplo temprano de HelloAR para Unreal. Esqueletos de header para ambos bindings. Un flujo de publicación de paquetes.

Nada de eso es lanzable. Todo eso es lo que se necesita antes de que algo lanzable sea posible. El patrón de poner ambos repositorios en marcha al mismo tiempo, con un acoplamiento deliberado en las costuras, va a ser un tema recurrente.

Por qué una especificación de gafas inteligentes el primer día en público

La especificación es algo deliberado. La mayoría de los motores eligen una arquitectura de runtime y luego salen a buscar productos que plausiblemente pudieran lanzarse sobre ella. Yo lo estoy haciendo en el orden contrario. El producto son gafas de RA que la gente lleva puestas en el mundo, y el motor tiene que tener la forma correcta para ese producto. Así que la especificación se escribe primero, incluso cuando es tosca.

No es un documento de marketing. Es una función forzadora. Dice sobre qué tipo de hardware tiene que correr el motor, cuál es el presupuesto de latencia, cómo tiene que verse la superficie de IA en la práctica. Cada decisión arquitectónica posterior puede apuntar a esa especificación y preguntar “¿esta decisión sirve a la especificación, o sirve a algún otro motor que preferiría construir en su lugar?”. Esa segunda categoría es donde los proyectos de motores van a morir, y me he mantenido fuera de ella antes y pretendo mantenerme fuera de ella ahora.

Por qué una guía de Copilot el primer día

La otra cosa deliberada de este fin de semana es la guía de incorporación de Copilot. La primera versión es tosca. Se reescribirá diez veces. Pero la guía existe porque los agentes son parte del equipo, y el equipo necesita saber cómo funciona el equipo.

La guía dice:

• Cuál es la estrategia y qué motor no estamos construyendo
• Dónde vive la hoja de ruta
• Cómo se presentan, se toman y se cierran los issues
• Cómo se ve un buen PR
• Qué se supone que debe hacer un revisor (donde el revisor a veces soy yo y a veces otro agente)

El encuadre de “los agentes leen documentación” no es un truco. Es la realidad práctica de correr un flujo de trabajo donde el equipo es un humano los fines de semana y varios asistentes de codificación autónomos en servicio continuo. Si la guía es mala, el trabajo es malo. Si la guía es buena, el trabajo es correcto y el costo de revisión baja.

Por qué el registro público ahora

Unas cuantas razones.

Las patentes son antecedentes de una década de antigüedad de los que nadie habla porque nosotros no hablamos de ellos. El trabajo sobre el factor de forma de gafas al que se remonta el motor ha sido concedido y continuado silenciosamente durante años. Quiero que el registro público de ingeniería apunte al linaje real. La RA espacial no es algo nuevo que alguien recogió el verano pasado. El trabajo viene de atrás.

Las conversaciones de alianzas están empezando. Socios de hardware, laboratorios de IA, estudios. Esas conversaciones se afinan cuando hay un registro público de ingeniería que se puede leer en lugar de una presentación. La presentación es la versión pulida. El blog es la versión real.

El flujo de trabajo de desarrollo es genuinamente nuevo y vale la pena mostrarlo. Agentes de IA en el equipo desde el primer día de la fase pública. Múltiples proveedores. Ramas paralelas. Cola pública de issues. Nada de eso se inventó para este proyecto; lo inusual es hacerlo todo a la vez en algo tan serio. Quiero dejarlo escrito conforme sucede, mientras las lecciones aún están lo bastante frescas como para ser honestas sobre ellas.

Qué quiero que los socios y constructores se lleven de esto

Si estás en uno de los grandes laboratorios de IA y lees esto, aquí está el argumento. El motor se está construyendo explícitamente para recibir dirección de tu modelo. No atornillado. No en un panel de editor. En el runtime, en el paso de simulación, en cada fotograma. Las decisiones arquitectónicas están ocurriendo ahora mismo, en público, con un rastro documental explícito. Si tu modelo mejora en entender un espacio físico real en el que el usuario está parado, este motor es donde puede hacer algo con ese entendimiento.

Si eres un desarrollador pensando en construir sobre esto eventualmente, el SDK se mueve al mismo ritmo que el runtime. Los ejemplos de Unity y Unreal quedaron sembrados en el repositorio del SDK a partir de este fin de semana. Todavía no funcionan. Funcionarán. La razón por la que ambos bindings existen en esta etapa es para que nunca llegue un momento dentro de seis meses en que la arquitectura del runtime esté fijada y el SDK tenga que deformarse para encajar.

Si estás observando la señal temprana como consumidor, la señal es esta: el motor se está construyendo alrededor de la suposición de que las experiencias más interesantes son experiencias de RA en lugares reales, y la IA es lo que hace que esas experiencias reaccionen. El contenido generativo en un navegador está bien. El contenido generativo pegado a una pared de tu cocina es el producto real.

Hoy es sábado. El blog está en vivo. De vuelta a construir mañana.