Validando Hardware Antes de o Silício Aparecer

A resposta tradicional para esperar pelo silício é sentar e esperar. A resposta moderna é construir tudo o que vem rio abaixo do hardware primeiro e ter tudo verde antes de as peças chegarem - para que seu hardware lance na RakuAI mais rápido que seus concorrentes.

Uma decisão que eu vinha mastigando durante a semana de trabalho estava esperando à mesa da cozinha quando o fim de semana começou. Mudar o alvo do produto de AR1+ para AR2 Gen1. Construir tudo o que vem rio abaixo da nova especificação antes de o silício chegar, para que, quando o silício chegar, a validação comece no dia um em vez do dia noventa.

Existe uma fase pela qual todo produto de hardware passa em que a especificação existe, o plano de validação existe, o harness de teste existe, e o silício de verdade não. A resposta tradicional é sentar e esperar. A resposta moderna é construir tudo que vem rio abaixo do hardware primeiro, e ter tudo verde antes de as peças serem lançadas.

Este fim de semana foi isso. A plataforma-alvo mudou oficialmente de AR1+ para AR2 Gen1, e a resposta de engenharia foi construir imediatamente a infraestrutura de validação de que a nova plataforma vai precisar, antes de qualquer um de nós tocar na nova plataforma.

O que entrou

Cinco coisas, todas entraram neste fim de semana:

• A infraestrutura de bring-up de dispositivo e integração de sensores do AR2 Gen1
• Um conjunto de testes de conectividade Wi-Fi 7 e estabilidade de rastreamento
• Um framework de validação térmica e de energia
• Testes de fumaça de CI com análise e relatório de métricas
• A documentação de validação de hardware do AR2 Gen1 e a especificação de padrões de produção

Tudo isso controlado por feature flags para que o caminho de código do AR1+ continue funcionando e nada no runtime existente regrida. Os agentes que entregaram esses PRs fizeram a disciplina chata corretamente: todo arquivo novo está escondido atrás de uma flag de build, toda adição de API não quebra nada, todo teste roda na CI mesmo sem um dispositivo AR2 para rodar contra. Os testes simulam. A simulação é boa o suficiente para pegar desvio de interface, exportações faltando, e fluxos de sensor quebrados.

Foi um fim de semana de 77 commits. A maioria desses commits está a serviço de um dispositivo que não consigo segurar.

Por que isso faz sentido

Algumas razões.

Validação de hardware que é lançada junto com o hardware é validação de hardware que chega seis meses atrasada. O framework térmico e de energia escrito neste fim de semana vai ser usado no dia em que o primeiro kit de desenvolvimento do AR2 chegar à minha mesa, não três meses depois. A primeira regressão térmica da plataforma vai ser pega por um teste existente, não por um humano notando que o dispositivo está quente.

Um harness de teste sem um dispositivo ainda é um harness de teste. Ele roda contra traces de sensor simulados. Esses traces vêm da era AR1+ e da especificação. Não são perfeitos. Eles pegam bugs de interface, bugs de integração, e bugs de coleta de métricas. Não pegam os bugs que só vão aparecer sob silício de verdade. Tudo bem. Os bugs que eles pegam são os bugs com os quais teríamos gastado a primeira semana de tempo com hardware real caçando, e agora não precisamos mais.

O ato de escrever o harness esclarece a especificação. Metade do documento de padrões de produção que entrou até o domingo à noite existia apenas como intenção vaga no início do fim de semana. Escrever os testes de validação forçou a especificação a virar números específicos. Orçamentos de frame. Envelopes térmicos. Limiares de estabilidade de Wi-Fi 7. O harness deixou o documento afiado. Essa é a entrega de verdade.

Como o agente lidou com a mudança

A mudança de AR1+ para AR2 Gen1 não foi tratada de forma limpa da primeira vez. No meio do fim de semana, o agente entregou um PR que referenciava “AR1+” em lugares onde o novo caminho de código deveria dizer “AR2.” Isso entrou porque o enquadramento da issue não sinalizou a renomeação. A correção foi um PR separado intitulado “Fix AR1+ vs AR2 device discrepancy in documentation and copilot instructions” que varreu 121 referências separadas e as colocou em ordem.

Este é o tipo de coisa que não acontece quando um único humano escreve todo o código, porque o único humano simplesmente renomeia conforme vai. Acontece em um fluxo de trabalho conduzido por agentes quando o agente pega uma issue anterior a uma renomeação e escreve fielmente o nome antigo. O remédio é manter os documentos que o agente lê como entrada totalmente sincronizados com a realidade atual, e escrever PRs de renomeação como peças de trabalho próprias.

Estou construindo um sistema onde a documentação do agente também é a documentação do time. Quando a documentação mente, o agente mente na mesma direção. Isso é uma característica do fluxo de trabalho que estou tentando acertar, não um bug.

O conjunto de testes de Wi-Fi 7, especificamente

Este é do qual mais me orgulho neste fim de semana.

A especificação do AR2 Gen1 assume conectividade Wi-Fi 7 para renderização descarregada e computação vinculada (tethered). O Wi-Fi 7 na prática não é tão estável quanto o Wi-Fi 6E, e os modos de falha são diferentes. O conjunto de testes escrito neste fim de semana caracteriza o conjunto de modos de falha (vazão degradada, perda intermitente, tempestades de reautenticação) e delimita o comportamento do runtime sob cada um. O runtime não consegue tolerar toda falha. O trabalho do conjunto de testes é ser específico sobre quais falhas o runtime degrada graciosamente e quais falham de forma ruidosa.

Isso importa porque a experiência de RA que o usuário está tendo não pode engasgar quando a conexão oscila. O runtime tem que recorrer à renderização local por um frame, ou dois, ou vinte, dependendo da duração da oscilação, e reconvergir quando a conectividade voltar. Essa lógica existia como intenção vaga na especificação. Depois deste fim de semana, ela existe como casos de teste.

O que eu quero que os parceiros tirem disso

Duas coisas.

Se você é um parceiro de hardware pensando em óculos de RA, o framework de validação com o qual este motor é lançado vai ser uma das razões pelas quais ele vai ser lançado no seu hardware mais rápido que seus concorrentes. O framework é portável. Adicionar um novo alvo de dispositivo são algumas centenas de linhas de código mais os vetores de teste específicos do dispositivo. A parte cara já está paga.

Se você é um lab de IA pensando em inferência no dispositivo sensível a latência, o orçamento de latência que a especificação do AR2 Gen1 assume está publicado. Os traces ponta a ponta do sensor até a renderização estão sendo instrumentados agora, então, quando seu modelo tiver que caber nesse orçamento, você vai poder ver quanto orçamento sobra de verdade para inferência. É essa a conversa que quero estar tendo com você em novembro.

77 commits ao longo do fim de semana. Terminou em documentação, o que é o tipo certo de fim de semana para terminar.