O Fim de Semana em Que um Agente Autônomo Lançou Dez Subsistemas

Um motor construído POR agentes desde o dia um sai com uma forma diferente de um com IA pendurada em cima. Essa forma é exatamente a que um runtime precisa quando IA é uma primitiva - não uma funcionalidade ao lado dela.

Abri o laptop no sábado de manhã. O repositório do runtime tinha recebido 139 commits durante a noite. A maioria deles entrou por um agente de codificação autônomo que vinha trabalhando contra uma fila de issues que registrei no fim de semana passado. Dez pull requests do tamanho de subsistema, todos prontos para revisão.

Quando as pessoas me perguntam como de fato é construir um runtime 3D com agentes de IA no time, elas geralmente assumem uma de duas coisas. Ou os agentes são autocompletar vestido com um painel de chat, ou são uma funcionalidade que você adiciona depois, assim que o motor “de verdade” tiver sido construído por humanos.

Nenhuma das duas é a versão dentro da qual estou sentado neste fim de semana.

Ao longo de sábado e domingo o repositório do runtime recebeu 139 commits. 110 deles foram escritos por um agente autônomo. 20 foram sob a conta da era fundadora BladeWireless. 10 foram meus. Ao longo desses 139 commits, dez pull requests de subsistema entraram:

• Sistema de animação esquelética
• API de edição de cena em tempo de execução
• Serialização de cena
• Occlusion culling
• Streaming de nível
• Sistema de prefabs
• Sistemas de partículas de GPU
• Renderização avançada
• Sistemas de terreno e ambiente
• Pipeline de pós-processamento

Nenhum desses subsistemas é IA. São as peças chatas e estruturais de que um runtime 3D precisa para ser um runtime 3D. E foram lançados ao longo de um fim de semana, em branches paralelos, principalmente escritos por um agente rodando autonomamente enquanto eu enquadrava, revisava, e mesclava.

Este é o post sobre o que significa a fundação estar sendo construída POR agentes, não construída PARA agentes.

A diferença está em toda decisão arquitetural

Existe uma versão dessa história em que você constrói um motor “normal” do jeito que motores sempre foram construídos, e depois adiciona IA em cima. A IA entra como uma funcionalidade. Ela é pendurada. Vive fora do motor porque o motor não foi projetado para hospedá-la. Esse é o padrão dominante na indústria agora mesmo, e não é um padrão errado. É só o que você obtém quando decide como o motor deveria parecer antes de a IA estar no time de desenvolvimento.

Quando agentes de IA estão no time desde o dia um, a forma do motor sai diferente. Três coisas mudam.

Um. Todo subsistema é lançado através de revisão de código. Porque agentes têm que participar do loop de revisão, o loop tem que aceitar diffs escritos por agentes. Todo PR. Todo diff. Toda mesclagem. Essa disciplina não apenas viabiliza agentes. Ela também acaba sendo exatamente a disciplina que você quer se a IA algum dia for ser uma primitiva de runtime em vez de uma funcionalidade de editor. O mesmo pipeline de revisão que pega o erro de digitação de um agente em um cabeçalho de culling vai pegar o erro de digitação do agente em uma árvore de comportamento. O pipeline não se importa em qual camada da stack ele vive.

Dois. Todo subsistema tem interfaces públicas limpas. Múltiplos agentes trabalhando em múltiplos subsistemas em paralelo produzem conflito impossível de mesclar toda vez que as fronteiras são turvas. O remédio é desenhar as fronteiras de forma rígida antes de qualquer um escrever código. Uma vez que as fronteiras são rígidas, os subsistemas se tornam endereçáveis de qualquer lugar, que é exatamente o que você precisa se quer que o motor hospede comportamentos de IA que consigam chamar o resto do runtime sem acoplamento.

Três. Todo subsistema é testável independentemente. Um sábado de 139 commits não pode ser testado manualmente por QA. Os testes têm que ser lançados junto com o diff ou o diff não entra. É assim que o humano no loop consegue confiar no diff de qualquer jeito. O efeito colateral é uma superfície de teste que te permite trocar implementações sem reescrever chamadores, que é a disciplina de que um motor precisa para sequer evoluir.

Nenhuma dessas coisas é uma funcionalidade de IA. São consequências de processo de desenvolvimento de ter agentes no time. O processo de desenvolvimento molda a arquitetura.

Como o fluxo de trabalho de fato se parece

O padrão que produziu este fim de semana:

• Eu enquadrei quais subsistemas o motor precisava a seguir.
• Um agente autônomo rodou em paralelo através de dez branches, cada um implementando um subsistema.
• Todo branch produziu um PR com implementação, testes, e documentação.
• Eu revisei e mesclei. Onde o agente errou algo, fechei o PR ou pedi mudanças.

O que me impressiona, sentado aqui no fim do fim de semana, é o quanto disso já está funcionando. O loop de desenvolvimento é o loop de desenvolvimento. O agente está fazendo o trabalho para o qual eu teria contratado dez pessoas há cinco anos. Estou fazendo o julgamento arquitetural e as decisões de mesclagem. É um tipo diferente de fim de semana longo dos fins de semana longos que eu costumava ter.

O agente autônomo neste fim de semana em particular não é uma stack multi-fornecedor de quatro assistentes. É um único agente (o agente SWE do Copilot) rodando através de muitas tarefas paralelas. Espero que o padrão multi-assistente venha, e venha rápido. O padrão já está aqui na forma de agente único.

O que é difícil

Honesto sobre isso, porque é genuinamente difícil.

Agentes não são de graça. Um fim de semana de 139 commits tem um custo de revisão de 139 commits. Todo PR precisa de atenção real porque os subsistemas são não familiares e não consigo apenas passar os olhos por eles. Estou cansado. A fadiga é real e vale a pena orçar para ela.

Confiar em um agente autônomo em trabalho inédito é uma habilidade. O agente SWE do Copilot que lançou a maioria dos subsistemas deste fim de semana é bom. Não é infalível. A habilidade é saber quando mesclar rápido, quando desacelerar, e quando descartar um rascunho. Já mesclei coisas que deveria ter refeito. Estou aprendendo pagando o custo.

A arquitetura tem que ser esboçada antes de os agentes rodarem. Dê a um agente o prompt “me construa um renderizador” e você vai receber um renderizador que não se encaixa no resto do seu motor. Dê a ele “implemente um subsistema de occlusion culling que exporte esta API C e se integre com o grafo de cena através destes handles” e você recebe algo que entra de forma limpa. O trabalho de enquadramento é o trabalho. O agente faz a digitação.

Testes não são negociáveis. Quase deixei um dos PRs deste fim de semana entrar com cobertura de teste fraca. Essa é uma regressão futura com a qual estou silenciosamente me comprometendo a lutar. O remédio é tornar o requisito de teste parte do prompt do agente desde a primeira linha.

O que estou levando deste fim de semana

Duas observações.

Os agentes obviamente vão continuar ficando melhores. Mais rápidos, mais precisos, capazes de manter mais do motor em uma única cabeça. Essa é a previsão fácil.

A previsão menos fácil é o que acontece com o papel humano dentro desse fluxo de trabalho. Já não é o papel para o qual treinei como engenheiro sênior. Menos digitação, mais enquadramento. Menos síntese, mais seleção. Menos “eu sou o gargalo nessa linha de código” e mais “eu sou o gargalo na decisão arquitetural que decide se esse branch valeu a pena rodar.”

Esse é um trabalho diferente. Usa músculos diferentes. Acho que os músculos que usa são incomumente fungíveis entre domínios, e acho que as pessoas que os desenvolverem ao longo dos próximos dois anos vão olhar para o resto da indústria do jeito que a indústria atualmente olha para pessoas que ainda constroem sem controle de versão.

Isso já é mais que suficiente reflexão para um fim de semana.

Fechando o laptop no domingo à noite. De volta a isso no próximo sábado.