🧭 A Virada: modelos que operam na intenção

Durante três anos a receita foi a mesma: modelo erra, você escreve mais uma regra. "Sempre rode os testes." "Leia a documentação antes de mudar qualquer coisa." "Peça permissão a cada passo." Cada linha nasceu de uma falha real de um modelo mais fraco. Em setembro de 2026 essa receita virou de cabeça para baixo: as duas gerações novas seguem instrução tão bem que obedecem às muletas — e as muletas passaram a custar qualidade.

Claude Fable 5.1 (Anthropic, 1/set/2026). Mesmo modelo do Mythos 5.1, com salvaguardas diferentes. Foi feito para trabalho longo e autônomo: sustenta tarefas de horas ou dias, mantém registros próprios, reprioriza e retoma de onde parou. O guia oficial de prompting do Fable 5 diz, textualmente, que skills feitas para modelos anteriores "são prescritivas demais e podem degradar a qualidade da saída". A 5.1 ficou ~25% mais barata em uso típico e até 45% em trabalho agêntico, e em esforço médio entrega o que a Fable 5 entregava em esforço alto.

GPT-6 Astra (OpenAI, prévia 3/set, público 4/set/2026). Ganhos grandes em uso de computador, código, ciência e contexto longo. Comportamento novo que pega todo mundo de surpresa: ele pergunta mais antes de agir e formata tudo em listas. Um prompt que só descreve a tarefa costuma voltar com uma pergunta e um resumo em vez do trabalho feito. Segundo a orientação da própria OpenAI (citada pelos guias que lemos), o antídoto é dizer ao modelo para inferir a intenção a partir do contexto e persistir até o objetivo estar completo — e deixar claro que reconhecer que poderia fazer não é o mesmo que ter feito.

Repare no padrão. Os dois erros são opostos (um age além do pedido, o outro para cedo demais), mas a causa é a mesma: o modelo está obedecendo ao que você escreveu, não ao que você queria. Se o seu texto ainda descreve passos, ele executa passos. Se descreve fronteiras rígidas, ele para na fronteira. O que falta não é mais instrução — é a intenção escrita de um jeito que o modelo consiga completar sozinho.

Em 5/set/2026 a equipe de experiência do desenvolvedor do Codex, na OpenAI, publicou um guia dizendo aos próprios usuários para "parar de superengenheirar os prompts": skills, arquivos de instrução e pedidos de tarefa acumularam "gordura — o apoio que um modelo fraco precisava e um forte não precisa". Do lado da Anthropic, a recomendação é a mesma com outras palavras: revise as instruções antigas e remova o que o comportamento padrão já faz melhor.

Para este curso a notícia é boa. Os 5 pilares do dia 2 não caem — eles mudam de forma. Contexto vira fonte de verdade (o que é autoritativo, não tudo que você sabe). Objetivos viram resultado + definição de pronto. Regras viram fronteiras de autoridade (o que decide sozinho, onde para). Memória vira arquivo de lições que o modelo lê e escreve. Validação vira verificação com evidência antes de declarar concluído. É isso que vamos montar hoje.

Um aviso honesto: tudo isso tem data. Os dois modelos têm menos de uma semana de rua enquanto escrevemos e o comportamento ainda está sendo medido. O que não muda é o método: a cada troca de geração, você reaudita o que escreveu. Este dia ensina o método com os fatos de set/2026 como caso.

Escrever para a nova geração é, antes de tudo, um exercício de apagar. Não porque instrução deixou de importar, mas porque cada linha agora é levada a sério. Uma linha inútil não é mais ignorada — é obedecida, e ocupa o lugar de uma linha que importava.

O critério de corte é uma pergunta só, feita linha a linha: "o modelo que eu uso hoje ainda precisa disso?" Se a linha existe porque um modelo de 2024 esquecia de rodar teste, e o de 2026 roda sem pedir, ela sai. Se existe porque a ação é de fato perigosa (apagar dados, publicar em produção, gastar dinheiro), ela fica — e ganha o nome certo: fronteira, não passo.

Os alvos mais comuns de corte, segundo os guias das duas casas: (1) rituais obrigatórios ("leia toda a documentação antes de qualquer mudança"); (2) lembretes do óbvio ("rode os testes", "não invente"); (3) "peça permissão" genérico, criado depois de um susto com modelo antigo; (4) regras de formatação em ambos os sentidos — a Fable 5.1 já usa menos negrito e lista do que as anteriores, então "nunca use bullets" hoje remove estrutura que faria falta; (5) "mostre seu raciocínio" — na Fable isso pode até disparar uma recusa por extração de raciocínio; se você precisa ver o progresso, peça atualizações de progresso, não a transcrição do pensamento.

Skills e arquivos de instrução do projeto (CLAUDE.md, AGENTS.md) sofrem do mesmo mal, com um agravante: eles são globais. Uma linha ruim ali contamina toda tarefa. A recomendação do guia do Codex é direta: descrições de skill curtas e com um gatilho específico ("use ao revisar um arquivo de migração de banco — não para consultas em geral") em vez de "use sempre que houver algo relacionado a banco de dados". Skills que se sobrepõem se consolidam; skills que despejam o fluxo inteiro viram roteador com o detalhe em arquivo separado.

Subtrair não é ficar sem nada. A regra do guia da Fable é: uma instrução curta de intenção substitui a lista de comportamentos. Em vez de enumerar "não faça PR longo, não comente linha por linha, não liste opções que não vai seguir", escreve-se uma frase: "Comece pelo resultado; detalhe e justificativa vêm depois; para encurtar, corte o que não muda a decisão do leitor, não comprima em fragmentos." O modelo generaliza.

E o que entra no lugar do que saiu? Permissões explícitas para fluxos seguros e repetíveis. "Os testes locais usam dados descartáveis e não tocam produção: rode-os, corrija o que a mudança quebrou e re-rode sem pedir aprovação a cada passo." Isso é o oposto da muleta: em vez de frear, libera — dentro de uma cerca que você desenhou.

Um detalhe que muda o jeito de testar: as duas casas dizem que o mesmo prompt se comporta diferente em cada nível de esforço e em cada geração. Então a auditoria não termina no corte — termina rodando o caso real depois do corte e comparando com antes. Subtração sem re-rodar é palpite.

No dia 2 o pilar Regras respondia "o que a IA não pode fazer". Na nova geração ele responde uma pergunta mais fina: até onde ela decide sozinha, e em que situação exata ela para e te chama. É o pilar Autoridade. Errar para menos trava o trabalho; errar para mais gera ação que ninguém pediu.

Os dois modelos novos mostram os dois lados do erro. A Fable, segundo o guia oficial, "pode ocasionalmente tomar ações não pedidas" — rascunhar um e-mail que ninguém pediu, criar um backup por precaução, consertar um bug vizinho que a tarefa não mencionava. O Astra faz o oposto: "leva suas fronteiras a sério e pode parar onde você preferiria que continuasse", na descrição da equipe do Codex. Uma cerca escrita para corrigir um modelo desobediente vira, num modelo obediente, uma parada indesejada.

A saída não é apagar fronteiras nem multiplicá-las: é reescopar. O guia da Fable resume em uma frase o que um prompt de 2025 fazia em vinte: "Pare para o usuário só quando o trabalho exigir de verdade: uma ação destrutiva ou irreversível, uma mudança real de escopo, ou uma informação que só ele tem. Se bater numa dessas, pergunte e encerre o turno, em vez de encerrar com uma promessa." São as três paradas. Tudo que não é uma delas — ações reversíveis que decorrem do pedido — segue sem perguntar.

Para o lado do Astra, a instrução espelhada: "infira a intenção a partir do que já tem, liste suas suposições no topo e siga com base nelas". Repare que não é "nunca pergunte" — isso força um chute onde uma decisão real falta. É redirecionar a pergunta: em vez de parar, o modelo declara o que assumiu e continua. Você mantém a visibilidade sem o travamento. Os guias sugerem ainda deixar explícito que ações de leitura, revisão e as reversíveis já carregam autorização implícita.

Para o lado da Fable, a cerca contra o excesso, também do guia oficial: "Se, ao trabalhar, encontrar um bug pré-existente ou um comportamento que a tarefa não menciona, não conserte nem estenda nesta mudança; reporte como pendência no resumo. Onde a tarefa for ambígua, implemente a leitura que o texto mais apoia, declare a suposição e não construa para as outras leituras." E a distinção que vale ouro em operação: quando o usuário está descrevendo um problema ou pensando alto, o entregável é a avaliação — reporte e pare; não aplique a correção antes de ser pedida.

Há um segundo motivo para escrever fronteiras com cuidado, e ele é de segurança. Uma leitura de terceiros que circulou nesta semana resume bem: "um prompt representa intenção; uma permissão representa imposição". Quanto mais forte o modelo, mais fraco "o prompt mandou não fazer" como controle. Fronteira de alto risco (deploy, apagar, pagar) precisa existir também fora do texto — na permissão da ferramenta, no acesso, no ambiente. O prompt diz onde parar; o ambiente garante.

O teste do pilar Autoridade é simples: leia sua lista de regras e classifique cada uma em parada (uma das três), permissão (fluxo seguro liberado) ou muleta (regra que existe por causa de um modelo antigo). A primeira fica e ganha garantia no ambiente. A segunda fica e libera. A terceira sai.

Se o modelo cuida do "como", a parte mais valiosa do seu texto passa a ser a linha de chegada. Um guia sobre o Astra resume: "o melhor prompt define uma linha de chegada — diz que resultado produzir, que evidência controla a resposta, o que ele pode decidir sozinho, como o entregável se estrutura e o que deve ser conferido antes de concluir". As duas últimas partes — pronto e verificação — são o que separa um prompt que devolve trabalho de um que devolve uma pergunta.

Definição de pronto é o teste que você aplicaria antes de aceitar. Não é "um bom relatório"; é "totais batem com a planilha, variação contra a semana anterior, três itens com ação". Escrita assim, ela faz três coisas ao mesmo tempo: dá ao modelo o critério para saber quando parar, impede que ele pare cedo (Astra) ou continue além (Fable), e vira a checklist de validação do dia 3 sem trabalho extra.

Verificação com evidência ataca um problema que ficou mais visível justamente porque os modelos agora rodam por horas: o relatório de progresso inventado. O guia da Fable traz a instrução que, nos testes da Anthropic, "praticamente eliminou" isso: "Antes de reportar progresso, audite cada afirmação contra um resultado de ferramenta desta sessão. Só reporte trabalho para o qual você consegue apontar evidência; se algo ainda não foi verificado, diga isso explicitamente. Se os testes falharam, diga com a saída; se um passo foi pulado, diga; quando algo está feito e verificado, afirme sem hedge."

Há um par de armadilhas novas. A primeira, do lado do Astra: reconhecer que poderia fazer não é ter feito. Sem isso escrito, ele às vezes responde com um plano competente e para. A segunda, do lado da Fable 5.1: em tarefas longas e assíncronas, ela pode encerrar o turno descrevendo o próximo passo ("em seguida vou…") ou pedindo permissão para algo que o pedido já cobria ("aplico?"). O guia oficial dá a frase de fechamento: "Antes de encerrar, releia seu último parágrafo. Se for um plano, uma pergunta ou uma promessa sobre trabalho não feito, faça esse trabalho agora." Isso não vale para trabalho em dupla ao vivo — vale para quando você não está olhando.

Verificação melhor ainda é a que não é feita por quem produziu. O guia da Fable é explícito: "verificadores separados, com contexto limpo, tendem a superar a autocrítica". Em trabalho longo, a instrução é montar um ritmo: "Estabeleça um método para conferir seu próprio trabalho a cada [intervalo]; rode-o verificando contra a especificação com subagentes." Para quem não usa subagente, o equivalente é o dia 3: outra pessoa ou outra sessão roda a checklist.

Junte as peças e você tem a estrutura que os guias do Astra chamam de prompt de seis partes, e que é, na prática, a nossa Ficha do dia 2 atualizada: Resultado · Fonte de verdade · Restrições · Autoridade · Contrato de saída · Verificação. "Resultado" evita análise sem rumo; "fonte de verdade" controla a evidência; "restrições" delimitam a solução; "autoridade" reduz paradas desnecessárias; "contrato de saída" torna o resultado usável; "verificação" define pronto.

Uma nota sobre fontes que vale para qualquer coisa que use busca: a Fable 5.1 em esforço baixo tende a responder de memória em vez de buscar. Quando o assunto muda rápido (modelos de IA são o exemplo do próprio guia), diga que reconhecer um nome não é saber seu estado atual e que ele deve buscar antes de responder. É uma definição de pronto para pesquisa: pronto inclui ter conferido.

Quando o modelo cuida do "como", sobram três botões que você ainda controla e que a geração anterior não tinha do mesmo jeito: quanto ele pensa (esforço), o que ele lembra entre rodadas (memória em arquivo) e como ele te mantém informado em trabalho que dura horas. Os três substituem um monte de instrução antiga.

Esforço é o controle principal. As duas casas usam a mesma escala de cinco níveis — baixo, médio, alto, extra-alto e máximo — e dizem a mesma coisa: é o botão que troca inteligência por latência e custo. Na Fable 5.1 o padrão é alto (no Claude Code) ou médio (no chat), e em médio ela entrega o que a Fable 5 entregava em alto, mais barato. Em baixo, compete em custo com modelos menores e pontua mais. O guia manda re-testar a escala a cada geração: o mesmo nome de nível não significa a mesma quantidade de pensamento entre modelos. Regra de bolso dos guias do Astra: extração e formatação em baixo; redação e mudança de rotina em médio; multiarquivo e análise longa em alto; refatoração ampla em extra-alto; decisão de arquitetura que você vai executar em máximo.

Esforço alto tem efeito colateral conhecido: em tarefa rotineira, a Fable "pode coletar contexto e deliberar além do que a tarefa precisa" e ficar tentada a arrumar o que ninguém pediu. A frase do guia que segura isso substitui dez regras: "Não adicione funcionalidades, refatore ou introduza abstrações além do que a tarefa exige. Faça a coisa mais simples que funcione bem." Se a tarefa termina mas demora demais, baixe o esforço antes de mexer no prompt.

Memória vira arquivo — e o modelo escreve nele. O pilar Memória do dia 2 era o que você guardava para a IA ler. Agora a Fable "se sai particularmente bem quando pode registrar lições de rodadas anteriores e consultá-las". A instrução oficial cabe em três linhas: "Guarde uma lição por arquivo com um resumo de uma linha no topo. Registre correções e abordagens confirmadas, incluindo por que importaram. Não guarde o que o repositório ou o histórico já registram; atualize a nota existente em vez de duplicar; apague notas que se mostrarem erradas." E para começar: "Reflita sobre nossas sessões anteriores, identifique temas e lições e guarde em [pasta]." É o plano de melhoria contínua do dia 3, só que quem escreve o log é o sistema.

Trabalho longo pede ritmo, não vigilância. A Fable 5.1 escreve menos atualizações durante rodadas longas do que a Fable 5 — o usuário vê o agente sumir por minutos. O guia manda primeiro apagar linhas antigas que suprimiam narração ("guarde tudo para a resposta final") e só então pedir: "Antes de começar, diga em uma linha o que vai fazer; atualizações breves enquanto trabalha; feche com um resumo que se sustente sozinho." Para agentes que rodam sem ninguém olhando, existe ainda a ferramenta de "enviar ao usuário", que entrega uma mensagem intacta no meio da rodada — mas o modelo raramente a usa se o prompt não mandar.

Delegação virou padrão. A Fable despacha subagentes em paralelo com mais facilidade que as anteriores; o guia recomenda usá-los com frequência, dizer quando delegar é apropriado e preferir comunicação assíncrona — o orquestrador continua trabalhando enquanto eles rodam e intervém se um sair do rumo. Para você, que talvez não monte agente nenhum, a lição é a mesma do dia 3: quebre o sistema em etapas que possam rodar em paralelo e separe quem produz de quem verifica.

Por fim, o dinheiro. A 5.1 reduziu o preço de leitura de cache, e é isso que faz trabalho longo custar até 45% menos. Consequência prática citada no próprio guia: compactar o histórico cedo para economizar "pode não ser mais a troca certa" — experimente compactar mais tarde. E o velho conselho do curso continua: o esforço certo para a tarefa é o mais baixo que passa na definição de pronto. Rode em dois níveis e compare contra o pronto; isso diz mais sobre o seu caso do que qualquer benchmark.

Você saiu do dia 3 com uma Ficha do Sistema rodada e validada. Hoje ela não vai para o lixo: vai migrar. Cada pilar da Ficha v1 tem um lugar na Ficha de Intenção v2, e a migração é justamente o exercício que mostra o que era muleta, o que era fronteira e o que faltava. No fim, você roda o mesmo caso real nos dois formatos e compara — essa comparação é a sua prova de que entendeu a virada.

Passo 1 — Audite por subtração. Pegue a Ficha v1 e o prompt/documento que roda o sistema. Linha a linha: "o modelo de hoje ainda precisa disso?" Marque muleta, fronteira ou permissão. Apague as muletas. Anote quantas linhas saíram — é o seu número de dívida paga.

Passo 2 — Reescreva Contexto como Fonte de verdade. Do contexto do dia 2, separe o que é autoritativo (o catálogo, a tabela de prazos, a política) do que era só descrição. Diga qual fonte manda quando houver conflito e o que fazer quando faltar dado: marcar a divergência, não inventar.

Passo 3 — Transforme Regras em Autoridade. Escreva o que o sistema decide sozinho, as três paradas com exemplos do seu caso, e os limites fixos que sobraram. Para cada parada de alto risco, anote onde ela é garantida fora do texto (acesso, permissão, ambiente).

Passo 4 — Escreva Pronto e Verificação. Sua checklist de validação do dia 3 vira a definição de pronto: o teste que você aplica antes de aceitar. Acrescente a exigência de evidência ("só reporte o que consegue apontar; o não verificado, diga que não verificou") e quem verifica separado de quem produz.

Passo 5 — Ajuste Esforço e instale a pasta de lições. Escolha o nível de esforço por tipo de caso (rotina em médio, parada em alto, por exemplo). Crie a pasta de lições com a regra de entrada, atualização e descarte, e coloque nela o primeiro furo corrigido no dia 3.

Passo 6 — Rode o mesmo caso nos dois formatos e compare. Pegue o caso real do dia 3. Rode com a Ficha v1 e com a v2, de preferência no mesmo modelo e, se puder, em dois modelos (um da Anthropic, um da OpenAI). Anote: perguntou ou fez? Parou onde devia? Passou no pronto? Quantas linhas de instrução usou? Essa tabela de comparação, junto com a Ficha v2 preenchida, é a sua entrega do dia 4.