Guia de campo do Fable: encontrando meus desconhecidos (Unknowns)

• O núcleo do trabalho com Claude Fable 5 é encontrar e reduzir a lacuna entre o mapa (map, prompts, skills e contexto) fornecido pelo usuário e o território (territory, codebase, realidade e restrições) onde o trabalho realmente acontece — ou seja, os desconhecidos (unknowns)
• O Fable é o primeiro modelo em que a qualidade do trabalho é determinada pela capacidade do usuário de esclarecer os desconhecidos; quanto maior o volume de trabalho, mais desconhecidos aparecem
• Os desconhecidos se dividem em 4 tipos: Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns; reduzir os desconhecidos e se preparar para eles é uma competência central da codificação agentic
• Antes, durante e depois da implementação, descubra desconhecidos com técnicas iterativas como blindspot pass, brainstorming, entrevistas, referências, planos de implementação, notas de implementação e quizzes
• Explicações, brainstormings, entrevistas, protótipos e referências são meios de descobrir desconhecidos de forma barata antes que o problema fique caro; é importante começar o próximo projeto pedindo ao Claude para encontrar os desconhecidos

---

Mapa, território e desconhecidos (Unknowns)

• O mapa é a representação da tarefa a ser executada: prompts, skills e contexto, ou seja, aquilo que você dá ao Claude; o território é onde o trabalho realmente acontece: codebase, realidade e restrições reais
• A diferença entre o mapa e o território é justamente o conjunto de desconhecidos (unknowns); quando o Claude esbarra neles, precisa tomar decisões com base no melhor palpite sobre o que o usuário quer
• O Fable é o primeiro modelo em que a qualidade do trabalho fica limitada pela capacidade de esclarecer desconhecidos
• Planejamento prévio, por si só, não basta; desconhecidos podem ser encontrados no fundo da implementação ou indicar que o problema precisa ser resolvido de uma forma completamente diferente
• Trabalhar com o Fable é um processo iterativo de descoberta de desconhecidos antes, durante e depois da implementação
• Alguns exemplos de materiais que ajudam a encontrar desconhecidos para consultar depois

Conhecendo seus desconhecidos (Knowing your unknowns)

• Decomponha o problema em 4 categorias
  • Known Knowns: aquilo que está no prompt, o que você diz ao agente que quer
  • Known Unknowns: aquilo que você ainda não entendeu, mas sabe que não entendeu
  • Unknown Knowns: aquilo que é tão óbvio que você não escreve, mas reconhece quando vê
  • Unknown Unknowns: aquilo que você nunca considerou, conhecimento de que não tem consciência, ou até onde algo poderia melhorar
• Bons coders agentic têm relativamente poucos desconhecidos e estão profundamente em sincronia (in-sync) com a codebase e o comportamento do modelo, sabendo em detalhe o que querem
• Reduzir desconhecidos e se preparar para eles é uma habilidade que pode melhorar trabalhando com o Claude

Ajude o Claude a ajudar você (Help Claude help you)

• Instruções exigem equilíbrio: se forem específicas demais, o modelo as seguirá mesmo quando seria melhor mudar de direção; se forem vagas demais, ele fará escolhas com base em convenções do setor (best practices) que podem não se aplicar à tarefa
• Se você não considerar os desconhecidos, falhará dos dois lados: vai querer que o Claude mude de direção sem saber quando um caminho está bloqueado ou quando está se abrindo
• O Claude acelera a descoberta de desconhecidos porque consegue pesquisar rapidamente a codebase e a internet, sabe mais sobre temas médios e itera rapidamente a partir de falhas
• O mais importante é fornecer contexto sobre o ponto de partida: explicite onde está no seu raciocínio e sua experiência com o problema e a codebase, colaborando como se fosse com um parceiro de pensamento
• Já escrevi antes sobre usar HTML no Claude; na maioria dos casos, artefatos HTML são ideais para visualização e apresentação

Pré-implementação (Pre-implementation)

• Blind Spot Pass

  • Em trabalhos desconhecidos, como escrever uma funcionalidade em uma nova área ou iterar em design, há muitos unknown unknowns; talvez você não saiba quais perguntas fazer, o que é bom, quais trabalhos anteriores existem ou quais armadilhas evitar
  • Peça ao Claude para encontrar e explicar os unknown unknowns; é importante usar explicitamente as expressões "blindspot pass" e "unknown unknowns" e fornecer contexto sobre quem você é e o que sabe
  • Exemplos de prompts
    • "Estou adicionando um novo auth provider, mas não conheço nada do módulo de auth desta codebase. Faça um blindspot pass para identificar unknown unknowns relevantes e me ajudar a formular melhor o prompt"
    • "Não sei o que é color grading, mas preciso fazer grade neste vídeo. Ensine-me a entender os unknown unknowns de color grading para que eu possa escrever um prompt melhor"

• Brainstormings e protótipos (Brainstorms and prototypes)

  • Em áreas com muitos unknown knowns, ou seja, muitos critérios que você reconhece quando vê, mas que são difíceis de definir com antecedência, faça brainstorming e protótipos com o Claude
  • É valioso identificar e colocar em palavras os unknown knowns no início da prototipagem, não durante a implementação, porque uma pequena mudança na especificação pode alterar muito a implementação do código e tornar difícil reverter mudanças anteriores
    • Ex.: quando você só quer ver como ficaria adicionar um botão a um frame, sem rotas de backend nem estado de frontend
  • Design visual é uma área difícil de expressar claramente, mas em que você sabe o que quer quando vê; peça várias abordagens de design
  • Comece quase toda sessão de coding por uma fase de exploração e brainstorming, definindo o escopo com intenção; isso evita que o escopo fique estreito ou amplo demais
  • Exemplos de prompts
    • "Quero um dashboard para estes dados, mas não tenho senso visual e não sei o que é possível. Crie páginas HTML em 4 direções de design totalmente diferentes para que eu possa reagir"
    • "Antes da integração, crie um único arquivo HTML mockando a nova toolbar do editor com dados falsos. Quero reagir ao layout antes de mexer no app real"
    • "O problema geral é abandono de usuários depois do onboarding. Pesquise a codebase e faça brainstorming de 10 pontos de intervenção, do mais barato ao mais ambicioso"

• Entrevistas (Interviews)

  • Se ainda houver desconhecidos depois de bastante brainstorming, peça ao Claude para entrevistar você sobre desconhecidos e ambiguidades, fornecendo o contexto do problema para orientar as perguntas
  • Exemplo de prompt
    • "Faça uma pergunta por vez sobre as partes ambíguas e priorize perguntas cujas respostas mudariam a arquitetura"

• Referências (References)

  • Quando você não consegue descrever em detalhes o que quer, a melhor resposta são referências; podem ser diagramas, documentos ou imagens, mas código-fonte é de longe a melhor referência
  • Se houver uma biblioteca implementada de uma forma específica ou um componente de design de que você gosta, aponte a pasta, mesmo que seja em outra linguagem, e instrua o Claude a procurá-la
  • O Claude Design funciona do mesmo modo: ao apontar para um módulo de um site de que você gosta, ele lê o código subjacente, não um screenshot, oferecendo informações ricas sobre markup, estrutura e implementação real
  • Exemplo de prompt
    • "Este crate Rust em vendor/rate-limiter implementa exatamente o comportamento de backoff que quero. Leia e reimplemente a mesma semântica no nosso cliente de API em TypeScript"

• Planos de implementação (Implementation Plans)

  • Quando estiver pronto para implementar, peça um plano de implementação para revisão com foco nas partes com maior probabilidade de mudar — modelo de dados, interfaces de tipos e fluxo de UX — para trazer à superfície os pontos que talvez precisem ser ajustados
  • Exemplo de prompt
    • "Escreva o plano de implementação em HTML, colocando primeiro as decisões em que eu provavelmente vou mexer mais (mudança no modelo de dados, novas interfaces de tipos, elementos voltados ao usuário) e deixando refatorações mecânicas no final"

Durante a implementação (During implementation)

• Notas de implementação (Implementation notes)

  • Quando estiver satisfeito com o plano, crie uma nova sessão e passe ao agente os artefatos, como o arquivo de especificação e o protótipo, no prompt, pedindo a implementação
  • Por mais que você planeje, unknown unknowns sempre ficam à espreita; um edge case encontrado pelo agente durante o trabalho pode exigir outra abordagem
  • Peça ao Claude Code para registrar as decisões tomadas em um arquivo temporário implementation-notes.md (ou .html), de modo que a próxima tentativa aprenda com elas
  • Exemplo de prompt
    • "Mantenha um arquivo implementation-notes.md. Se encontrar um edge case que force desviar do plano, faça a escolha conservadora, registre em 'Deviations' e continue"

Pós-implementação (Post implementation)

• Pitches e explicadores (Pitches and explainers)

  • Uma das partes mais importantes de lançar algo é obter concordância e aprovação; criar artefatos de pitch e explicação na documentação final ajuda
    • Quando os revisores partem dos mesmos desconhecidos que você, isso acelera o entendimento
    • Quando especialistas querem verificar se você considerou os desconhecidos e os pontos comuns de falha, isso acelera a aprovação
  • Exemplo de prompt
    • "Agrupe o protótipo, a especificação e as notas de implementação em um único documento para postar no Slack e obter concordância. Coloque o GIF de demo no início"

• Quizzes

  • Depois de uma sessão longa, o Claude pode ter feito mais do que você esperava; apenas o diff do código dá uma compreensão superficial do comportamento que depende de caminhos existentes do código
  • Depois de fornecer contexto, peça ao Claude para criar um quiz sobre as mudanças para verificar seu entendimento, e só faça merge depois de passar perfeitamente no quiz
  • Exemplo de prompt
    • "Quero entender tudo o que aconteceu nesta mudança. Gere um relatório em HTML com contexto, intuição e o que foi feito, e inclua no final um quiz em que eu preciso passar"

Como tudo isso se junta no caso de lançamento do Fable (How this comes together)

• O vídeo de lançamento do Fable foi editado inteiramente com Claude Code, em uma área nova e que não era minha especialidade
• Começando pelo que eu sabia: eu sabia que o Claude podia editar e transcrever vídeo com código, mas não tinha certeza da precisão, então pedi uma explicação sobre como funciona a transcrição no estilo Whisper e se o ffmpeg conseguiria cortar com precisão ums e longos silêncios
• Eu queria uma UI em que as palavras faladas e o timing combinassem, mas não tinha certeza se seria possível; validei criando um vídeo protótipo com Remotion e transcrição
• Eu sabia que o vídeo parecia um pouco muted por causa de color grading, mas não sabia o que isso era; em vez de escolher variações, pedi que ele me ensinasse color grading para descobrir desconhecidos

Alinhando o mapa e o território (Matching the Map and Territory)

• Quanto melhores os modelos ficam, mais coisas se tornam possíveis com a abordagem correta; quando uma tarefa longa volta errada, em geral é preciso gastar mais tempo na definição dos desconhecidos ou em um plano de implementação no qual o Claude possa improvisar
• Todas as explicações, brainstormings, entrevistas, protótipos e referências são meios de descobrir desconhecidos de forma barata antes que o problema fique caro
• O ponto central é começar o próximo projeto pedindo ao Claude para encontrar os desconhecidos