Claude Sonnet 5.5 resolve projeto legado? O que muda com o novo modelo e o que continua com você

Fala aí, beleza? Vou começar sem rodeio: modelo novo não conserta repositório sem teste, sem documentação e sem padrão

A Anthropic lançou o Claude Sonnet 5.5 em 28 de setembro de 2026, o segundo modelo da família Claude 5.5 (o primeiro foi o Opus 5.5)

E aí quem mantém aquela base antiga, cheia de gambiarra, sem ninguém que lembre por que aquele if existe, já pensou: agora vai? haha

Será?

Bora ajustar a expectativa com base no que a Anthropic divulgou, separando onde o salto de versão ajuda de verdade e onde o gargalo continua sendo o seu próprio repositório 🙂

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O que a Anthropic lançou no Claude Sonnet 5.5?

O Sonnet 5.5 chega com um papel bem claro no posicionamento oficial: ser o complemento mais rápido e barato do Opus 5.5

Segundo a Anthropic, ele rende mais em tarefas do dia a dia bem delimitadas, correção de bugs e criação de documentos, slides e planilhas

Na API, o ID do modelo é claude-sonnet-5-5, e ele está disponível na Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry e Claude Platform on AWS

Os números oficiais, todos juntos:

O preço de entrada, saída e leitura de cache é o MESMO do Sonnet 5, ou seja, não teve aumento por token

E o benchmark de 70,6%?

No lançamento, a Anthropic divulgou o Terminal-Bench 4.0, um benchmark de código agêntico: o Sonnet 5.5 marcou 70,6% contra 10,3% do Sonnet 5

É um salto absurdo no papel 😀

Porém, tome cuidado: benchmark não é o seu repositório

Ele mede o modelo em tarefas controladas, não naquele módulo de faturamento escrito por três pessoas diferentes que já saíram da empresa xD

Onde o novo modelo ajuda de verdade em código antigo?

Aqui dá pra ligar cada caso de uso a algo que a Anthropic de fato divulgou, sem prometer milagre em nenhuma base específica

Correção de bug pontual e tarefa bem delimitada

Esse é o terreno onde o posicionamento oficial coloca o Sonnet 5.5: tarefa do dia a dia, com começo, meio e fim claros, e correção de bugs

Em legado, isso casa com aquele bug que você já sabe reproduzir e sabe em qual parte do sistema mora

Quanto mais fechado o escopo, mais o modelo joga no campo dele

Ler mais código de uma vez

Com janela de 1M de tokens, cabe MUITO mais contexto numa mesma sessão

Em base antiga isso pesa, porque a regra quase nunca está num arquivo só: está espalhada entre controller, helper, trigger de banco e por aí vai

Mais contexto não significa entender tudo sozinho, mas reduz aquele vai e volta de colar arquivo por arquivo

Documentar o que ninguém documentou

Criação de documentos também está no posicionamento oficial

No legado, isso vira um use case bem prático: pedir pra ele descrever o que um módulo faz, listar dependências, rascunhar um README que nunca existiu

Só lembra que ele documenta o que o código FAZ, não o que deveria fazer (a gente volta nisso já já)

Custo por tarefa menor sem mudar o preço por token

Segundo a Anthropic, o Sonnet 5.5 é mais de 30% mais rápido e custa até 30% menos por tarefa na maior parte do trabalho

E por quê, se o preço por token é o mesmo? Porque ele usa menos tokens pra fazer o mesmo trabalho

É dado da própria Anthropic, então vale conferir na sua conta, mas a lógica faz sentido: menos token gasto, conta menor no fim do mês

O que continua no seu colo: teste, documentação e padrão

Agora o coração do assunto

Trocar de modelo é como contratar um dev mais rápido e mais esperto, sentar ele na cadeira e virar as costas

Se a casa está bagunçada, ele vai trabalhar mais rápido… na bagunça

Sem teste, quem garante que a correção não quebrou outra coisa?

Ninguém

O modelo pode corrigir o bug do relatório e, de brinde, quebrar a exportação que usava a mesma função

Sem teste automatizado, você só descobre isso em produção, e aí já era

E código zoado feito pela IA no modo 100% vibe coder passa liso justamente quando não tem nada pra pegar o erro

Sem documentação, o modelo deduz regra de negócio

Que regra de negócio? Aquela que só existe na cabeça de quem escreveu, tipo: cliente antigo não paga taxa X porque teve um acordo em algum ano aí

Se isso não está escrito em lugar nenhum, o modelo vai DEDUZIR pelo código

E dedução em cima de gambiarra costuma dar ruim

Se o desafio é justamente lidar com um código que ninguém mais entende, o trabalho de mapear e explicar esse código continua sendo uma etapa à parte

Sem padrão, ele replica a inconsistência

Modelo aprende com o que vê no repositório

Se metade do projeto usa um jeito de acessar o banco e a outra metade usa outro, ele vai escolher um dos dois (ou inventar um terceiro haha)

Padrão é decisão humana, não dá pra terceirizar isso pro modelo

Tarefa bem delimitada exige que você saiba delimitar

O Sonnet 5.5 brilha em tarefa bem delimitada, beleza

Mas quem delimita é você

Se o pedido é refatora o módulo de pagamento todo, isso não é tarefa delimitada, é um projeto inteiro

Pra trabalho grande e ambíguo, o próprio posicionamento oficial aponta o Opus 5.5 como modelo principal, com o Sonnet 5.5 de complemento

Como preparar o repositório legado no Claude Code:

Antes de jogar qualquer modelo no legado, vale dar pra ele o mínimo de contexto sobre o projeto

No Claude Code, isso passa pelo CLAUDE.md, um arquivo markdown com instruções persistentes do projeto, lido no início de toda sessão

Se você conhece um README, pensa nele como um README escrito pro agente, não pra humano 🙂

Bora ver na prática?

1. Rode o /init dentro do projeto

O /init analisa o código e gera um CLAUDE.md inicial com comandos de build, instruções de teste e convenções que ele encontrou

Se o arquivo já existir, ele sugere melhorias em vez de sobrescrever, então não precisa ter medo de perder o que já tinha

/init

Erro comum deste passo: achar que o arquivo gerado substitui revisão humana

Ele só registra o que ENCONTROU no código, e em legado o código nem sempre reflete a regra certa

2. Revise e complete o CLAUDE.md

Como ele é lido no início de toda sessão, tudo que estiver ali vira contexto fixo pro modelo

Aqui entra o que o código não conta: regras de negócio, módulos que não pode mexer, convenções que vocês decidiram seguir daqui pra frente

Isso é context engineering na prática: dar o contexto certo antes de pedir qualquer coisa

Erro comum deste passo: deixar de fora justamente as regras de negócio que não aparecem no código

Tome cuidado: se a regra não está escrita, o modelo faz exatamente o que o código sugere, mesmo que isso esteja errado pro negócio

3. Importe a documentação que já existe

Tem doc perdida numa pasta? O CLAUDE.md pode importar outros arquivos com a sintaxe @caminho/do/arquivo

Exemplo (o caminho aqui é só ilustrativo, use o do seu projeto):

@docs/regras-de-negocio.md

Erro comum deste passo: copiar e colar o conteúdo dentro do CLAUDE.md em vez de importar

Aí você fica com duas versões da mesma informação, e uma delas vai desatualizar

Antes de trocar o modelo: alias, migração na API e fallback

Cada produto tem a sua particularidade, então separei por onde você usa

No Claude Code: o alias sonnet

A partir da versão v2.1.284, o alias sonnet aponta para o Sonnet 5.5 quando você usa a API da Anthropic

No Bedrock, no Google Cloud e no Claude Platform on AWS, o alias continua apontando para modelos anteriores

Ou seja: dependendo do provedor, você pode achar que está no 5.5 e não estar, se liga nisso!

Na API: migrar não é só trocar o ID

Trocar o nome do modelo pra claude-sonnet-5-5 e sair rodando é receita pra dor de cabeça

Existe um guia oficial de migração que lista configurações de requisição que o Sonnet 5.5 rejeita com erro 400, uma nova forma de desligar o thinking e mudanças que falham sem avisar

Essas silenciosas são as piores, porque nada quebra na hora… só o resultado muda

Não vou listar aqui quais parâmetros quebram, então vai direto no guia antes de mexer em produção

Outro detalhe: o adaptive thinking vem ligado por padrão no Sonnet 5.5, e a configuração mínima é between_tools, que desliga o raciocínio antes da resposta

No app Claude: o fallback para o Sonnet 5

No app Claude, as checagens de segurança do Sonnet 5.5 leem memória, conectores, resultados da web e arquivos

Quando um fallback dispara, a conversa é refeita no Sonnet 5 e continua nele até o fim

E isso pode acontecer por conteúdo que você nem digitou, tipo um arquivo anexado ou algo que veio de um conector

Então se a resposta mudar de qualidade no meio da conversa, já sabe onde olhar

Vale usar o Sonnet 5.5 no seu legado?

Vale testar, sim, mas com a expectativa no lugar certo

O salto de versão traz mais velocidade, custo por tarefa menor (segundo a Anthropic) e janela de 1M de tokens pra ler mais código de uma vez

Porém o resultado depende do que o repositório oferece ao modelo: teste pra validar, documentação pra explicar a regra e padrão pra ele seguir

O próximo passo concreto é simples: roda o /init, revisa o CLAUDE.md com as regras que só você conhece e começa por um bug bem delimitado e coberto por teste

Deu certo? Aí sim vale subir a régua pra tarefas maiores, e deixar refatoração grande pra depois

E tu, já vai colocar o Sonnet 5.5 no legado ou vai esperar mais relatos? Bora trocar uma ideia 😀

Até o próximo post!