Replicando o Fable com o Opus: Como um Prompt de Uma Linha Construiu um Jogo 3D (e o que Isso Nos Ensinou Sobre Prompting)

O prompt de uma linha que construiu um jogo

Começou como um experimento, não como um projeto. Em uma conta pessoal do Claude, com o esforço máximo de raciocínio ativado, eu digitei uma única frase:

"Crie um jogo de sobrevivência medieval, formato RTS, muitos recursos, fazendas, comidas, tudo muito detalhado, 3D."

Esse foi o briefing inteiro. Sem documento de design, sem lista de arquivos, sem arquitetura. Eu saí de perto.

Noventa minutos depois eu voltei e encontrei um RTS de sobrevivência medieval 3D completo, jogável, rodando no navegador. Não uma demo. Não uma caixa cinza num plano vazio. Um jogo com terreno ondulado, ciclo de dia e noite com estrelas visíveis, florestas em aglomerados, uma economia funcional — colher madeira e pedra, transformar trigo em farinha e em pão, caçar veados, formar um exército — e dez invasões noturnas cada vez mais difíceis que você precisa sobreviver, sob pena de perder sua prefeitura.

O resultado final: 38 arquivos TypeScript, 11.826 linhas de código (10.591 TS, 1.085 CSS, 150 HTML). Uma única tentativa. Nenhuma lógica de jogo escrita por humanos.

Não é apenas um vídeo — o build original é jogável aqui mesmo no seu navegador:

Minha primeira reação foi a óbvia: "O Fable 5 é incrível." Mas então fiz algo que mudou toda a conclusão. Abri o repositório e li como ele havia sido construído.

A surpresa: 94% disso foi o Sonnet, não o Fable

Quando você vê um agente autônomo produzir um jogo em 90 minutos, a suposição natural é que o modelo principal fez todo o trabalho pesado. Não fez.

Lendo o histórico do git e os artefatos de orquestração, eis o que o Fable 5 de fato escreveu com seus próprios tokens:

• Três arquivos-fonte — um contrato de tipos congelado, um arquivo de dados de balanceamento e uma biblioteca de primitivas de mesh.
• Um script de workflow — a orquestração que constrói todo o resto.
• Alguns documentos de planejamento.

Isso dá aproximadamente 754 linhas de código nos três arquivos de contrato — cerca de 6% da base de código final. Os 94% restantes — cada entidade, cada sistema, cada mesh de construção, a UI, o loop do jogo — foram escritos por subagentes Sonnet 4.6 que o Fable iniciou e coordenou.

Ele não usou git worktrees. Todo o build concorrente rodou sobre uma única árvore compartilhada, mantida segura não por isolamento, mas por contrato. E a fase de implementação foi mais de 90% movida pelo Sonnet.

Isso reformula completamente a conquista. A pergunta deixa de ser "quão bom o Fable é em escrever jogos?" e passa a ser a muito mais útil: "quão bom o Fable é em fazer prompting do Sonnet para escrever jogos?" Porque essa habilidade é transferível. Você pode copiar um prompt. Você não pode copiar os pesos de um modelo.

Planeje escrevendo o contrato, não um documento

A decisão de design mais importante que o Fable tomou é uma que a maioria dos times erra. Ele não produziu um plano escrito, um artefato /plan ou um documento de design para aprovação. O "plano" era código — três arquivos decisivos, commitados antes de qualquer agente de build rodar, e então declarados imutáveis.

Essas 754 linhas governaram todas as 11.826. A genialidade está no que elas removem: a autoridade de design dos implementadores. Oito agentes escrevendo código às cegas e em paralelo só podiam se encontrar em um único lugar — um contrato que estavam proibidos de mudar. A deriva de interface (interface drift), o modo de falha clássico do trabalho paralelo em que oito trabalhadores inventam oito versões incompatíveis da mesma fronteira, tornou-se estruturalmente impossível.

Oito módulos sem sobreposição

A base de código foi cortada em oito grupos de arquivos, desenhados de modo que dois agentes jamais tocassem no mesmo arquivo. Toda referência entre módulos era resolvida via types.ts; importações de classes concretas só eram permitidas onde o contrato as nomeava explicitamente.

• core — eventBus, input, cameraController, sound
• world — noise, terrain, water, grid, dayNight, worldGen
• meshes-buildings — props, buildings
• meshes-units — units, fx
• entities — entity, resourceNode, building, unit, enemy, animal
• systems — pathfinding, combat, waves, production
• ui — index.html, styles, hud, buildMenu, selectionPanel, minimap, messages, overlays
• game — o integrador: game, selection, commands, placement, main

Cada grupo foi para um agente implementador. Todo agente recebeu os mesmos dois preâmbulos — um bloco de RULES (regras) e uma especificação CONTRACT completa — e depois seu próprio briefing de módulo. Eis o bloco de RULES, na íntegra:

# Project rules (apply to every file you write)
- Repo root: /Users/fkesheh/medieval. All paths below are relative to it.
- TypeScript STRICT mode. Never use "any" (use precise types or "unknown" +
  narrowing). Named exports only. No default exports.
- Import three as: import * as THREE from 'three'. Relative imports between
  src files (e.g. import type { IGameCtx } from '../types').
- FIRST read these three contract files. They are FINAL — never modify them:
  src/types.ts, src/config/gameData.ts, src/meshes/common.ts.
- Implement interfaces from src/types.ts EXACTLY (names, signatures, semantics).
- Create ONLY your assigned files. Other modules are being written in parallel
  by other agents against the same contract — import from their documented
  paths and trust the documented exports.
- Do NOT run npm, tsc, vite or any dev server (node_modules may be mid-install;
  a later phase compiles). Write careful, complete, production-quality code with
  zero TODOs and zero placeholder stubs.
- Code comments: only where a constraint is non-obvious. No narration comments.
- This is a real, finished game, not a demo: handle edge cases (empty selection,
  depleted nodes, dead targets, no path found, unaffordable costs).

Repare no que isso faz. Cada agente confia em exports documentados que ainda não consegue ver, porque o contrato garante que eles existem. A cada agente é dito que ele está construindo um produto finalizado, não um protótipo — e é por isso que você obtém tratamento de casos extremos em vez de stubs.

O workflow de build: seis fases, um script

O plano não parou em "escreva o código". Um único script de orquestração codificou seis fases — um fan-out para construir, seguido por um teste adversarial para endurecer:

1. Implementar — oito agentes de módulo (Sonnet) constroem simultaneamente contra o contrato congelado. Zero arquivos compartilhados.
2. Compilar — rodar tsc --noEmit; um relator Haiku barato agrupa os erros por arquivo; até oito corretores Sonnet os reparam em paralelo. Loop de ≤ 6 rodadas até o verificador de tipos ficar em silêncio.
3. Revisar — cinco revisores (Sonnet), cada um com uma lente distinta, caçam bugs de integração e de runtime.
4. Verificar — cada achado sério vai para um cético independente cujo veredito padrão é "não é um bug real". O ônus da prova recai sobre o achado; o verificador precisa citar o caminho exato de código que se comporta mal para afirmar que ele é real. Isso elimina falsos positivos.
5. Corrigir — bugs confirmados agrupados por arquivo, um corretor por arquivo para que as edições nunca colidam. 15 bugs reais reparados.
6. Portão (Gate) — tsc --noEmit && vite build precisam passar os dois. Passou na primeira tentativa (~647 kB JS, ~168 kB gzip).

As cinco lentes de revisão foram deliberadamente diversas — lifecycle (loop do jogo e ciclo de vida das entidades), economy (colher → construir → cultivar → comida), combat (dano, torres, timing das ondas), ui-wiring (ids do DOM e argumentos de construtor) e visual (meshes, sombras, alocações em caminhos quentes). Revisar e Verificar foram pipelinados, não sequenciais: os achados de cada lente eram verificados no momento em que aquela lente terminava, então o revisor mais lento nunca travava a verificação do mais rápido.

Um detalhe sutil mas importante: todo o pipeline rodou em Sonnet, com um único relator Haiku — seis papéis Sonnet mais um passo Haiku barato. O custo foi escalonado conforme a dificuldade da tarefa, não nivelado pelo modelo mais caro.

Onde a mágica realmente vive: no prompt, não no modelo

Eis o achado que mais importa, e ele só surgiu quando refiz o experimento com seeds diferentes para comparar.

Construí mais duas versões da mesma ideia com a mesma abordagem de orquestração, mas com contratos diferentes, e as comparei com a original. As três foram implementadas por agentes Sonnet — nenhum humano escreveu uma linha de qualquer uma delas; o único código que o próprio Fable escreveu em cada caso foi o pequeno scaffold. Logo, qualquer diferença na qualidade visual não é uma diferença de capacidade do modelo. Ela vem inteiramente de onde a direção de arte foi escrita.

O seed da original deu ao Sonnet um vocabulário — uma paleta, primitivas, um bakeGroup(). Mas o seed não continha nenhuma das ~3.900 linhas de código visual. O Sonnet escreveu todas elas, guiado pelo prompt do CONTRACT, que especificava à mão a aparência de quase todos os arquivos. Leia esses trechos na íntegra e você verá a diferença:

"DETAILED and distinctive, 15-40 primitives each… townhall = grand two-story timber-framed hall, stone base, banners, torch posts; house = cottage w/ thatched roof + chimney…"

"warm dawn, golden dusk, deep blue night with visible stars… a Points starfield only visible at night… small glowing sun & moon sphere meshes orbiting the sky."

"VERTEX COLORS: sandy near water level, grass greens with noise-driven dirt patches, gray rock on steep slopes…"

E o briefing de módulo do agente de mesh das construções literalmente enquadrou o trabalho como um ofício:

"Focus: this is the art department. Every building must be instantly recognizable at RTS camera distance and charming up close — generous primitive counts, color variation via PALETTE, small storytelling details (barrels, sacks, fences, banners)."

Agora contraste isso com um dos meus seeds refeitos, cuja inteira direção de arte do renderizador era uma única frase: "Implement the Three.js renderer… It must be visually nonblank and detailed without external binary assets." Sem paleta, sem "260 árvores em aglomerados", sem clima de iluminação, sem silhuetas por construção, sem "departamento de arte". O resultado? Um renderizador competente, genérico, em arquivo único, com cores improvisadas sobre um plano quase vazio. O mesmo padrão se manteve quando tentei replicar o jogo com o Opus e com o GPT-5.5 como arquiteto: deixados para escrever seus próprios contratos, ambos produziram apenas uma direção de arte rasa — estruturalmente sólida, mas nada parecida com a prosa do Fable, por construção e por clima. Os jogos saíram corretos e sem graça.

Mesmo modelo. Mesma competência. Resultados radicalmente diferentes. A aparência foi antecipada para dentro dos prompts de implementação — e o loop de revisão não a adicionou depois (a lente "visual" checa correção, não estética). Dê ao Sonnet uma prosa com direção de arte e ele produz visuais ricos; dê a ele "renderize, deixe detalhado" e ele produz visuais corretos-mas-sem-graça.

Replicando por conta própria, com o Sonnet

Se a mágica está no prompt, então o prompt deveria ser reproduzível. Então preservamos o script de orquestração exato — cada prompt de subagente na íntegra e o tier de modelo fixado para cada papel — como um workflow reexecutável, e refizemos o build a partir do scaffold congelado de 3 arquivos.

Funcionou. O mesmo seed contract-first, conduzido pelo mesmo workflow Sonnet de seis fases, produziu a mesma classe de resultado: um RTS 3D detalhado e jogável, construído quase inteiramente por agentes Sonnet.

Esta é a parte que deveria mudar como você trabalha: o artefato mais valioso de um build agêntico bem-sucedido não é o código. É o workflow e o contrato que o produziram. Salve esses, e você poderá reproduzir o resultado sob demanda.

Opus vs. Opus: mais modelo não é mais jogo

A pergunta óbvia seguinte: se o Sonnet fez isso tão bem, o que acontece se jogarmos o modelo mais capaz na coisa inteira?

Rodei a mesma ideia com Opus 4.8 no esforço máximo, usando o Opus também para o trabalho de implementação. O build levou 2 horas e 52 minutos e produziu ~12.500 linhas de código — um pouco mais de código, muito mais computação, muito mais tempo de relógio.

Foi pior como jogo. Sem animações. Jogabilidade inferior — por exemplo, escolher a função de um camponês exigia selecionar uma opção em uma combo box em vez do fluido clicar-com-o-botão-direito-para-atribuir do build Sonnet. A capacidade extra do modelo não se traduziu em um jogo melhor de se jogar nem melhor de se ver.

Isso soa contraintuitivo até você lembrar da seção anterior. O que tornou a original bonita e divertida foi a direção de arte e o design de interação codificados no prompt — não a capacidade bruta do modelo que a executou. Apontar um modelo mais caro para um prompt mais fraco compra muito pouco. A alavanca é o briefing, não a força bruta.

Replicando o Fable com o Opus, do jeito certo

Então eis a síntese — e o real sentido do título. A maneira de "replicar o Fable com o Opus" não é fazer o Opus fazer tudo. É colocar cada modelo onde ele é mais forte:

• Opus como o arquiteto. Use o modelo mais capaz para fazer o que o Fable fez com seus 6% — escrever o contrato congelado, decompor o sistema em módulos disjuntos e dirigir a arte do workflow em prosa. Este é o trabalho de alta alavancagem e baixo volume, onde a capacidade rende mais.
• Sonnet como o implementador. Distribua o grosso do código entre agentes Sonnet paralelos amarrados pelo contrato. Este é o trabalho de alto volume, onde um Sonnet bem instruído iguala ou supera o Opus por dólar e por minuto.

Para testar, peguei os achados acima e construí um workflow deliberadamente com direção de arte no estilo Opus-planeja / Sonnet-constrói — o "prompt especial" — antecipando silhuetas por construção, um clima de iluminação, densidade de mundo, ganchos de animação e uma linha de trabalho dedicada de departamento de arte, exatamente como o CONTRACT original fazia. A qualidade visual e de jogabilidade subiu na mesma proporção. O prompt exato que conduziu essa regeneração está em código aberto aqui: contract-first-game-build.md.

Quer ver como um desses builds realmente joga? Aqui está um jogo ao vivo, no navegador — Hearthwatch — gerado de ponta a ponta exatamente por este workflow contract-first com direção de arte. Sem instalação, sem assets para baixar; roda inteiramente no seu navegador:

A conclusão que um colega tirou quando compartilhei isso internamente foi o resumo mais limpo que já ouvi: "Então o Sonnet em si é bom — a gente só não sabia como usá-lo?" Sim. É exatamente isso.

O mesmo prompt, modelos diferentes — jogue todos

Aqui está a evidência mais forte de que a alavanca é o prompt, não o modelo: o contrato com direção de arte é apenas texto puro, então você pode entregar o build inteiro — arquitetura e implementação — a praticamente qualquer modelo capaz e ainda obter um jogo completo, animado e genuinamente dirigido em arte. Rodei o mesmo prompt em código aberto de ponta a ponta com vários modelos diferentes, cada um atuando como seu próprio arquiteto e executor. Cada um produziu seu próprio estilo de arte — mas nunca a saída rasa, sem graça e sem animação que um briefing de uma linha gera. Jogue e julgue você mesmo.

Opus → Opus, com o prompt dirigido em arte — Hearthhold

Lembra da rodada anterior, toda em Opus, que saiu sem graça e sem animações? Aquilo era o Opus apontado para um briefing raso. Dê a essa mesma dupla Opus-constrói-tudo o contrato com direção de arte, e ela entrega isto:

GLM-5.2 como arquiteto e executor — Hamlet

GPT-5.5 como arquiteto e executor

Quatro modelos, um prompt, quatro jogos completos (cinco, contando o Hearthwatch Opus → Sonnet acima). Essa é a tese inteira em uma única fileira jogável: escreva bem o contrato e a direção de arte, e a escolha do modelo vira questão de gosto e orçamento — não a diferença entre um jogo de verdade e uma demo sem graça.

O que isso significa para construir software de verdade com IA

Tire o tema medieval e estes são princípios gerais e duradouros para qualquer build agêntico não trivial:

1. Planeje escrevendo o contrato, não um documento. Congele suas interfaces, seus formatos de dados e seu vocabulário compartilhado em código antes de qualquer implementação começar. Um tipo que não compila quando violado vale mais que mil palavras de especificação.
2. Decomponha em módulos disjuntos e faça fan-out. Agentes paralelos são seguros quando — e somente quando — não podem colidir. Desenhe as fronteiras de modo que dois agentes nunca editem o mesmo arquivo, e roteie toda referência entre módulos pelo contrato congelado. Você talvez nem precise de worktrees.
3. Dirija a arte no prompt. Seja lá o que "qualidade" signifique no seu domínio — riqueza visual, polimento de UX, rigor no tratamento de erros, acessibilidade — isso precisa estar escrito nos prompts de implementação. Os modelos executam fielmente a direção que recebem e raramente a superam. Uma passada de revisão checa correção; ela não fornece bom gosto.
4. Verifique de forma adversarial e, depois, rode de verdade. Céticos independentes com um padrão de "culpado até que se prove o contrário" eliminam falsos positivos. Mas a revisão estática não enxerga comportamento em tempo de execução — reserve orçamento para um playtest real ou uma execução de ponta a ponta.
5. Escalone seus modelos conforme a tarefa. Capacidade onde ela rende mais (arquitetura, contratos, a verificação mais difícil); modelos mais baratos onde o volume domina (implementação em massa, relato mecânico de erros). Mais caro em tudo não é mais correto — é só mais caro.
6. Salve o workflow, não só o resultado. O ativo reutilizável é o script de orquestração e o contrato. Eles permitem reproduzir — e melhorar — o resultado deliberadamente, em vez de torcer para o raio cair duas vezes no mesmo lugar.

Na FMKTech, é precisamente esse tipo de orquestração que construímos para clientes: arquiteturas contract-first, frotas de agentes paralelos amarradas por fronteiras tipadas, verificação adversarial e escalonamento de modelos ajustado para custo e qualidade. Um prompt de uma linha produziu um jogo em noventa minutos — mas a versão repetível dessa mágica é um workflow de engenharia, e essa é a parte que vale a pena ter.

Se você está explorando como colocar builds multiagente para trabalhar nos seus próprios produtos, vamos conversar. A alavanca, no fim das contas, nunca foi o modelo. Foi saber como pedir.