282 commits, primer fin de semana en el registro público

La API en C fue el commit que importó: el momento en que el runtime tuvo una superficie pública estable, dos corrientes de trabajo escrito por agentes dejaron de estorbarse entre sí. Así se ve un runtime nativo de IA cuando el bucle encaja.

El sábado pasado presenté una pila de issues y apunté un agente de codificación autónomo hacia la cola. Para la noche del domingo, sentado en la mesa de la cocina con la laptop abierta por última vez antes del lunes, habían aterrizado 282 commits en el repositorio del runtime. Yo fui el autor de una pequeña fracción de ellos. Un agente de codificación autónomo fue el autor de la mayor parte del resto.

La razón por la que el conteo se ve como una semana de sprint de trabajo es que el trabajo ha estado ocurriendo continuamente mientras no estoy frente al teclado. Yo estoy frente al teclado los fines de semana. Los agentes no tienen un trabajo diurno. La producción es lo que resulta de ese arreglo.

Cómo funciona la cola

El sábado por la mañana es día de presentación. Me siento con café y escribo issues de GitHub. Cada uno es una pieza de trabajo acotada con precisión que el motor necesita a continuación. La forma es más o menos:

• Un subsistema o una funcionalidad por issue
• Un criterio de aceptación claro que el agente pueda autoverificar
• Referencias a la documentación relevante, la especificación, y cualquier archivo existente que el trabajo deba tocar
• Una etiqueta explícita de “agent-queue”

También hay un flujo de trabajo nocturno (issue #37 en el repositorio del runtime este fin de semana) que asegura que la cola nunca caiga por debajo de quince issues de agente abiertos. Si eso ocurre, el flujo redacta tareas de relleno a partir de la hoja de ruta. El agente lee la cola, toma el siguiente que puede hacer, abre un PR en borrador, itera, y eventualmente se marca listo para revisión.

Del sábado al domingo reviso y hago merge. Donde el agente se equivocó en algo, cierro el PR, afino el issue, y lo vuelvo a presentar. Donde el agente lo hizo bien, el PR aterriza y el issue se cierra. El ritmo es presentar al inicio del fin de semana, revisar durante ambos días, y dejar una cola fresca detrás cuando la laptop se cierra el domingo por la noche. El agente muele la cola mientras yo estoy de vuelta en mi trabajo diurno.

Ese es el flujo de trabajo. No es sutil. La razón por la que vale la pena escribirlo es que funciona.

Lo que se construyó

Los titulares de los 282 commits:

• Un bucle principal de runtime real, no solo un esqueleto
• Un rastreador de latencia que mide el tiempo de extremo a extremo desde la entrada del sensor hasta el renderizado
• Un monitor de uso de memoria con umbrales configurables y reportes periódicos
• Un subsistema de logging con niveles INFO / WARNING / ERROR, salidas a consola y archivo
• Manejo de errores con manejadores de señal para apagado ordenado
• Una API en C que expone el runtime para que el SDK pueda enlazarse contra él
• Un sistema de gestión de módulos / agentes en la API en C para la integración del SDK
• El modelo de concurrencia del runtime: colas de tareas y hilos trabajadores
• Un arnés de pruebas exhaustivo
• Verificación de ABI y validación del enlace con el SDK
• Especificación de gafas inteligentes AR1+ finalizada como el objetivo de producto

Nada de eso es glamoroso. Todo eso es lo que un runtime de RA necesita antes de que se pueda construir encima cualquiera de las cosas interesantes.

El commit más importante, en retrospectiva, es la exposición de la API en C. En el momento en que el runtime tuvo una superficie pública estable a la que el SDK podía enlazarse, el trabajo del runtime y el trabajo del SDK dejaron de estorbarse entre sí. Antes de ese commit, cada cambio en un repositorio tenía que sincronizarse cuidadosamente con el otro. Después de él, se desacoplaron. Dos corrientes de trabajo escrito por agentes podían correr en paralelo sin producir conflictos de merge.

Lo que me sorprendió

Tres cosas.

El agente es más rápido en la infraestructura aburrida de lo que yo habría sido. Telemetría, logging, manejo de errores, arneses de prueba. Estos son el tipo de tareas donde un humano se distrae porque el trabajo no es glamoroso. El agente no se distrae. Simplemente hace aterrizar el diff.

El agente es conservador en arquitectura. Dale un issue que diga “implementa un rastreador de latencia que mida el tiempo de sensor a renderizado,” y construye exactamente eso. No inventa una metafísica de qué significa la latencia ni propone una forma distinta para la API. Eso es bueno. La arquitectura es mi trabajo. La implementación es el trabajo del agente.

Rellenar la cola es el cuello de botella. Cuando el agente lanza quince PRs en un día y la cola está vacía para la tarde, el rendimiento deja de tratarse de qué tan rápido trabaja el agente. Empieza a tratarse de qué tan rápido puedo articular el siguiente conjunto de tareas. Eso ha reformado las mañanas de sábado. La primera hora es presentar issues.

Lo que se rompió

Dos cosas, ninguna fatal.

El build de CMake se rompió dos veces cuando el agente hizo aterrizar código que compilaba de forma aislada pero no enlazaba contra el resto del runtime. Ambas veces la solución fue la misma: el agente todavía no tiene visibilidad completa sobre el grafo de enlace del proyecto. La solución está en el encuadre del issue. De ahora en adelante, cada issue que toque una biblioteca dirá explícitamente qué otras bibliotecas se enlazan contra ella.

El arnés de pruebas se añadió tarde en la tanda e inmediatamente sacó a la superficie cuatro bugs en PRs anteriores que habían pasado pruebas de humo manuales pero fallaban con el nuevo arnés. La lección ahí es la poco atractiva: escribe las pruebas como parte de la funcionalidad, no como un seguimiento posterior. El agente hace esto cuando el issue lo indica. No lo hace cuando el issue no lo indica. Hazlo indicarlo siempre.

Lo que quiero que sepan los socios y constructores

La forma de este motor se está construyendo ahora mismo. Para fin del próximo mes la mayoría de las decisiones fundacionales estarán fijadas. Si estás en un laboratorio de modelos y tienes opiniones sobre cómo debería conectarse la capa de IA, esta es la ventana en la que las opiniones son baratas de incorporar. Si eres un desarrollador pensando en la integración con Unity o Unreal, el SDK se está moldeando este fin de semana y los bindings reflejan lo que el runtime puede hacer. Prefiero saber de ti en la semana seis que en la semana sesenta.

El repositorio del runtime está abierto. El repositorio del SDK está abierto. La cola de issues abiertos está abierta. Ver esto suceder en tiempo real es todo el punto.

282 commits, primer fin de semana en el registro público. Domingo en el banco. Lunes que viene.