Claude Fable 5.2 decifra prompt com erro de digitação e gera animação 3D completa em Three.js

Um prompt torto para testar um modelo novo

Simon Willison, criador do Datasette e um dos blogueiros mais lidos sobre LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →, queria entender onde fica Yonkers, cidade vizinha a Nova York. Depois de checar no Google Maps, ele transformou a curiosidade em teste: pediu ao Claude Fable 5.2 (variante Medium) que desenhasse a cidade "ganhando vida" em 3D, usando dados reais do OpenStreetMap. O relato foi publicado em 10 de novembro de 2026 no blog de Willison.

O resultado se chama Yonkers Rises: um diorama 3D animado em que o contorno real de Yonkers vira um mech gigante, que se levanta do chão e caminha por Manhattan, Brooklyn, Queens e pelo Bronx. A cena roda uma sequência de "ficar em pé" seguida de um passeio de pisadas em loop, com prédios sendo achatados a cada passo. Um contador de pisadas, um indicador de altura do mech e uma linha de status (que muda conforme ele pisa em terra firme ou entra na água) completam a interface.

O prompt que o modelo precisou decifrar

Willison não escreveu um prompt cuidadoso, revisado frase a frase. Ele escreveu o tipo de texto que qualquer pessoa digita no celular, correndo, com autocorretor ligado:

Faça uma animação em three.js em que Yonkers se levanta como um grande mecha (com um movimento legal de ficar em pé) e átomos ao redor de Manhattan, Queens e Brooklyn, usando dados de mapeamento do OpenStreetMap

Simon Willison, criador do Datasette e autor do blog simonwillison.netMake a three js animation where yonkers stands up as a big mech (cool stand up motion) and átomos around manhattan and queens and Brooklyn, use openstreetmap mapping data

A palavra "átomos" chama atenção por um detalhe que o próprio Willison não explorou, mas que vale destacar para quem lê em português: é uma palavra real do nosso idioma. Tudo indica que o teclado do celular dele tinha o dicionário em português ativo e "corrigiu" a palavra em inglês "stomps" (pisadas) para o termo mais próximo que reconhecia em outro idioma, trocando um verbo por um substantivo de outra língua.

Segundo Willison, o Claude Fable 5.2 Medium interpretou corretamente que "átomos" deveria ser "stomps" e gerou a animação com o mech pisando ao redor dos bairros, exatamente como a frase pretendida (sem o erro) pedia.

Por que decifrar um typo importa mais do que parece

Ferramentas de desenvolvimento costumam assumir texto limpo: o compilador reclama de um parêntese faltando, o linter aponta a linha exata. Interfaces conversacionais e agentes de código recebem outro tipo de input: ditado por voz, digitação no celular, falantes não nativos, autocorretor hostil. Decidir que "átomos" não fazia sentido ali e que "stomps" se encaixava no contexto (mech, levantar, andar pelos bairros) é inferência semântica, não correção ortográfica.

Isso tem implicações diretas para quem projeta copilots e agentes:

• Uma camada de sanitização de input se torna menos necessária quando o próprio modelo resolve ambiguidade pelo contexto da tarefa.
• O risco inverso existe: uma "correção" errada do modelo pode mudar o significado pretendido sem avisar o usuário, e o post de Willison não discute esse cenário.
• Em pipelines de geração de código visual (3D, UI, dados), o custo de uma interpretação errada é mais alto que num chat de texto, porque o erro só aparece depois que a cena já está renderizada.

Do contorno real ao WebGL: o que provavelmente aconteceu por baixo

Willison não publicou o código gerado, então o que segue é inferência técnica sobre o tipo de pipeline necessário para esse resultado, não uma descrição do que o Fable 5.2 de fato produziu. Para transformar um contorno municipal do OpenStreetMap num mech animado em Three.js, um esqueleto típico precisaria buscar o polígono de fronteira da cidade, projetar as coordenadas geográficas (latitude e longitude) num plano local e extrudar essa forma numa geometria tridimensional:

// Esqueleto ilustrativo de um pipeline OSM -> Three.js
// (não é o código gerado por Willison, que não foi publicado)
import * as THREE from 'three';

async function loadBoundary(cityName) {
  const geojson = await fetch(`/osm/boundary?city=${cityName}`).then(r => r.json());
  return geojson.features[0].geometry.coordinates;
}

function boundaryToShape(coords, project) {
  const shape = new THREE.Shape();
  coords.forEach(([lng, lat], i) => {
    const [x, y] = project(lng, lat);
    i === 0 ? shape.moveTo(x, y) : shape.lineTo(x, y);
  });
  return shape;
}

const coords = await loadBoundary('Yonkers');
const shape = boundaryToShape(coords, equirectangularProject);
const mechBody = new THREE.ExtrudeGeometry(shape, { depth: 400, bevelEnabled: false });

A linha de status que muda entre terra e água sugere algum teste de ponto dentro de polígono contra as camadas de água do próprio GeoJSON do OpenStreetMap. Os prédios "achatados" a cada pisada indicam colisão simplificada entre o pé do mech e as malhas de edifício, provavelmente trocando a escala vertical do prédio por zero quando o impacto acontece. Nada disso está confirmado por Willison; é o caminho mais plausível para quem já mexeu com dados geográficos em WebGL.

O que muda (e o que não muda) para quem programa

Essa demonstração não é um benchmark. É um relato de uso único, sem código publicado, sem métrica de tempo de geração e sem comparação com outros modelos. Vale como sinal, não como prova.

Onde esse tipo de capacidade generativa já ajuda:

• Prototipagem rápida de visualizações de dados geográficos, sem montar manualmente o pipeline OSM-para-geometria.
• Material educacional ou de divulgação, em que a precisão geométrica importa menos que a ideia transmitida.
• Demos internas e provas de conceito para validar se uma direção criativa vale o investimento de produção.

Onde ela ainda não substitui o trabalho de quem constrói aplicações 3D de verdade:

• Performance em WebGL de produção exige controle fino sobre número de draw calls, nível de detalhe e otimização de malhas, algo que um prompt solto não garante.
• Precisão geográfica para uso sério (simulação urbana, visualização científica) exige validação da fonte de dados, não só um resultado visualmente convincente.
• Sem o código à disposição, não dá para auditar, versionar ou dar manutenção no que foi gerado.

Willison como termômetro informal de modelos

O padrão de Willison é testar modelos em situações reais e meio aleatórias da própria vida, não em suítes de benchmark formais. Na mesma lista de posts recentes do blog aparecem "Locating the source of a mysterious beep with Claude", de 9 de novembro de 2026, e "Qwen 3.8 27B on my laptop can interpret model weights, too", de 3 de novembro de 2026. É um jeito de avaliar modelos que vale a pena acompanhar, mas que pede o mesmo cuidado de sempre: tratar como indício de capacidade, não como garantia reproduzível para o seu caso de uso.

Fonte: Simon Willison