{}A discussão sobre produtividade com agentes de código costuma girar em torno da capacidade do modelo. O artigo “A field guide to Claude Fable 5: Finding your unknowns”, publicado por Thariq Shihipar, membro do corpo técnico da Anthropic, desloca o eixo dessa conversa para outro lugar.
A tese central é que o gargalo raramente está no modelo. Ele está na quantidade de coisas que o desenvolvedor não sabe que não sabe no momento em que escreve o prompt.
Este artigo detalha o método proposto, organiza os padrões em um fluxo de trabalho aplicável e discute as implicações técnicas de cada etapa.
O Claude Fable 5 foi lançado em 9 de junho de 2026 como o primeiro modelo publicamente disponível da classe Mythos, um patamar posicionado acima da linha Opus.
Segundo a documentação da Anthropic, o modelo foi construído para projetos de código ambiciosos, incluindo grandes migrações, implementações complexas e sessões autônomas de vários dias. Executado em um harness de agente como o Claude Code, ele planeja em estágios, delega para subagentes e verifica o próprio trabalho.
Esse perfil de autonomia prolongada é justamente o que torna o problema dos desconhecidos mais agudo. Quanto maior o horizonte de execução, maior o custo de uma premissa errada colocada no início.
Um agente que trabalha por trinta minutos com uma instrução ambígua produz um desvio pequeno. Um agente que trabalha por dois dias sobre a mesma ambiguidade produz uma dívida técnica considerável.
O autor propõe decompor qualquer problema levado ao Claude em quatro categorias. A classificação é simples, mas tem consequências práticas diretas sobre qual técnica aplicar em cada momento.
A observação mais importante do artigo é que os melhores usuários de agentes têm relativamente poucos desconhecidos. Eles sabem em detalhe o que querem, estão sincronizados com a base de código e com o comportamento do modelo. Ao mesmo tempo, eles assumem a existência de desconhecidos e planejam em torno deles. Reduzir e antecipar desconhecidos é apresentado como a habilidade central da programação agêntica, e como uma habilidade treinável em colaboração com o próprio modelo.
Instruir um agente é descrito como um equilíbrio delicado, e a formulação do problema merece atenção técnica.
Se o prompt é específico demais, o Claude seguirá as instruções mesmo quando um desvio seria mais apropriado. Se o prompt é vago demais, o modelo preencherá as lacunas com boas práticas genéricas da indústria, que podem não servir ao contexto.
Quando os desconhecidos não são considerados, ocorre falha nas duas direções simultaneamente. O desenvolvedor não sabe onde o caminho está cheio de obstáculos e também não sabe onde ele está livre, mas ainda assim gostaria que o agente mudasse de rota.
Essa assimetria explica por que instruções mais longas não resolvem o problema por si. O volume de contexto não substitui a qualidade da delimitação entre o que é restrição rígida e o que é espaço de decisão delegado.
Antes de qualquer técnica específica, o artigo aponta um pré-requisito frequentemente ignorado.
O passo mais importante é informar ao modelo qual é o seu ponto de partida: em que estágio do raciocínio você está, qual é a sua experiência com o problema e com a base de código, e a intenção explícita de que ele atue como parceiro de pensamento.
A justificativa é operacional. O Claude percorre a base de código e a internet muito rapidamente, conhece mais do que a média sobre a maioria dos assuntos e itera a partir do erro mais rápido do que uma pessoa. Sem a declaração de nível de experiência, o modelo não tem como calibrar profundidade de explicação nem escolher entre ensinar e executar.
A primeira técnica é chamada literalmente de blind spot pass, ou passagem de pontos cegos.
Ela se aplica quando o trabalho ocorre em uma região desconhecida da base de código ou em um domínio no qual o desenvolvedor não tem repertório. Nesses cenários, a concentração de desconhecidos desconhecidos é alta. O problema típico é não saber quais perguntas fazer, não saber como se parece um bom resultado, ignorar o histórico de trabalho já realizado e desconhecer as armadilhas do domínio.
A recomendação é pedir explicitamente que o modelo identifique e explique esses pontos cegos, usando os termos literais “blind spot pass” e “unknown unknowns”. O autor observa que essas expressões funcionam como âncoras de intenção.
Um exemplo de prompt citado no original trata da adição de um novo provedor de autenticação em uma base de código cujos módulos de auth são desconhecidos, pedindo ao modelo que ajude a mapear os desconhecidos relevantes e, com isso, a escrever prompts melhores. O detalhe relevante é o objetivo declarado: a saída desejada não é o código, é um prompt melhor para a etapa seguinte.
Quando o problema concentra desconhecidos conhecidos — ou seja, critérios que só serão reconhecidos quando vistos — a técnica indicada é brainstorm acompanhado de prototipagem.
A justificativa é econômica. Identificar e verbalizar esses critérios durante a prototipação é barato, enquanto descobri-los durante a implementação é caro. Pequenas mudanças em uma funcionalidade ou especificação podem provocar implementações drasticamente diferentes no código, e reverter alterações já aplicadas é uma operação relativamente difícil para o agente.
O padrão sugerido é isolar a pergunta de forma deliberada. Ver como um botão adicionado a um frame se comporta não exige criar rota de backend nem manter estado adicional no frontend. Design visual aparece como o caso exemplar: algo difícil de articular verbalmente, mas fácil de julgar visualmente, o que favorece pedir várias abordagens em um único artefato para reagir a elas.
Há também um uso mais amplo do brainstorm. O autor inicia quase toda sessão de código com uma fase de exploração, o que ajuda a definir escopo com intenção. O modelo frequentemente encontra abordagens de alto valor que teriam passado despercebidas, e ocasionalmente perde a visão do conjunto. O brainstorm serve como controle contra escopo estreito demais e contra escopo largo demais.
Um dos prompts citados pede a busca na base de código e a proposta de dez pontos possíveis de intervenção para um problema de evasão de usuários após o onboarding, ordenados do mais barato ao mais ambicioso. A ordenação por custo é um detalhe de engenharia importante: ela transforma uma lista de ideias em um espaço de decisão navegável.
Após o brainstorm, permanecem desconhecidos. A técnica seguinte é inverter a direção do diálogo e pedir que o modelo entreviste o desenvolvedor.
O prompt de referência pede uma entrevista, uma pergunta por vez, sobre qualquer ambiguidade, priorizando perguntas cuja resposta alteraria a arquitetura. O critério de priorização é o que dá eficiência à técnica: perguntas com impacto arquitetural são as que reduzem mais risco por unidade de tempo gasto.
O autor reforça que fornecer contexto sobre o problema é necessário para guiar as perguntas. Sem isso, a entrevista tende a percorrer generalidades.
Existem casos em que o desenvolvedor não consegue descrever o que quer em detalhe, seja por falta de vocabulário técnico, seja porque a descrição precisa levaria tempo excessivo. A recomendação é usar uma referência. E há uma hierarquia explícita entre os tipos de referência possíveis.
Diagramas, documentação e imagens são aceitáveis, mas a melhor referência é código-fonte. A razão é a densidade de informação.
O código carrega detalhe estrutural e de marcação que uma captura de tela não transmite. Se existe uma biblioteca que implementa um comportamento da forma desejada, ou um componente de design apreciado, basta apontar o modelo para a pasta e indicar o que procurar.
O ponto mais interessante é que a referência funciona mesmo em outra linguagem. O exemplo citado no artigo aponta um crate Rust em um diretório vendor que implementa o comportamento de backoff desejado, com o pedido de reimplementar a mesma semântica em um cliente de API em TypeScript. Isso reposiciona a referência de código como transferência de semântica, e não como cópia de sintaxe.
Quando o desenvolvedor se considera pronto para implementar, a etapa recomendada é solicitar um plano de implementação para revisão.
O plano deve concentrar-se nas partes com maior probabilidade de mudança, tipicamente modelos de dados, interfaces de tipos e fluxos de experiência do usuário. O objetivo é fazer o modelo trazer à superfície exatamente aquilo que ainda pode ser alterado.
O prompt citado pede que o plano seja escrito em HTML, começando pelas decisões mais sujeitas a ajuste, e que a refatoração mecânica fique no final, com confiança delegada ao agente. A estrutura do documento é, aqui, uma decisão de engenharia: ordenar por probabilidade de mudança, e não por ordem de execução, otimiza o plano para revisão humana.
Satisfeito o plano, o autor abre uma nova sessão e passa os artefatos produzidos como entrada do prompt. Isso oferece ao modelo uma janela de contexto limpa, mas contendo toda a informação compilada na fase de planejamento. Uma especificação e um protótipo podem ser entregues juntos para que o agente implemente.
A gestão deliberada da janela de contexto merece destaque. Planejamento e implementação são tratados como fases com necessidades de contexto distintas, e não como uma conversa contínua.
Ainda assim, o artigo é explícito quanto ao limite do planejamento. Independentemente do esforço investido, sempre restam desconhecidos desconhecidos à espreita. O agente pode descobrir, durante a execução, que precisa mudar de abordagem por causa de um caso de borda encontrado no código.
A técnica de mitigação é pedir ao Claude Code que mantenha um arquivo temporário de notas de implementação, em Markdown ou HTML, registrando as decisões tomadas para aprendizado na tentativa seguinte. O prompt de referência acrescenta uma política de decisão: diante de um caso de borda que force desvio do plano, o agente deve escolher a opção conservadora, registrar o ocorrido em uma seção de desvios e prosseguir.
Isso constitui um protocolo simples de autonomia governada. O agente não interrompe o trabalho a cada dúvida, mas também não esconde o desvio.
Entregar código é apenas parte do trabalho. Obter adesão e aprovação é apresentado como parte igualmente importante do processo de shipping.
Construir artefatos de apresentação e explicação no documento final acelera duas coisas. A primeira é a compreensão dos revisores que partem dos mesmos desconhecidos que o autor tinha no início. A segunda é a aprovação de especialistas que desejam ver evidência de que os desconhecidos e os pontos comuns de falha foram considerados.
O prompt citado pede o empacotamento do protótipo, da especificação e das notas de implementação em um único documento compartilhável, liderado pela demonstração visual. Note que os três insumos desse documento são exatamente os artefatos produzidos nas etapas anteriores: o método é cumulativo por construção.
A última técnica é a mais incomum e possivelmente a mais valiosa em contextos de sessões longas.
Após uma sessão extensa, o modelo pode ter realizado muito mais do que o desenvolvedor percebeu. Ler os diffs oferece apenas compreensão superficial, porque grande parte do comportamento depende de caminhos de código já existentes.
A solução proposta é pedir ao Claude que aplique um questionário sobre a mudança. O autor declara que só faz merge após acertar o quiz integralmente.
O prompt citado pede um relatório em HTML sobre as alterações, com contexto e intuição sobre o que foi feito, seguido de um questionário obrigatório ao final. Isso institui uma verificação de compreensão como critério de qualidade, ao lado dos testes automatizados. O código pode passar na suíte de testes e ainda assim ser inadequado para manutenção se ninguém no time entende por que ele funciona.
O artigo encerra com um exemplo concreto: o vídeo de lançamento do próprio Fable, editado de ponta a ponta com o Claude Code em um domínio no qual o autor não é especialista. A sequência de raciocínio é instrutiva porque cada etapa endereça uma categoria diferente de desconhecido.
O ponto de partida foi o conhecido conhecido. O autor sabia que o Claude podia usar código para editar e transcrever vídeos, mas não tinha certeza sobre a acurácia. Esse conhecido desconhecido foi tratado por explicação: ele pediu ao modelo que explicasse como funciona a transcrição no estilo Whisper e se seria possível cortar hesitações e pausas longas com precisão usando ffmpeg.
A viabilidade de uma interface sincronizada com as palavras faladas era incerta, então foi tratada por protótipo. O pedido foi criar um vídeo de demonstração com Remotion e uma transcrição para verificar se a ideia funcionava.
O caso final é o mais didático. O vídeo parecia sem vida, o que o autor sabia estar relacionado a color grading, sem saber o que color grading realmente é. A primeira tentativa foi pedir variações para escolher. Ela falhou por um motivo específico e reconhecido: o autor não sabia como se parecia um bom resultado.
A correção foi trocar geração por ensino. Em vez de pedir variações, ele pediu ao modelo que o ensinasse sobre color grading para descobrir seus desconhecidos. Essa é a lição operacional mais forte do artigo: pedir opções só funciona quando existe critério de julgamento, e quando o critério não existe, a etapa anterior é construí-lo.
O fechamento do artigo articula o princípio geral. Quanto melhores os modelos ficam, mais se pode alcançar com a abordagem correta.
Quando uma tarefa de longo horizonte retorna errada, a causa provável não é a capacidade do modelo. É a necessidade de dedicar mais tempo à definição dos desconhecidos ou de construir um plano de implementação que permita adaptação conjunta durante a execução.
Cada explicador, brainstorm, entrevista, protótipo e referência é descrito como uma forma barata de descobrir o que não se sabia antes que a correção fique cara. Para times que operam com agentes em regime de autonomia prolongada, a implicação prática é clara: o investimento marginal mais rentável não está em prompts mais longos, e sim em rituais de descoberta anteriores à primeira linha de código.
É uma etapa inicial na qual o desenvolvedor pede explicitamente ao modelo que identifique e explique seus desconhecidos desconhecidos sobre um domínio ou parte da base de código. O objetivo declarado da etapa não é gerar código, mas produzir um prompt melhor para a fase seguinte.
Porque carrega densidade estrutural muito maior. O código expõe marcação, organização e semântica de comportamento, enquanto uma imagem transmite apenas o resultado visual final.
Não. O artigo cita explicitamente o caso de apontar um crate Rust como referência para reimplementar a mesma semântica de backoff em um cliente TypeScript.
Para dar ao modelo uma janela de contexto limpa, mas contendo os artefatos compilados na fase de planejamento. Isso evita arrastar todo o histórico exploratório para a fase de execução.
Registrar as decisões e os desvios tomados pelo agente diante de casos de borda encontrados durante a execução. Ele serve como insumo de aprendizado para a tentativa seguinte e como material para o documento de apresentação final.
Porque ler diffs oferece compreensão superficial quando o comportamento depende de caminhos de código já existentes. O quiz verifica se o desenvolvedor realmente entende a mudança que está aprovando.
As técnicas são independentes de modelo, mas ganham relevância proporcional ao horizonte de autonomia. Em sessões longas e multiestágio, o custo de uma premissa não examinada no início cresce significativamente.
IA{}Como o Microsoft Agent Framework coordena vários agentes de IA em pipelines sequenciais e grafos dirigidos, com exemplos reais em C# usando o SDK Microsoft.Agents.AI.
IA{}Dois dos frameworks mais comentados para construir agentes de IA seguem filosofias diferentes. Entenda o que cada um é, como se comparam e quando escolher um ou outro.