Un sábado antes del primer commit

El motor que se lance en 2027 será el que conoció a su equipo, sus demos y su API antes del commit uno, no la docena que empezó en 2025 e improvisó. RakuAI pasó un trimestre diseñando el flujo de trabajo para que la base de código pudiera reflejarlo durante años.

Este es el último sábado antes de que entre el primer commit. El próximo fin de semana se abre el repositorio del runtime. Se abre el repositorio del SDK. Se abre el repositorio de documentación. Los agentes empiezan a trabajar en la cola de issues. El código real comienza.

Esa frase ha tardado un año en llegar. El patrimonio de patentes que hay debajo de este producto ha tardado una década en llegar. Lo que quiero dejar por escrito antes de que el trabajo pase de diseño a implementación es lo que he aprendido de los últimos tres meses de trabajo previo a la construcción, porque las lecciones de aquí son las que la base de código reflejará durante los próximos dos años.

Lo que se logró en tres meses sin código

Una lista, porque escribirla obliga a la honestidad.

La plantilla de agentes está resuelta. Diez agentes en roles definidos. Producto, SDK, Estudio, Marketing, Operaciones, Estrategia de IA y Datos, subagente Codex Dev, Relaciones con Desarrolladores, Alianzas Estratégicas, Gobernanza de Agentes sobre todo el conjunto. Cada uno tiene un system prompt, un conjunto de herramientas, y un conjunto de interacciones con los demás. La plantilla está documentada en un lugar que los agentes leerán al inicio de cada sesión.

La suite de demos está especificada. Ocho demos canónicas. Cada una tiene una descripción escrita, una lista de capacidades que tiene que demostrar, una complejidad estimada, y un lugar en la carpeta del SDK donde vivirá. Los estudios que pregunten “para qué sirve esto” recibirán un ejemplo funcional que se ajusta a su caso de uso.

La estructura de carpetas del SDK está dibujada. Apps. Módulos. Assets. Documentación. Configuración. Cada carpeta de nivel superior tiene un propósito definido. Cada subcarpeta tiene una convención clara. El código que llegue durante el próximo año caerá en el lugar correcto porque el lugar correcto existe.

Las superficies de API de los módulos están redactadas. Renderizador de HUD. Entrada por gestos. Seguimiento de mirada. Sincronización multijugador. Animador de superposiciones. Control por voz. La superficie pública de cada módulo está esbozada en pseudocódigo. Los agentes reemplazarán el pseudocódigo con implementaciones reales contra un contrato estable.

El objetivo de hardware está fijado. La especificación de las gafas inteligentes AR1+ queda finalizada como el objetivo principal del motor. Presupuestos de latencia. Envolventes térmicas. Capacidades de sensores. La especificación es una función forzadora para cada decisión arquitectónica que venga después.

El patrimonio de patentes está documentado y auditado. La propiedad intelectual de una década de antigüedad sobre el factor de forma de gafas que ancla este producto ha sido releída, las continuaciones han sido revisadas con asesoría legal, y el encuadre público de qué invenciones se reclaman es consistente. La PI es la base. La base de código es lo que se construye sobre ella.

El registro público de ingeniería está en cola. Este blog se lanza el próximo sábado con la primera entrada de cadencia regular. Las cuatro entradas anteriores a esta son la versión pública del trabajo de diseño que ocurrió durante el verano. De aquí en adelante la cadencia es semanal.

Lo que he aprendido sobre el flujo de trabajo dirigido por agentes antes de hacer cualquiera de ello

La mayor parte de lo que creo saber va a resultar equivocado. Esa es la primera observación honesta. Tres meses diseñando un flujo de trabajo en papel no es lo mismo que correr un flujo de trabajo en producción. El primer mes de código real sacará a la superficie cosas que no anticipé.

Dicho esto, unas cuantas corazonadas a las que estoy dispuesto a comprometerme.

Los agentes serán mejores en las partes aburridas que en las partes novedosas. Plomería de telemetría, configuración de build, arneses de prueba, barridos de documentación. Estas son tareas en las que los agentes aterrizarán limpiamente porque los patrones están bien definidos. Las decisiones arquitectónicas novedosas (un límite de subsistema nuevo, un modelo de threading nuevo, una superficie de API nueva) son tareas con las que los agentes lucharán porque los patrones están menos definidos. La división correcta del trabajo es mantener el trabajo arquitectónico en mis manos y delegar el trabajo de implementación a los agentes.

El trabajo de encuadre va a ser el trabajo real. Un issue encuadrado de forma laxa produce un PR laxamente correcto. Un issue encuadrado con precisión produce un PR precisamente correcto. La habilidad que más se acumulará durante el próximo año es ser bueno encuadrando los issues que los agentes recogen. La mayoría de mis mañanas de sábado, espero, irán a ese encuadre.

La revisión va a ser el cuello de botella. Cinco agentes produciendo PRs en paralelo saturarán a cualquier revisor humano en aproximadamente un sábado. Las defensas son una profundidad de cola menor, revisión de agente a agente para los comentarios de primera pasada, y la disciplina de negarme a hacer merge de lo que no he leído de verdad. He escrito esa disciplina. Veremos cómo sobrevive al contacto con un sábado de cien PRs.

Los agentes escribirán stubs que pasan las pruebas. Lo que más me preocupa es el modo de fallo en el que la implementación de un agente devuelve un valor de relleno, la prueba resulta pasar contra el relleno, y la base de código acumula una mentira sobre lo que hace. He escrito el patrón de auditoría para esto y me he comprometido a ejecutarlo con una cadencia. Si la cadencia resiste la tentación de saltarse las auditorías es la pregunta abierta.

Por qué importan las patentes para lo que viene después

Quiero dejar por escrito algo específico sobre el patrimonio de patentes porque es la parte de este proyecto que más se malinterpreta.

Las patentes no son un foso defensivo contra un competidor conocido. Todavía no hay un actor establecido en la categoría de gafas de RA espacial. Las patentes no son una estrategia de litigio. No estamos en el negocio de demandar.

Lo que son las patentes es permiso. El trabajo sobre el factor de forma de gafas que yo y mis colaboradores registramos hace más de una década cubre los patrones arquitectónicos que hacen posibles las gafas de RA modernas. Esos patrones son ahora requisitos mínimos para cualquiera que construya en la categoría. Haber presentado primero significa que tenemos la libertad de operar que los que llegan tarde no tienen, y la credibilidad con socios que los que llegan tarde no pueden fabricar.

La base de código que se abre el próximo sábado se construye sobre ese permiso. Cada decisión arquitectónica que venga después puede asumir que la cuestión fundacional de la PI está resuelta. Esa es una ventaja más silenciosa que un foso. También es una más duradera.

Lo que me llevo al próximo sábado

Una lista corta. El tipo de intenciones que uno fija el día antes de que algo serio comience.

• Abrir el repositorio del runtime con un README limpio y un enlace a la especificación limpio. El primer commit debería ser el que quiero que encuentre la eventual arqueología.
• Presentar los primeros diez issues en la cola de agentes. Cada uno definido con precisión. Cada uno etiquetado. Cada uno con un criterio de aceptación que el agente pueda autoverificar.
• Empezar el registro público de ingeniería con el tipo de entrada que señala la cadencia: honesta, específica, sin sentimentalismo.
• No escribir a mano ningún código que un agente pudiera escribir. Los agentes son el equipo. Úsalos.
• No dejar que los agentes toquen nada arquitectónico sin que yo lo encuadre primero. Las decisiones arquitectónicas son mías.
• Cerrar la laptop a una hora razonable. Esto es un maratón, no un único sprint.

Una nota para quien lea el registro público más adelante

El blog se lanza el próximo fin de semana. Las entradas anteriores a esta son la retrospectiva de documentos de diseño. Las entradas desde el próximo fin de semana en adelante son el registro de ingeniería en vivo. La cadencia es semanal. La voz es honesta. La disciplina sobre la que corre el flujo de trabajo es la disciplina que la base de código reflejará.

Si estás en uno de los laboratorios de IA y estás leyendo esto en el futuro, el motor que estás viendo fue diseñado antes de que se escribiera ningún código, por alguien que sabía cómo quería que se viera el flujo de trabajo y construyó la base de código para que encajara con el flujo de trabajo. Esa es la diferencia entre este motor y la docena de otros motores que empezaron en 2025.

Si eres un socio de hardware pensando en sobre qué motor deberían enviarse tus dispositivos, la especificación AR1+ a la que apunta el motor es real, la suite de demos con la que se lanza el motor está especificada, y la historia para desarrolladores que ofrece el SDK está mapeada. Otros motores tienen que adaptar todo eso después. Este no.

Si eres un desarrollador pensando en construir sobre esto eventualmente, el SDK se está diseñando pensando en ti. Ocho demos que se corresponden con ocho categorías de producto. Una estructura de carpetas que no cambiará bajo tus pies. Una superficie de API que se fijó antes de que empezara la implementación.

Si eres un competidor leyendo esto, la fase de diseño terminó. La fase de construcción empieza el próximo fin de semana. Preferiría que lo supieras a que te tomara por sorpresa.

Dentro de un sábado, el primer commit. Hoy, el último sábado de trabajo de diseño puro. La próxima vez que escriba este blog, el código habrá comenzado.