Dois Meses Público, Anos Debaixo do Capô

A maioria dos motores "nativos de IA" pendura um painel de chat num editor. A RakuAI trata o modelo como uma entrada de controle a cada frame — e dois meses depois, essa tese está lançando código, não slides.

O plano para este sábado era desacelerar e pensar. Três commits no fim de semana inteiro, a menor contagem desde que comecei o diário público. Os agentes estão rodando mais frios de propósito; minha atenção está na arquitetura em vez de lançar código novo. A base de código termina o fim de semana mais ou menos onde o começou, que é o estado certo para o tipo de trabalho que eu estava fazendo.

Dois meses atrás, hoje, o repositório público do runtime era um README vazio. O motor e o portfólio de patentes por trás dele vêm de mais longe que isso. O tipo de fim de semana que vale a pena escrever a respeito é aquele em que o escritor faz um balanço. Então é isso que é isto.

O que o motor de fato é, hoje

Se eu tivesse que descrever a Raku em um parágrafo para alguém que não vem acompanhando, a descrição seria:

Um runtime de RA multiplataforma, escrito em C++ e exposto através de uma API C estável, com bindings de SDK para Unity e Unreal. Tem como alvo principal óculos de RA e roda em qualquer hardware disponível hoje (atualmente entrando em operação para passthrough do Meta Quest, com builds de preview para desktop e mobile). É projetado desde a fundação em torno da premissa de que IA é uma preocupação de runtime, não uma funcionalidade de editor. Ancoragem sub-milimétrica é suportada. OpenXR é o alvo de conformidade onde padrões existem. A base de código é construída com agentes de codificação autônomos no time de desenvolvimento, trabalhando através de uma fila pública de issues.

Esse parágrafo teria sido uma declaração de missão aspiracional no dia um. Agora é uma descrição do que está no repositório.

O que me surpreendeu nos últimos dois meses

Três coisas.

O fluxo de trabalho conduzido por agentes escalou além de onde eu esperava. Eu tinha uma preocupação ao entrar de que os agentes autônomos produziriam uma base de código que funcionava em PRs isolados e virava papa através de muitas mesclagens. A papa não aconteceu. A base de código está mais coerente aos dois meses do que bases de código que herdei de times humanos aos dois anos. A razão é a disciplina sobre a qual venho escrevendo todo fim de semana (fila menor, revisão mais cedo, pareamento multi-fornecedor para independência de revisão, documentação como entrada). Essas disciplinas funcionam.

A mudança de hardware foi menos custosa do que eu temia. Mudar do AR1+ como alvo do produto para o AR2 Gen1 no início de outubro foi uma decisão com a qual fiquei alguns dias porque o custo parecia grande. O custo real foi um par de PRs (uma varredura completa de renomeação, uma passada de documentação). A razão de o custo ter sido pequeno é a arquitetura modular estabelecida cedo. Subsistemas que não precisavam conhecer a fronteira de classe de dispositivo não precisaram mudar. Os que precisaram, mudaram de forma limpa através de suas superfícies bem definidas. Esse é o dividendo de desenhar a arquitetura cedo.

As conversas de parceria estão acontecendo mais cedo do que eu planejei. Eu esperava estar no modo “construir o motor, lançar uma demo, depois ter conversas de parceria” até o fim do ano. A sequência real tem sido “construir o motor, ter conversas de parceria ao longo do caminho que informam o que construir a seguir, depois lançar demos que correspondam ao que essas conversas precisam.” NTT QONOQ. Meta. As próximas eu ainda não vou nomear. As conversas estão mais afiadas que as demos agora mesmo, o que é um bom lugar para se estar.

Onde a arquitetura se assentou

Uma lista curta das decisões arquiteturais que não espero mais revisitar:

• O runtime é C++ exposto através de uma API C estável. Outros bindings de linguagem ficam em cima da API C, não em cima do C++ diretamente.
• O SDK é multi-binding desde o dia um. Unity e Unreal são de primeira classe. Godot está no roadmap. Web-nativo está no roadmap. A API C é o gargalo. Os bindings não são.
• Subsistemas são DLLs. Cada um tem uma superfície pública; nada dentro de um subsistema alcança os internos de outro subsistema. As superfícies são PRs revisados.
• IA é uma preocupação de runtime, não uma funcionalidade de editor. O trabalho de IA que vive no motor roda na etapa de simulação a cada frame. O trabalho de LLM em nuvem que vive no motor se integra ao pipeline de voz em tempo de execução. Nenhum dos dois é um painel em uma ferramenta de autoria.
• OpenXR é o padrão onde o padrão se encaixa. Código específico de fornecedor fica atrás de feature flags e padrões de provedor. Adotar um novo alvo de dispositivo conformante com OpenXR é uma camada de cola específica de fornecedor, não uma reescrita de runtime.
• O processo de desenvolvimento é multi-fornecedor por design. O modelo que escreve um pedaço de código não pode ser o modelo que o revisa. O lab cujo modelo é atualmente o melhor em um determinado papel ganha esse papel até outro lab ser melhor.

O que eu ainda espero revisitar:

• A divisão exata de trabalho entre inferência no dispositivo e intenção de LLM em nuvem. Isso vai ficar mais afiado conforme o trabalho de TFLite amadurece e conforme a interface de LLM em nuvem é exercitada por parceiros de verdade. A linha atual é provisória.
• O formato do arquivo de definição de experiência. Os ossos estão lá. O esquema vai evoluir. Espero pelo menos um salto de versão maior antes de o formato estabilizar.
• O posicionamento da sincronização de estado para RA multiplayer. Temos um canal de delta de baixa latência hoje. Se a resposta certa de longo prazo é uma malha peer-to-peer, um servidor autoritativo hospedado, ou algum híbrido ainda não está resolvido. As demos de dois jogadores que serão lançadas em dezembro vão informar essa decisão.

O caminho para a prontidão de produção em dezembro

Venho mirando silenciosamente em um marco de dezembro em que o motor esteja “pronto para produção para parceiros construírem demos sérias em cima.” Isso não é um lançamento público. É a régua interna na qual estou disposto a convidar um time parceiro a começar a construir contra o runtime sem avisá-los sobre meia dúzia de arestas ásperas.

O que ainda precisa acontecer para superar essa régua:

• Os subsistemas de IA para o runtime (árvores de comportamento, malha de navegação, simulação de multidão, sistemas sensoriais, árvores de decisão). Atualmente esboçados em documentos de design; a implementação entra em dezembro e no primeiro fim de semana de janeiro.
• Limpeza do build no Windows MSVC. Eu não construí de fato o runtime no Visual Studio 2026 desde outubro. Tenho quase certeza de que isso vai ser uma briga. Vou escrever sobre isso quando eu fizer.
• Um pacote canônico de exemplos que demonstra uma experiência de RA não trivial de ponta a ponta através dos bindings de Unity e Unreal, com o pipeline de voz e o LLM em nuvem conectados.
• Um caminho de sincronização federada para distribuir atualizações de modelo para dispositivos em campo. A peça de criptografia precisa ser de nível de produção, não de nível de stub.
• O atualizador de runtime. Precisamos ser capazes de lançar um novo build para o kit de desenvolvimento de um parceiro e ele se instalar de forma limpa.

Essa é a lista. Seis semanas para superá-la. O volume de commits de dezembro vai ser alto.

O que eu quero que construtores e parceiros tirem disso

Se você vem lendo o diário público há dois meses, você viu o motor se juntar em tempo real. O ritmo é alto; a disciplina é real; as decisões arquiteturais estão documentadas. Essa é a cultura de engenharia com a qual este motor é construído. É a cultura de engenharia com a qual você vai estar trabalhando se construir em cima dele.

Se você é um parceiro pensando se deve começar uma conversa séria: a conversa está mais afiada que as demos agora mesmo, e isso é de propósito. Prefiro ouvir o que o seu produto de fato precisa e deixar isso moldar o que vai ser construído do que construir uma demo e depois tentar encaixá-la nas suas necessidades depois do fato. A janela para moldar o que dezembro entrega está aberta até o fim de novembro.

Se você é um desenvolvedor esperando por estabilidade: estabilidade é a entrega de dezembro. O motor está em evolução ativa o suficiente hoje que eu não recomendaria construir código dependente sério sobre ele ainda. Daqui a dois meses a recomendação vai ser diferente.

Sábado tranquilo. Dois meses. De volta a construir no próximo fim de semana.