Validar el hardware antes de que llegue el silicio

La respuesta tradicional a esperar por el silicio es sentarse y esperar. La respuesta moderna es construir primero todo lo que depende del hardware y tenerlo todo en verde antes de que lleguen las piezas, así tu hardware se lanza sobre RakuAI más rápido que sus competidores.

Una decisión que había estado masticando durante la semana laboral esperaba en la mesa de la cocina cuando empezó el fin de semana. Cambiar el objetivo de producto de AR1+ a AR2 Gen1. Construir todo lo que depende de la nueva especificación antes de que llegue el silicio, para que cuando el silicio llegue, la validación empiece el primer día en lugar del día noventa.

Hay una etapa por la que pasa todo producto de hardware en la que la especificación existe, el plan de validación existe, el arnés de pruebas existe, y el silicio real no. La respuesta tradicional es sentarse y esperar. La respuesta moderna es construir primero todo lo que depende del hardware, y tenerlo todo en verde antes de que se lancen las piezas.

Este fin de semana fue eso. La plataforma objetivo cambió oficialmente de AR1+ a AR2 Gen1, y la respuesta de ingeniería fue construir de inmediato la infraestructura de validación que la nueva plataforma necesitará, antes de que ninguno de nosotros toque la nueva plataforma.

Lo que aterrizó

Cinco cosas, todas aterrizadas este fin de semana:

• La infraestructura de puesta en marcha del dispositivo AR2 Gen1 e integración de sensores
• Una suite de pruebas de conectividad Wi-Fi 7 y estabilidad de seguimiento
• Un marco de validación térmica y de energía
• Pruebas de humo de CI con análisis de métricas y reportes
• La documentación de validación de hardware de AR2 Gen1 y la especificación de estándares de producción

Todo controlado por feature flags para que la ruta de código de AR1+ siga funcionando y nada en el runtime existente retroceda. Los agentes que hicieron aterrizar estos PRs hicieron correctamente la disciplina aburrida: cada archivo nuevo está oculto detrás de un flag de build, cada adición de API es no disruptiva, cada prueba corre en CI aunque no haya un dispositivo AR2 contra el cual correr. Las pruebas simulan. La simulación es suficientemente buena como para detectar desviación de interfaz, exportaciones faltantes, y flujos de sensor rotos.

Este fue un fin de semana de 77 commits. La mayoría de esos commits están al servicio de un dispositivo que no puedo sostener.

Por qué esto es sensato

Unas cuantas razones.

La validación de hardware que se lanza junto con el hardware es validación de hardware que llega seis meses tarde. El marco térmico y de energía escrito este fin de semana se usará el día en que el primer kit de desarrollo de AR2 llegue a mi escritorio, no tres meses después. La primera regresión térmica de la plataforma será detectada por una prueba existente, no por un humano notando que el dispositivo está caliente.

Un arnés de pruebas sin un dispositivo sigue siendo un arnés de pruebas. Corre contra trazas de sensor simuladas. Esas trazas vienen de la era AR1+ y de la especificación. No son perfectas. Detectan bugs de interfaz, bugs de integración, y bugs de recolección de métricas. No detectan los bugs que solo aparecerán bajo silicio real. Eso está bien. Los bugs que sí detectan son los bugs en los que habríamos pasado la primera semana de tiempo con hardware real cazando, y ahora no tenemos que hacerlo.

El acto de escribir el arnés aclara la especificación. La mitad del documento de estándares de producción que aterrizó para la noche del domingo existía solo como intención difusa al inicio del fin de semana. Escribir las pruebas de validación obligó a que la especificación se convirtiera en números concretos. Presupuestos de fotogramas. Envolventes térmicas. Umbrales de estabilidad de Wi-Fi 7. El arnés hizo preciso el documento. Ese es el entregable real.

Cómo manejó el agente el cambio de plataforma

El cambio de AR1+ a AR2 Gen1 no se manejó limpiamente la primera vez. A mitad de fin de semana, el agente hizo aterrizar un PR que referenciaba “AR1+” en lugares donde la nueva ruta de código debería haber dicho “AR2.” Eso aterrizó porque el encuadre del issue no señalizó el renombrado. La solución fue un PR separado titulado “Corregir discrepancia entre dispositivo AR1+ y AR2 en documentación e instrucciones de copilot” que barrió 121 referencias separadas y las puso en línea.

Este es el tipo de cosa que no pasa cuando un solo humano escribe todo el código, porque el humano solo renombra sobre la marcha. Pasa en un flujo de trabajo dirigido por agentes cuando el agente toma un issue anterior a un renombrado y escribe fielmente el nombre viejo. El remedio es mantener la documentación que el agente lee como entrada completamente sincronizada con la realidad actual, y escribir los PRs de renombrado como sus propias piezas de trabajo.

Estoy construyendo un sistema donde la documentación del agente es también la documentación del equipo. Cuando la documentación miente, el agente miente en la misma dirección. Eso es una característica del flujo de trabajo que estoy tratando de hacer bien, no un bug.

La suite de pruebas de Wi-Fi 7, específicamente

Esta es de la que estoy más orgulloso de este fin de semana.

La especificación de AR2 Gen1 asume conectividad Wi-Fi 7 para renderizado descargado y cómputo atado. Wi-Fi 7 en la práctica no es tan estable como Wi-Fi 6E, y los modos de fallo son distintos. La suite de pruebas escrita este fin de semana caracteriza el conjunto de modos de fallo (rendimiento degradado, pérdida intermitente, tormentas de reautenticación) y acota el comportamiento del runtime bajo cada uno. El runtime no puede tolerar todos los fallos. El trabajo de la suite de pruebas es ser específica sobre qué fallos el runtime degrada con gracia y cuáles fallan ruidosamente.

Esto importa porque la experiencia de RA que está teniendo el usuario no puede tartamudear cuando la conexión falla momentáneamente. El runtime tiene que recurrir al renderizado local por un fotograma, o dos, o veinte, dependiendo de la duración del corte, y reconverger cuando la conectividad regrese. Esa lógica existía como intención difusa en la especificación. Después de este fin de semana, existe como casos de prueba.

Lo que quiero que los socios se lleven de esto

Dos cosas.

Si eres un socio de hardware pensando en gafas de RA, el marco de validación con el que se lanza este motor va a ser una de las razones por las que se lanza sobre tu hardware más rápido que sus competidores. El marco es portable. Añadir un nuevo objetivo de dispositivo son unas cuantas centenas de líneas de código más los vectores de prueba específicos del dispositivo. La parte cara ya está pagada.

Si eres un laboratorio de IA pensando en inferencia en el dispositivo sensible a la latencia, el presupuesto de latencia que asume la especificación de AR2 Gen1 está publicado. Las trazas de extremo a extremo desde el sensor hasta el renderizado se están instrumentando ahora, así que cuando tu modelo tenga que caber dentro de ese presupuesto, puedes ver qué presupuesto realmente le queda a la inferencia. Esa es la conversación que quiero estar teniendo contigo en noviembre.

77 commits durante el fin de semana. Terminó en documentación, que es el tipo correcto de fin de semana con el que terminar.