Trabalhar com o Claude Fable 5 continua me ensinando uma lição antiga: o mapa não é o território.
O mapa, uma representação do trabalho a ser feito, são meus prompts, habilidades e contexto, é o que eu dou ao Claude. O território é onde o trabalho precisa acontecer, a base de código, o mundo real, suas restrições reais.
A diferença entre o mapa e o território é o que chamo de incógnitas. Quando o Claude encontra uma incógnita, ele precisa tomar uma decisão baseada no seu melhor palpite do que eu quero. Quanto mais trabalho é feito, mais incógnitas o Claude pode encontrar.
Fable é o primeiro modelo em que percebo que a qualidade do trabalho é limitada pela minha capacidade de esclarecer suas incógnitas.
Importante: apenas planejar com antecedência nem sempre é suficiente. Você pode encontrar incógnitas no fundo da implementação, ou suas incógnitas podem apontar que você deveria, na verdade, resolver o problema de uma maneira completamente diferente.
Descobri que trabalhar com o Fable é um processo iterativo de descobrir minhas incógnitas antes, durante e depois da implementação.
Criei alguns exemplos de artefatos para encontrar incógnitas aqui, mas volte para construir a intuição de quando usá-los.
Conhecendo suas incógnitas
Quais são suas incógnitas? Quando chego ao Claude com um problema, costumo dividi-lo em 4 maneiras:
- Conhecidos Conhecidos: É essencialmente o que está no meu prompt. O que eu digo ao agente que quero?
- Incógnitas Conhecidas: O que ainda não descobri, mas estou ciente de que não descobri?
- Conhecidos Incógnitos: O que é tão óbvio que eu nunca escreveria, mas reconheceria se visse?
- Incógnitas Incógnitas: O que não considerei de forma alguma? De que conhecimento não estou ciente? Eu sei o quão bom algo pode ser?
Os melhores codificadores agentivos são bons e têm relativamente poucas incógnitas. Observar alguém como Boris ou Jarred fazendo um prompt, é óbvio para mim que eles sabem o que querem em detalhes. Eles estão profundamente sincronizados tanto com a base de código quanto com os comportamentos do modelo.
Mas eles também assumem incógnitas. De muitas maneiras, reduzir e planejar suas incógnitas é a habilidade da codificação agentiva. Mas, felizmente, esta é uma habilidade que você pode melhorar, trabalhando com o Claude.
Ajude o Claude a te ajudar
Instruir o Claude é um equilíbrio delicado. Se você for muito específico, o Claude seguirá suas instruções mesmo quando uma mudança de direção for mais apropriada. Se você for muito vago, o Claude frequentemente fará escolhas e suposições baseadas nas melhores práticas do setor que podem não ser adequadas para sua tarefa.
Quando você não considera suas incógnitas, falha de ambas as maneiras. Você não sabe quando o caminho será cheio de obstáculos e não sabe quando o caminho estará livre, mas ainda quer que o Claude se desvie.
O Claude pode ajudá-lo a descobrir suas incógnitas mais rapidamente. Ele pode pesquisar sua base de código e a internet extremamente rápido e sabe muito mais sobre o tópico médio do que você. Ele também pode iterar a partir do fracasso mais rapidamente.
A parte mais importante deste processo é dar ao Claude contexto sobre seu ponto de partida. Por exemplo, diga a ele onde você está em seu processo de pensamento; revele sua experiência com o problema e a base de código; e deixe-o trabalhar com você como um parceiro de reflexão.
Já escrevi anteriormente sobre o uso de HTML com Claude; em quase todos esses casos, um artefato HTML é a melhor maneira de visualizar e representar isso.
Neste artigo, detalho alguns dos padrões que uso para descobrir essas incógnitas. Não uso todas as técnicas todas as vezes, mas é uma coleção útil de técnicas para se ter.
Pré-implementação
Passagem de Pontos Cegos
Ao iniciar o trabalho, uma das coisas mais úteis que você pode fazer é entender seus pontos cegos. Por exemplo, se você está escrevendo um recurso em uma nova parte da base de código ou usando o Claude para ajudá-lo em trabalhos desconhecidos, como iterar em um design, é provável que tenha muitas incógnitas incógnitas.
Você pode não saber quais perguntas fazer, como é o "bom", que trabalho histórico foi feito ou quais armadilhas evitar.
Para fazer isso, você pode pedir ao Claude para ajudá-lo a encontrar suas incógnitas incógnitas e explicá-las para você. Gosto de usar as palavras literais "passagem de pontos cegos" e "incógnitas incógnitas". Dar a ele contexto sobre quem você é e o que sabe geralmente é importante.
Exemplos de Prompts:
- "Estou trabalhando para adicionar um novo provedor de autenticação, mas não sei nada sobre os módulos de autenticação nesta base de código. Você pode fazer uma passagem de pontos cegos para me ajudar a descobrir minhas incógnitas incógnitas relevantes e me ajudar a fazer prompts melhores para você?"
- "Não sei o que é correção de cor, mas preciso corrigir este vídeo. Você pode me ensinar a entender minhas incógnitas incógnitas sobre correção de cor, para que eu possa fazer prompts melhores?"
Brainstorms e Protótipos
Quando estou trabalhando em uma área com muitos conhecidos incógnitos, envolvendo critérios que só sei definir quando os vejo, gosto de pedir ao Claude para fazer um brainstorm e prototipar comigo.
É extremamente valioso identificar e verbalizar conhecidos incógnitos no início durante a prototipagem, porque descobri-los durante a implementação pode ser (relativamente) caro. Pequenas mudanças em um recurso ou especificação podem causar implementações drasticamente diferentes no código e pode ser mais difícil para seu agente reverter alterações anteriores.
Por exemplo, você pode querer apenas ver como um botão adicionado a um quadro fica sem ter que configurar uma rota de backend ou manter estado adicional no frontend.
O design visual é algo que para mim é difícil de articular, mas sei o que quero quando vejo. Nesses casos, peço várias abordagens de design para um artefato.
Também começo quase toda sessão de codificação com uma fase de exploração ou brainstorming. Isso me ajuda a começar com a intenção de definir o escopo do projeto. O Claude frequentemente encontra abordagens de alto valor que eu teria perdido e, às vezes, não vê a floresta por causa das árvores. O brainstorming me impede de definir um escopo muito estreito ou muito amplo.
Exemplos de prompts:
- "Quero um painel para esses dados, mas não tenho bom gosto visual e não sei o que é possível. Faça-me uma página HTML com 4 direções de design radicalmente diferentes para que eu possa reagir a elas."
- "Antes de conectar qualquer coisa, faça um único arquivo HTML simulando a nova barra de ferramentas do editor com dados falsos. Quero reagir ao layout antes de você tocar no aplicativo real."
- "Aqui está meu problema aproximado: os usuários desistem após a integração. Pesquise a base de código e faça um brainstorming de 10 lugares onde podemos intervir, do mais barato ao mais ambicioso. Direi quais ressoam comigo."
Entrevistas
Depois de fazer brainstorming suficiente, provavelmente ainda tenho incógnitas.
Nesse caso, peço ao Claude para me entrevistar sobre quaisquer incógnitas ou ambiguidades. Ao pedir ao Claude para entrevistá-lo, tente dar a ele contexto sobre seu problema para orientar suas perguntas. Aqui estão alguns exemplos.
Exemplos de prompts:
- "Entreviste-me uma pergunta de cada vez sobre qualquer coisa ambígua, priorize perguntas onde minha resposta mudaria a arquitetura."
Referências
Às vezes você não consegue descrever o que quer em detalhes. Por exemplo, você pode não ter o vocabulário ou pode ser tão complicado que levaria um bom tempo.
Nesse caso, a melhor resposta é uma referência. Embora você possa incluir diagramas, documentação ou imagens, a melhor referência absoluta é o código-fonte.
Se você tem uma biblioteca que implementa algo de uma certa maneira ou um componente de design de que realmente gosta, basta apontar o Fable para a pasta e dizer a ele o que procurar, mesmo que esteja em um idioma diferente.
É assim que o Claude Design funciona também. Você não precisa entregar um arquivo (embora também possa fazer isso). Você pode apontá-lo para um módulo em um site de que gosta, e ele lê o código subjacente, não apenas a captura de tela. Isso fornece detalhes muito mais ricos sobre a marcação, a estrutura e como o componente é realmente construído.
Exemplos de prompts:
- "Este crate Rust em vendor/rate-limiter implementa o comportamento de backoff exato que eu quero. Leia-o e reimplemente a mesma semântica em nosso cliente de API TypeScript."
Planos de Implementação
Quando acho que estou pronto para implementar, costumo pedir ao Claude para montar um plano de implementação para eu revisar, que se concentre nas partes que podem ser mais propensas a mudar, por exemplo, para revisar modelos de dados, interfaces de tipo ou fluxos de UX. Isso permite que o Claude traga à tona coisas que eu posso realmente precisar alterar.
Exemplos de Prompts:
- "Escreva um plano de implementação em HTML, mas comece com as decisões que tenho mais probabilidade de ajustar: mudanças no modelo de dados, novas interfaces de tipo e qualquer coisa voltada para o usuário. Enterre a refatoração mecânica no final, confio em você nessa parte."
Durante a implementação
Notas de Implementação
Depois de satisfeito com meu plano, crio uma nova sessão e passo todos os artefatos para o prompt. Por exemplo, posso passar um arquivo de especificação e um protótipo e pedir a um agente para implementá-lo.
Mas a verdade é que, não importa quanto planejamento você faça, sempre há incógnitas incógnitas à espreita. O agente pode descobrir durante seu trabalho que precisa seguir um caminho diferente devido a um caso extremo que encontrou no código.
Peço ao Claude Code para manter um arquivo temporário 'implementation-notes.md' (ou .html) onde ele mantém o controle das decisões que toma para que possamos aprender com nossa próxima tentativa.
Exemplos de prompts:
- "Mantenha um arquivo implementation-notes.md. Se você encontrar um caso extremo que o force a se desviar do plano, escolha a opção conservadora, registre-a em 'Desvios' e continue."
Pós-implementação
Apresentações e Explicações
Uma das partes mais importantes de lançar algo é obter adesão e aprovações. Construir artefatos de apresentação e explicação no documento final ajuda a:
- Acelerar a compreensão quando os revisores começam com as mesmas incógnitas que você
- Acelerar as aprovações quando especialistas querem ver se você considerou as incógnitas e os pontos de falha comuns que eles teriam antecipado
Exemplos de prompts:
- "Empacote o protótipo, a especificação e as notas de implementação em um único documento que posso colocar no Slack para obter adesão. Comece com o GIF de demonstração."
Questionários
Após uma longa sessão de trabalho, o Claude pode ter realizado muito mais do que eu imaginava. Ler os diffs de código só pode me dar uma compreensão superficial do que aconteceu, já que grande parte do comportamento dependerá dos caminhos de código existentes.
Pedir ao Claude para me testar sobre a mudança depois de me dar um monte de contexto me ajuda a entender o que aconteceu. Só faço merge depois de passar no teste perfeitamente.
Exemplos de prompts:
- "Quero ter certeza de que entendi tudo o que aconteceu nesta mudança. Faça-me um relatório HTML sobre as mudanças para eu ler e entender com contexto, intuição, o que foi feito, etc., e um questionário no final sobre as mudanças que devo passar."
Como isso se junta: lançando o Fable
O vídeo de lançamento do Fable foi editado inteiramente pelo Claude Code. Este era um novo domínio para mim e não sou de forma alguma um especialista.
Então, comecei com o que eu sabia. Eu sabia que o Claude poderia usar código para editar vídeos e transcrevê-los, mas não tinha certeza se era preciso o suficiente. Em seguida, pedi ao Claude para me explicar como funcionava a transcrição, como o Whisper, e se eu seria capaz de cortar com precisão coisas como "hums" ou longas pausas usando o ffmpeg.
Eu queria que o Claude criasse uma interface do usuário que fosse sincronizada com as palavras que eu estava dizendo, mas não tinha certeza se ele conseguiria, então pedi ao Claude para criar um protótipo de vídeo usando Remotion e uma transcrição para ver se funcionaria.
Finalmente, o vídeo em si parecia um pouco sem cor, o que eu sabia ser resultado da correção de cor, mas eu realmente não sabia o que era correção de cor. Minha primeira tentativa foi fazer o Claude criar algumas variações para eu escolher, mas percebi que não sabia como era o "bom" quando se tratava de correção de cor. Então, em vez disso, pedi ao Claude para me ensinar sobre correção de cor para descobrir minhas incógnitas.
Você pode assistir a uma explicação mais aprofundada sobre isso aqui.
Combinando o Mapa e o Território
Quanto melhores os modelos ficam, mais você pode alcançar com a abordagem certa. Quando uma tarefa de longo prazo retorna errada, é provável que você precise gastar mais tempo definindo suas incógnitas ou criando um plano de implementação que permita ao Claude improvisar através delas.
Cada explicação, brainstorming, entrevista, protótipo e referência é uma maneira barata de descobrir o que você não sabia antes que se torne caro para consertar.
Então, comece seu próximo projeto pedindo ao Claude para ajudá-lo a encontrar suas incógnitas.
