Engenharia de contexto na prática com o Claude Fable 5

O contexto do lançamento do Claude Fable 5

Lançado em 9 de junho de 2026, o Claude Fable 5 é o primeiro modelo da classe Mythos para uso geral. Segundo o anúncio da Anthropic, a classe Mythos fica acima da linha Opus em capacidade.

De acordo com a página oficial do Claude Fable, o modelo mira projetos de código ambiciosos, incluindo 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 torna a engenharia de contexto ainda mais importante.

Afinal, quanto maior o horizonte de execução, maior o custo de uma premissa errada colocada no início. Um agente que trabalha dois dias sobre uma instrução ambígua produz uma dívida técnica considerável.

A matriz de desconhecidos da engenharia de contexto

O autor propõe decompor qualquer problema levado ao Claude em quatro categorias. A classificação é simples, mas define qual técnica de engenharia de contexto aplicar em cada momento.

Conhecidos conhecidos. São essencialmente o conteúdo do prompt, ou seja, aquilo que o desenvolvedor consegue articular explicitamente sobre o que deseja.

Conhecidos desconhecidos. São as lacunas percebidas, isto é, questões que o desenvolvedor sabe que ainda não resolveu.

Desconhecidos conhecidos. São os critérios tão óbvios que ninguém escreveria, como preferências de design visual e convenções implícitas do time, mas que qualquer pessoa reconheceria se visse.

Desconhecidos desconhecidos. São as questões que ninguém considerou, incluindo a própria noção de quão bom um resultado poderia ser.

Segundo o guia, os melhores usuários de agentes têm poucos desconhecidos, mas assumem que eles existem e planejam em torno deles. Por isso, o autor trata a redução de desconhecidos como a habilidade central da programação agêntica, treinável com o próprio modelo.

O paradoxo da instrução na engenharia de contexto

Instruir um agente exige um equilíbrio delicado, e a formulação do problema merece atenção técnica. Na engenharia de contexto, o excesso e a falta de detalhe produzem falhas diferentes.

Se o prompt é específico demais, o Claude seguirá as instruções mesmo quando um desvio seria mais apropriado. Por outro lado, se o prompt é vago demais, o modelo preenche as lacunas com boas práticas genéricas, que podem não servir.

Quando ninguém considera os desconhecidos, a falha acontece nas duas direções ao mesmo tempo. O desenvolvedor não sabe onde há obstáculos nem onde o caminho está livre para o agente mudar de rota.

Essa assimetria explica por que instruções mais longas não resolvem o problema sozinhas. Em outras palavras, o volume de contexto não substitui a delimitação clara entre restrição rígida e espaço de decisão delegado.

Engenharia de contexto começa pelo ponto de partida

Antes de qualquer técnica específica, o guia aponta um pré-requisito frequentemente ignorado. O passo mais importante é informar ao modelo qual é o seu ponto de partida.

Isso inclui o estágio do raciocínio em que você está e a sua experiência com o problema e com a base de código. Também inclui a intenção explícita de que o modelo atue como parceiro de pensamento.

A justificativa é operacional. O Claude percorre a base de código e a internet muito rápido e itera a partir do erro mais depressa que uma pessoa.

Sem a declaração de nível de experiência, porém, o modelo não consegue calibrar a profundidade da explicação. Ele também não sabe se deve ensinar ou simplesmente executar.

Pré-implementação: a passagem de pontos cegos

A primeira técnica se chama literalmente 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 nem como se parece um bom resultado, além de desconhecer as armadilhas do domínio.

A recomendação é pedir explicitamente que o modelo identifique e explique esses pontos cegos, usando os termos "blind spot pass" e "unknown unknowns". Segundo o autor, essas expressões funcionam como âncoras de intenção.

Um dos prompts citados trata da adição de um novo provedor de autenticação em uma base de código cujos módulos de auth o desenvolvedor não conhece. Nesse caso, o pedido é que o modelo ajude a mapear os desconhecidos relevantes e, com isso, a escrever prompts melhores.

O detalhe relevante é o objetivo declarado, pois a saída desejada não é código, e sim um prompt melhor. Por isso, essa técnica é um exercício puro de engenharia de contexto.

Brainstorms e protótipos

Quando o problema concentra desconhecidos conhecidos, ou seja, critérios que você só reconhece quando vê, a técnica indicada é o brainstorm acompanhado de prototipagem.

A justificativa é econômica. Identificar e verbalizar esses critérios durante a prototipação custa pouco, enquanto descobri-los durante a implementação custa caro.

Pequenas mudanças na especificação podem gerar implementações muito diferentes, e reverter alterações é difícil para o agente. Por isso, o guia sugere isolar a pergunta, como testar um botão sem criar rota de backend.

O design visual aparece como o caso exemplar. Trata-se de algo difícil de articular verbalmente, mas fácil de julgar visualmente, então vale 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 o escopo com intenção.

Assim, o brainstorm serve como controle contra escopo estreito demais e contra escopo largo demais.

Um dos prompts citados pede dez pontos de intervenção para a evasão de usuários após o onboarding. A lista deve vir ordenada da opção mais barata para a mais ambiciosa.

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.

Entrevistas como técnica de engenharia de contexto

Mesmo após o brainstorm, alguns desconhecidos permanecem. A técnica seguinte inverte a direção do diálogo e pede que o modelo entreviste o desenvolvedor.

O prompt de referência pede uma entrevista, uma pergunta por vez, sobre qualquer ambiguidade. Além disso, ele prioriza perguntas cuja resposta mudaria a arquitetura.

O critério de priorização é o que dá eficiência à técnica. Afinal, 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, e a engenharia de contexto perde o foco.

Referências de código na engenharia de contexto

Às vezes, o desenvolvedor não consegue descrever o que quer, por falta de vocabulário ou de tempo. Nesse caso, a recomendação é usar uma referência, e o guia define uma hierarquia entre os tipos possíveis.

Diagramas, documentação e imagens são aceitáveis, mas a melhor referência é o 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. Portanto, se existe uma biblioteca que implementa um comportamento da forma desejada, 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 do guia aponta um crate Rust com o backoff desejado e pede a mesma semântica em um cliente TypeScript.

Isso reposiciona a referência de código como transferência de semântica, e não como cópia de sintaxe. Na engenharia de contexto, uma pasta bem escolhida vale mais do que parágrafos de descrição.

Planos de implementação

Quando o desenvolvedor se considera pronto para implementar, a etapa recomendada é pedir um plano de implementação para revisão. O plano deve se concentrar nas partes com maior probabilidade de mudança.

Essas partes costumam ser 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 mudar.

O prompt citado pede que o plano seja escrito em HTML, começando pelas decisões mais sujeitas a ajuste. Já a refatoração mecânica fica no final, porque o desenvolvedor confia que o agente resolve essa parte sozinho.

Aqui, a estrutura do documento é uma decisão de engenharia. Ordenar por probabilidade de mudança, e não por ordem de execução, otimiza o plano para a revisão humana.

Notas de implementação durante a execução

Satisfeito com o plano, o autor abre uma nova sessão e passa os artefatos produzidos como entrada do prompt. Com isso, o modelo recebe uma janela de contexto limpa, mas com toda a informação compilada no planejamento.

Essa gestão deliberada da janela de contexto trata planejamento e implementação como fases distintas. Ainda assim, o guia admite que 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. Para mitigar isso, o autor pede ao Claude Code que mantenha um arquivo de notas de implementação, como um implementation-notes.md.

Além disso, o prompt define uma política para casos de borda. O agente escolhe a opção conservadora, registra o desvio e prossegue.

Assim, o agente não interrompe o trabalho a cada dúvida, mas também não esconde o desvio. O guia completo do Claude Code aprofunda o uso de sessões e arquivos.

Pós-implementação: pitches e explicadores

Entregar código é apenas parte do trabalho. Segundo o guia, obter adesão e aprovação é uma parte igualmente importante do processo de entrega.

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 alguém considerou os desconhecidos e os pontos comuns de falha.

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 das etapas anteriores. Ou seja, o método de engenharia de contexto é cumulativo por construção.

Quizzes como porta de merge

A última técnica é a mais incomum e possivelmente a mais valiosa em 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 uma compreensão superficial, porque grande parte do comportamento depende de caminhos de código já existentes. Por isso, a solução proposta é pedir ao Claude que aplique um questionário sobre a mudança.

O autor declara que só faz merge depois de acertar o quiz integralmente, aplicado ao fim de um relatório em HTML sobre as alterações.

Isso institui uma verificação de compreensão como critério de qualidade, ao lado dos testes automatizados. Afinal, 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.

Essa ideia complementa as evals para agentes de IA, com a diferença de que o quiz avalia o humano.

Estudo de caso: o vídeo de lançamento

O guia termina com o vídeo de lançamento do próprio Fable, editado com o Claude Code em um domínio que o autor não dominava. Esse caso mostra a engenharia de contexto aplicada fora do código.

Cada etapa endereça uma categoria diferente de desconhecido. No início, o autor sabia que o Claude podia usar código para editar e transcrever vídeos, mas não tinha certeza sobre a precisão.

Ele tratou esse conhecido desconhecido com uma explicação. Assim, 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 ele recorreu a um protótipo. O pedido foi criar um vídeo de demonstração com Remotion e uma transcrição para verificar se a ideia funcionava.

Por fim, veio o caso mais didático, um vídeo que parecia sem vida por causa do color grading. Pedir variações falhou, porque o autor não sabia como se parecia um bom resultado.

Então, 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 os próprios desconhecidos.

Essa é a lição operacional mais forte do guia. Pedir opções só funciona quando existe critério de julgamento, e, quando o critério não existe, a etapa anterior é construí-lo.

Como aplicar a engenharia de contexto no dia a dia

Reunidas, as técnicas formam um fluxo de trabalho com três fases. Antes do código, você faz a passagem de pontos cegos, os brainstorms, os protótipos, as entrevistas, as referências e o plano.

Durante o código, o agente mantém as notas de implementação e segue a política conservadora para desvios. Depois do código, você monta o explicador e responde ao quiz antes do merge.

Na prática, uma correção pequena dispensa a entrevista, enquanto uma migração em domínio novo pede o fluxo completo de engenharia de contexto. Por fim, o texto sobre as novas regras de engenharia de contexto para os modelos da geração Claude 5 complementa este método.

Conclusão: alinhar o mapa e o território

O fechamento do guia 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. Em vez disso, falta engenharia de contexto, seja na definição dos desconhecidos, seja em um plano que permita adaptação.

Cada técnica de engenharia de contexto é uma forma barata de descobrir o que você não sabia antes que a correção fique cara.

Para times que operam agentes em regime de autonomia prolongada, a implicação prática é clara. O investimento mais rentável em engenharia de contexto não está em prompts mais longos, e sim em rituais de descoberta anteriores à primeira linha de código.

FAQ

O que é uma blind spot pass?

É uma etapa de engenharia de contexto em que o modelo aponta os desconhecidos desconhecidos do desenvolvedor. O objetivo não é gerar código, mas produzir um prompt melhor para a fase seguinte.

Por que código-fonte é uma referência melhor que uma captura de tela?

Porque carrega uma 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.

A referência precisa estar na mesma linguagem do projeto?

Não. O guia cita o caso de um crate Rust usado como referência para reimplementar a mesma semântica de backoff em um cliente TypeScript.

Por que abrir uma nova sessão entre planejamento e implementação?

Para dar ao modelo uma janela de contexto limpa, mas com os artefatos compilados no planejamento. Isso evita arrastar todo o histórico exploratório para a execução.

Qual a função do arquivo de notas de implementação?

Registrar as decisões e os desvios do agente diante de casos de borda encontrados na execução. Ele serve como insumo para a tentativa seguinte e para o documento de apresentação final.

Por que usar um quiz antes do merge?

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 aprova.

Essas técnicas dependem do Claude Fable 5?

As técnicas independem do modelo, mas ganham relevância conforme cresce o horizonte de autonomia. Em sessões longas e com vários estágios, o custo de uma premissa não examinada cresce bastante.