Um Sábado Antes do Primeiro Commit

O motor que for lançado em 2027 vai ser aquele que conhecia seu time, suas demos e sua API antes do commit número um - não a dúzia de motores que começaram em 2025 e improvisaram. A RakuAI passou um trimestre projetando o fluxo de trabalho para que a base de código pudesse refleti-lo por anos.

Este é o último sábado antes de o primeiro commit entrar. No próximo fim de semana o repositório do runtime abre. O repositório do SDK abre. O repositório de documentação abre. Os agentes começam a trabalhar na fila de issues. O código de verdade começa.

Essa frase demorou um ano para chegar. O portfólio de patentes por trás deste produto demorou uma década para chegar. A coisa que quero registrar antes de o trabalho mudar de design para implementação é o que aprendi nos últimos três meses de trabalho pré-construção, porque as lições aqui são as que a base de código vai refletir pelos próximos dois anos.

O que foi feito em três meses sem código

Uma lista, porque escrevê-la força honestidade.

A escalação de agentes está definida. Dez agentes em papéis definidos. Produto, SDK, Studio, Marketing, Operações, Estratégia de IA e Dados, sub-agente de Codex Dev, Relações com Desenvolvedores, Parcerias Estratégicas, Governança de Agentes sobre tudo isso. Cada um tem um system prompt, um conjunto de ferramentas e um conjunto de interações com os outros. A escalação está documentada em um lugar que os agentes vão ler no início de cada sessão.

O conjunto de demos está especificado. Oito demos canônicas. Cada uma tem uma descrição escrita, uma lista de capacidades que precisa demonstrar, uma complexidade estimada, e um lugar na pasta do SDK onde vai viver. Estúdios que perguntarem “para que serve isso” vão receber um exemplo funcional que corresponde ao seu caso de uso.

A estrutura de pastas do SDK está desenhada. Apps. Módulos. Assets. Docs. Config. Cada pasta de nível superior tem um propósito definido. Cada subpasta tem uma convenção clara. O código que chegar ao longo do próximo ano vai cair no lugar certo porque o lugar certo existe.

As superfícies de API dos módulos estão rascunhadas. Renderizador de HUD. Entrada por gesto. Rastreamento de olhar. Sincronização multiplayer. Animador de overlay. Controle por voz. A superfície pública de cada módulo está esboçada em pseudocódigo. Os agentes vão substituir o pseudocódigo por implementações reais sobre um contrato estável.

O alvo de hardware está travado. A especificação dos óculos inteligentes AR1+ está finalizada como o alvo primário do motor. Orçamentos de latência. Envelopes térmicos. Capacidades de sensores. A especificação é uma função forçadora para toda decisão arquitetural rio abaixo.

O portfólio de patentes está documentado e auditado. A propriedade intelectual de uma década sobre o formato de óculos que sustenta este produto foi relida, as continuações foram revisadas com a assessoria jurídica, e o enquadramento público de quais invenções são reivindicadas é consistente. A PI é a fundação. A base de código é o que é construído em cima dela.

O diário público de engenharia está na fila. Este blog vai ao ar no próximo sábado com o primeiro post do ritmo regular. As quatro entradas antes desta são a versão pública do trabalho de design que aconteceu durante o verão. Daqui em diante o ritmo é semanal.

O que aprendi sobre o fluxo de trabalho conduzido por agentes antes de fazer qualquer parte dele

A maior parte do que acho que sei vai acabar se mostrando errada. Essa é a primeira observação honesta. Três meses projetando um fluxo de trabalho no papel não é o mesmo que rodar um fluxo de trabalho em produção. O primeiro mês de código de verdade vai revelar coisas que eu não previ.

Dito isso, alguns palpites que estou disposto a assumir.

Os agentes vão ser melhores nas partes chatas do que nas partes inéditas. Encanamento de telemetria, configuração de build, harnesses de teste, varreduras de documentação. São tarefas nas quais os agentes vão pousar de forma limpa porque os padrões estão bem definidos. Decisões arquiteturais inéditas (uma nova fronteira de subsistema, um novo modelo de threading, uma nova superfície de API) são tarefas com as quais os agentes vão ter dificuldade porque os padrões são menos definidos. A divisão de trabalho certa é manter o trabalho arquitetural comigo e delegar o trabalho de implementação aos agentes.

O trabalho de enquadramento vai ser o trabalho de verdade. Uma issue enquadrada de forma vaga produz um PR que está vagamente correto. Uma issue enquadrada com precisão produz um PR que está precisamente correto. A habilidade que mais vai se acumular ao longo do próximo ano é ser bom em enquadrar as issues que os agentes pegam. A maioria das minhas manhãs de sábado, eu espero, vai para esse enquadramento.

A revisão vai ser o gargalo. Cinco agentes produzindo PRs em paralelo vão saturar qualquer revisor humano único em cerca de um sábado. As defesas são profundidade de fila menor, revisão agente-a-agente para comentários de primeira passada, e uma disciplina de recusar mesclar o que eu não li de fato. Escrevi essa disciplina. Vamos ver como ela sobrevive ao contato com um sábado de cem PRs.

Os agentes vão escrever stubs que passam nos testes. A coisa que mais me preocupa é o modo de falha em que a implementação de um agente retorna um valor de placeholder, o teste por acaso passa contra o placeholder, e a base de código cresce uma mentira sobre o que faz. Escrevi o padrão de auditoria para isso e me comprometi a rodá-lo em um ritmo. Se o ritmo se sustenta contra a tentação de pular auditorias é a questão em aberto.

Por que as patentes importam para o que vem a seguir

Quero registrar algo específico sobre o portfólio de patentes porque essa é a parte deste projeto mais frequentemente mal-entendida.

As patentes não são um fosso defensivo contra um concorrente conhecido. Ainda não há um incumbente na categoria de óculos de RA espacial. As patentes não são uma estratégia de litígio. Não estamos no ramo de processar pessoas.

O que as patentes são é permissão. O trabalho sobre o formato de óculos que eu e meus colaboradores registramos há mais de uma década cobre os padrões arquiteturais que tornam os óculos de RA modernos possíveis. Esses padrões agora são o básico esperado para qualquer um construindo nesta categoria. Ter registrado primeiro significa que temos a liberdade de operar que os retardatários não têm, e a credibilidade com parceiros que retardatários não conseguem fabricar.

A base de código que abre no próximo sábado é construída sobre essa permissão. Toda decisão arquitetural rio abaixo pode assumir que a questão fundamental de PI já está resolvida. Essa é uma vantagem mais silenciosa que um fosso. Também é uma mais durável.

O que estou levando para o próximo sábado

Uma lista curta. O tipo de intenção que você define no dia anterior a algo sério começar.

• Abrir o repositório do runtime com um README limpo e um link de especificação limpo. O primeiro commit deveria ser aquele que eu quero que a futura arqueologia encontre.
• Registrar as primeiras dez issues na fila dos agentes. Cada uma delimitada com precisão. Cada uma etiquetada. Cada uma com um critério de aceitação que o agente consiga autoverificar.
• Iniciar o diário público de engenharia com o tipo de post que sinaliza o ritmo: honesto, específico, sem sentimentalismo.
• Não escrever à mão nenhum código que um agente pudesse escrever. Os agentes são o time. Use-os.
• Não deixar os agentes tocarem em nada arquitetural sem que eu enquadre antes. As decisões arquiteturais são minhas.
• Fechar o laptop em um horário razoável. Isso é uma maratona, não um único sprint.

Uma nota para quem estiver lendo o diário público depois

O blog vai ao ar no próximo fim de semana. As entradas antes desta são a retrospectiva do documento de design. As entradas a partir do próximo fim de semana são o diário de engenharia ao vivo. O ritmo é semanal. A voz é honesta. A disciplina sobre a qual o fluxo de trabalho roda é a disciplina que a base de código vai refletir.

Se você é de um dos labs de IA e está lendo isso no futuro, o motor que você está olhando foi projetado antes de qualquer código ser escrito, por alguém que sabia como queria que o fluxo de trabalho fosse e construiu a base de código para caber no fluxo de trabalho. Essa é a diferença entre este motor e a dúzia de outros motores que começaram em 2025.

Se você é um parceiro de hardware pensando em qual motor seus dispositivos deveriam rodar, a especificação AR1+ que o motor tem como alvo é real, o conjunto de demos que acompanha o motor está especificado, e a proposta para desenvolvedores que o SDK oferece está mapeada. Outros motores têm que adaptar tudo isso depois. Este não.

Se você é um desenvolvedor pensando em construir sobre isso eventualmente, o SDK está sendo projetado pensando em você. Oito demos que correspondem a oito categorias de produto. Uma estrutura de pastas que não vai mudar debaixo de você. Uma superfície de API travada antes de a implementação começar.

Se você é um concorrente lendo isso, a fase de design acabou. A fase de construção começa no próximo fim de semana. Prefiro que você saiba disso a ser pego de surpresa por isso.

Daqui a um sábado, o primeiro commit. Hoje, o último sábado de trabalho de design puro. Na próxima vez que eu escrever neste blog, o código já terá começado.