Começando o Ritmo Semanal

Conteúdo generativo em um navegador é legal. Conteúdo generativo ancorado na parede da sua cozinha de verdade é o produto. Este é o motor sendo construído para receber direção do seu modelo em cada etapa de simulação - dia zero, em público.

Este sábado começa o ritmo semanal regular deste blog. As quatro entradas abaixo desta foram os sábados de documento de design do início do verão: escalação de agentes, conjunto de demos, estrutura de pastas, a última reflexão antes de o código começar. O ritmo daqui em diante é semanal. A coisa sobre a qual o blog fala não é nova.

Venho pensando em óculos de RA, experiências espaciais ancoradas no mundo real, e o formato certo para o runtime que as conduz há mais de uma década. Parte desse pensamento virou patentes no início dos anos 2010, o portfólio sobre o formato de óculos que ainda sustenta a PI por trás do que estamos construindo agora. Parte virou protótipos que nunca viram a luz do dia. A maior parte rodou em segundo plano enquanto eu fazia outro trabalho.

O que mudou neste último ano é que o resto do mundo finalmente alcançou. O poder de computação é pequeno o suficiente. A óptica é boa o suficiente. Os LLMs em nuvem são reais o suficiente. A inferência no dispositivo é rápida o suficiente. O produto que era uma ideia adiantada em uma década é, finalmente, um produto que dá para lançar.

Então comecei a lançar. A leva atual de código já tem vários meses. Os commits vivem em repositórios privados que agora estou trazendo a público conforme limpo e consolido a base de código. Este blog é o registro público daqui em diante.

Como vão ser os próximos meses

O formato do plano deste sábado, como um gostinho do que vem por aí:

• O runtime: um rascunho da especificação de óculos inteligentes AR1+ está na mesa nesta manhã. Versões em PDF, PowerPoint e Markdown para que um LLM consiga raciocinar sobre ela, um parceiro consiga lê-la, e um designer consiga revisá-la. O ponto é a especificação, não o formato. O formato é para os leitores.
• Um main.cpp e um esqueleto de loop principal do runtime, recém-registrados.
• Um cabeçalho de rastreador de latência e um stub de implementação. Latência vai ser a métrica que define este motor.
• Um workflow de build com CMake na CI para que cada push receba um build limpo a partir de uma máquina limpa.
• Um guia de onboarding do Copilot para que os agentes do time saibam como o time funciona.

O repositório do SDK também ganhou seu próprio andaime neste sábado. Um exemplo inicial de HelloAR em Unity. Um exemplo inicial de HelloAR em Unreal. Esqueletos de cabeçalho para os dois bindings. Um workflow de publicação de pacotes.

Nada disso é pronto para lançar. Tudo isso é o que você precisa antes de qualquer coisa lançável ser possível. O padrão de colocar os dois repositórios em movimento ao mesmo tempo, com acoplamento deliberado nas costuras, vai ser um tema recorrente.

Por que uma especificação de óculos inteligentes no dia um de ir a público

A especificação é uma coisa deliberada. A maioria dos motores escolhe uma arquitetura de runtime e depois sai à caça de produtos que poderiam plausivelmente ser lançados sobre ela. Estou fazendo isso na ordem inversa. O produto são óculos de RA que as pessoas usam no mundo, e o motor precisa ter o formato certo para esse produto. Então a especificação é escrita primeiro, mesmo quando está rústica.

Não é um documento de marketing. É uma função forçadora. Ela diz em que tipo de hardware o motor precisa rodar, qual é o orçamento de latência, como a superfície de IA precisa se parecer na prática. Toda decisão arquitetural rio abaixo pode apontar para essa especificação e perguntar “essa decisão serve à especificação, ou serve a algum outro motor que eu gostaria de construir em vez disso.” Essa segunda categoria é onde projetos de motor vão morrer, e já fiquei fora dela antes e pretendo ficar fora dela agora.

Por que um Guia do Copilot no dia um

A outra coisa deliberada deste fim de semana é o guia de onboarding do Copilot. A primeira versão é rústica. Vai ser reescrita dez vezes. Mas o guia existe porque os agentes fazem parte do time, e o time precisa saber como o time funciona.

O guia diz:

• Qual é a estratégia e qual motor não estamos construindo
• Onde vive o roadmap
• Como issues são registradas, pegas e fechadas
• Como é um bom PR
• O que um revisor deve fazer (onde o revisor às vezes sou eu e às vezes é outro agente)

O enquadramento “agentes leem documentação” não é uma jogada de marketing. É a realidade prática de rodar um fluxo de trabalho em que o time é um humano nos fins de semana e vários assistentes de codificação autônomos em serviço contínuo. Se o guia é ruim, o trabalho é ruim. Se o guia é bom, o trabalho sai correto e o custo de revisão cai.

Por que o diário público agora

Algumas razões.

As patentes são precedentes de uma década que ninguém comenta porque não comentamos sobre elas. O trabalho sobre o formato de óculos ao qual o motor remonta foi concedido e continuado discretamente por anos. Quero que o registro público de engenharia aponte para a linhagem real. RA espacial não é uma coisa nova que alguém pegou no verão passado. O trabalho vem de trás.

Conversas de parceria estão começando. Parceiros de hardware, labs de IA, estúdios. Essas conversas ficam mais afiadas quando existe um registro público de engenharia que eles podem ler em vez de um deck. O deck é a versão arrumada. O blog é a versão real.

O fluxo de desenvolvimento é genuinamente novo e vale a pena mostrar. Agentes de IA no time desde o dia um da fase pública. Múltiplos fornecedores. Branches paralelos. Fila pública de issues. Nada disso é inventado para este projeto; o incomum é fazer tudo isso ao mesmo tempo em algo tão sério. Quero registrar enquanto acontece, enquanto as lições ainda estão frescas o suficiente para serem honestas.

O que eu quero que parceiros e construtores tirem disso

Se você é de um dos grandes labs de IA e está lendo isso, aqui vai o discurso. O motor está sendo construído explicitamente para receber direção do seu modelo. Não pendurado. Não num painel de editor. No runtime, na etapa de simulação, a cada frame. As decisões arquiteturais estão acontecendo agora mesmo, em público, com um rastro de documentação explícito. Se o seu modelo fica melhor em entender um espaço físico real em que o usuário está, este motor é onde ele consegue fazer algo com esse entendimento.

Se você é um desenvolvedor pensando em construir sobre isso eventualmente, o SDK está se movendo em lockstep com o runtime. Exemplos de Unity e Unreal foram semeados no repositório do SDK neste fim de semana. Ainda não funcionam. Vão funcionar. A razão de os dois bindings existirem nesta fase é para que eu nunca chegue a um momento daqui a seis meses em que a arquitetura do runtime esteja travada e o SDK tenha que se deformar para caber nela.

Se você está de olho no sinal antecipado como consumidor, o sinal é este: o motor está sendo construído em torno da premissa de que as experiências mais interessantes são experiências de RA em lugares reais, e a IA é o que faz essas experiências reagirem. Conteúdo generativo em um navegador é legal. Conteúdo generativo grudado numa parede da sua cozinha é o produto de verdade.

Hoje é sábado. O blog está no ar. De volta a construir amanhã.