Fable 5.2 escreveu um path tracer e uma cena de 370 000 polígonos com um único prompt

Normalmente, quando se fala de agentes, pensa-se em um modelo que usa ferramentas prontas: abre o Blender, chama uma API, executa o script de outra pessoa. O experimento descrito pelo canal «Metaversishche» quebra esse esquema. O modelo recebeu uma tarefa, criou as próprias ferramentas e ele mesmo as utilizou.

O que exatamente aconteceu

O prompt era uma única frase em inglês. Em linhas gerais: usando quaisquer técnicas de programação que você conheça, crie uma imagem feita do entrelaçamento de luz e sombra, mostre o jogo tranquilo de luz e sombra em um dia claro, busque a perfeição. Não havia nenhuma palavra sobre renderização, C++ ou 3D. O modelo Fable 5.2 (como o autor do post o chama) decidiu por conta própria que o melhor caminho para essa imagem era escrever um renderizador.

Segundo a descrição, o resultado foi este:

• um path tracer escrito do zero em C++;
• o sol como um disco de verdade, e não como um ponto;
• cerca de 370 000 polígonos totalmente gerados por código: piso de parquê em espinha de peixe, dobras das cortinas, cada folha de bordo do lado de fora da janela;
• materiais procedurais, incluindo uma pequena estampa na parede;
• um script em Python que remove ruído, faz a correção de cor e adiciona grão.

O que significa «sol como disco» é mais fácil de entender com um exemplo. Em renderizadores simplificados, a fonte de luz é um ponto, e a sombra que ela projeta fica nítida. Para parecer suave, costuma-se desfocá-la com um filtro. Já se a fonte tem área, como o sol de verdade, a borda da sombra se esmaece sozinha: na base do objeto ela é nítida e, quanto mais longe, mais suave. Isso se chama penumbra. O modelo escolheu o caminho fisicamente fiel, embora o prompt não pedisse isso.

Por que isso importa para desenvolvedores e product managers

Primeiro: a mudança de tool use para tool making. O agente convencional escolhe de um conjunto de funções prontas. Aqui, o modelo escreveu ferramentas para uma única tarefa, elas funcionaram uma vez, e só. Para o desenvolvedor, isso muda a pergunta. Antes era preciso decidir como integrar uma dezena de SDKs. Agora, às vezes basta dar ao modelo um sandbox com compilador e descrever o resultado desejado.

Segundo: isso não é uma imagem de difusão, e sim um programa que a calcula. Daí uma vantagem lógica, embora o post não a tenha verificado: o resultado pode ser reproduzido e editado. Quer outro ângulo do sol ou outro bordo? Muda-se um parâmetro e renderiza-se de novo. Um gerador de imagens normalmente não oferece esse controle. Para produtos ligados a 3D e visualização, é um sinal: a fronteira entre «gerador» e «código» começa a se apagar.

Terceiro: um efeito colateral na infraestrutura. O autor brinca que, se todas as ferramentas descartáveis fossem salvas no GitHub, a plataforma estouraria, e afirma que o armazenamento lá cresceu 20 vezes em um ano. O número é do post, não o verificamos. Mas a ideia em si é honesta: quando o código se torna material de consumo, a pergunta «o que disso vale a pena guardar» passa a ser real.

Limitações

• É um único post e um único exemplo. Não se sabe quantas iterações internas o modelo fez, quantos tokens e quanto dinheiro foram gastos e quanto tempo o trabalho levou. As palavras «apenas um prompt» não respondem a essas perguntas.
• O path tracer é um clássico da computação gráfica, sobre o qual existe muito material. Em tarefas de nicho, com menos exemplos, esse truque pode não funcionar.
• O critério de «perfeição» é subjetivo. Uma cena bonita não prova que a física foi calculada corretamente em todos os pontos.
• Um modelo que escreve e executa código exige isolamento: sandbox, limites de tempo e de memória, proibição de acesso desnecessário à rede.

O que fazer com isso

Experimente em uma tarefa sua. Dê ao modelo um ambiente com compilador ou interpretador e formule o objetivo, não a receita. Veja se ele se propõe a escrever ferramentas em vez de escolher as prontas. Defina isolamento e limites com antecedência. E abra o repositório afternoon-light: ele mostra como é o código que o modelo escreveu para uma única imagem.