Modelo novo, comportamento novo: trate a troca como uma migração

O fornecedor anuncia um modelo novo. O modelo que você usa ganha data de saída. Entre um aviso e outro, aparece um seletor na interface e a troca parece tão simples quanto mudar uma configuração.

A API continua aceitando mensagens. A resposta continua sendo texto. Talvez os testes unitários até passem. Dias depois, porém, o agente começa a chamar ferramentas em outra ordem, ignora uma etapa de validação ou gasta mais para resolver a mesma issue.

É aí que a falsa simplicidade do seletor cobra a conta.

No ecossistema do GitHub Copilot, por exemplo, o anúncio da chegada do Gemini 3.7 Flash veio no mesmo período em que outros modelos receberam uma data de depreciação. O Copilot cloud agent também passou a permitir a escolha do nível de raciocínio por execução, com impacto possível no consumo de tokens ou créditos. São mudanças diferentes, mas apontam para o mesmo cuidado operacional: modelo e esforço fazem parte da rota de execução do produto.

Trocar essa rota exige o mesmo cuidado que uma migração de dependência importante. Não precisa virar um projeto de três meses. Precisa ser pequena, observável e reversível.

O seletor esconde uma dependência de comportamento

Duas opções compatíveis com a mesma API não são, necessariamente, equivalentes no seu workflow. A troca pode alterar:

como o agente interpreta uma instrução ambígua;
quando ele decide chamar uma ferramenta;
o formato e a consistência da saída estruturada;
a quantidade de tentativas até concluir uma tarefa;
a latência e o custo da execução;
o ponto em que ele considera o trabalho encerrado.

Essa diferença importa pouco em uma conversa casual. Importa bastante quando o modelo edita código, usa credenciais, abre um pull request ou chama um serviço externo.

Fixar a rota atual traz alguma estabilidade, mas não elimina a migração. Só adia o momento. Se o fornecedor já definiu uma data de depreciação, esperar até a última semana reduz justamente o que você mais precisa para trocar com segurança: tempo para comparar o comportamento.

Atualizar automaticamente resolve o problema oposto. Você recebe novidades sem esforço manual, mas aceita mudanças antes de entender como elas afetam o seu fluxo. Para um agente em produção, nenhuma das duas escolhas funciona bem sozinha. É melhor ter uma política explícita de versão, avaliação e promoção.

Escreva o contrato antes de escolher o candidato

Comparar modelos por uma resposta isolada quase sempre favorece o texto mais convincente. O produto, no entanto, depende do fluxo completo.

Antes de testar o candidato, descreva o comportamento que precisa sobreviver à troca. Use poucos casos reais e declare o que será observado em cada um. Um contrato enxuto pode registrar:

rota: corrigir-bug-frontend
entrada:
  - issue com passos de reprodução
  - repositório em uma branch isolada
saída_obrigatória:
  - arquivos alterados
  - resumo curto da causa
  - testes executados
ferramentas_permitidas:
  - leitura e edição do repositório
  - terminal com comandos aprovados
  - navegador de teste
limites:
  tentativas: 3
  custo_por_execução: definido_pelo_time
condições_de_parada:
  - pedir contexto se a reprodução falhar
  - parar antes de qualquer deploy
validação:
  - testes automatizados
  - console sem erro novo
  - critérios da issue reproduzidos no navegador

Esse arquivo não precisa virar uma especificação universal. Ele só precisa expor o que hoje está escondido no prompt, no código ou na cabeça de quem montou o agente.

Também vale evitar um contrato que descreve o comportamento do modelo atual em vez da necessidade do produto. “Responder com o mesmo estilo e o mesmo número de passos” pode congelar uma peculiaridade sem valor. “Entregar JSON válido, executar os testes aprovados e preservar o estado de erro do formulário” define algo que o usuário realmente percebe.

Tire modelo e esforço da regra de negócio

Se o identificador do modelo aparece espalhado por handlers, jobs e scripts, cada migração vira uma caça ao texto. O risco não está apenas em esquecer um ponto. Rotas diferentes podem acabar usando versões distintas sem que isso seja intencional.

Concentre a decisão em uma configuração versionada:

rotas:
  corrigir-bug-frontend:
    modelo: modelo-atual
    esforco: medio
    fallback: modelo-anterior
  revisar-pull-request:
    modelo: modelo-atual
    esforco: alto
    fallback: desabilitado

O formato é menos importante que a separação. A regra de negócio pede “corrija este bug com estes limites”; a camada de roteamento decide qual modelo e qual nível de esforço executam a tarefa.

Essa camada também deve registrar a rota que foi usada de verdade. Um log útil inclui modelo, configuração de esforço, versão do prompt, ferramentas liberadas, duração, custo, resultado da validação e motivo de fallback.

Sem isso, o fallback vira uma fonte de confusão. A tarefa termina, mas ninguém sabe que ela passou pelo modelo de reserva. A disponibilidade parece boa enquanto uma regressão fica escondida nos bastidores.

Fallback explícito não significa anunciar detalhes técnicos ao usuário em toda resposta. Significa deixar a substituição visível para quem opera e avalia o sistema.

Uma migração curta em seis passos

Você não precisa reproduzir toda a produção. Uma amostra pequena, escolhida a partir de falhas e tarefas frequentes, costuma revelar mais que um benchmark genérico.

Inventarie a rota atual. Localize identificadores de modelo, níveis de esforço, fallbacks, prompts, limites de custo e ferramentas disponíveis.
Salve um baseline. Execute os casos representativos com a configuração atual e guarde saídas, validações, latência, custo e falhas.
Rode o candidato nas mesmas condições. Se possível, use execução em sombra ou uma branch descartável para impedir efeitos externos.
Revise diferenças, não só acertos. Observe chamadas de ferramenta, tentativas extras, omissões, formato de saída e condições de parada.
Libere para uma amostra pequena. Comece por tarefas reversíveis e acompanhe a rota usada em cada execução.
Mantenha o rollback por um prazo definido. Preserve a configuração anterior enquanto o novo caminho ganha volume suficiente para revelar regressões menos óbvias.

Rodar duas rotas custa mais tokens e créditos. É um custo temporário para obter evidências antes da virada. Se o orçamento for apertado, reduza a quantidade de casos, não a qualidade dos critérios. Três tarefas bem escolhidas são mais úteis que cinquenta prompts genéricos.

Exemplo: um agente que corrige bugs de frontend

Imagine um agente interno que recebe issues pequenas. A rota atual altera o código, executa os testes e valida o fluxo no navegador. Para avaliar um novo modelo, o time separa três casos:

um formulário que precisa preservar os dados depois de um erro da API;
uma tela que quebra em largura de celular;
um componente que perdeu o nome acessível após uma refatoração.

O candidato pode produzir um diff elegante e ainda reprovar. Se limpar o formulário depois do erro, corrigir apenas o viewport usado no teste ou ignorar a regressão de acessibilidade, o comportamento importante não foi preservado.

A avaliação deveria comparar pelo menos quatro tipos de evidência:

o diff e os arquivos tocados;
o resultado dos testes;
erros novos no console;
a reprodução dos critérios no navegador.

Suponha que o candidato acerte o código, mas pare antes da validação visual. Isso não prova que o modelo seja ruim. A causa pode estar no prompt, no nível de esforço, na ferramenta disponível ou no limite de tentativas. Como o contrato separa essas partes, o time consegue ajustar uma variável por vez em vez de escolher outra opção no seletor e torcer.

Esse detalhe evita uma armadilha comum: transformar toda falha em comparação de inteligência. Às vezes, o modelo tinha capacidade para concluir a tarefa, mas a rota não lhe deu tempo, permissão ou um critério de parada adequado.

Rollback de configuração não desfaz o mundo

Voltar ao identificador anterior é simples quando o roteamento está isolado. Isso restaura a configuração para as próximas execuções. Não apaga uma mensagem enviada, não reverte automaticamente um deploy e não desfaz uma gravação feita em um serviço externo.

Por isso, a primeira fase da migração deve privilegiar tarefas reversíveis. Para ações externas, use aprovação humana, idempotência, modo de simulação ou uma operação compensatória quando o sistema oferecer esse caminho.

O rollback precisa responder a duas perguntas diferentes:

como voltar a executar tarefas com a rota anterior;
como tratar os efeitos que a rota nova já produziu.

Misturar as duas dá uma sensação de segurança que não existe.

O que revisar antes da troca

Uma última checagem ajuda a evitar a migração feita no impulso:

onde o modelo atual está configurado?
quais tarefas representam o uso real?
quais saídas e ferramentas fazem parte do contrato?
existe um teto de custo e uma condição clara de parada?
a telemetria mostra modelo, esforço e fallback usados?
o candidato foi testado sem receber a fila inteira?
há um prazo para manter a rota anterior disponível?
efeitos externos exigem aprovação ou compensação?

Modelos vão entrar, melhorar, mudar de disponibilidade e sair de catálogo. Tentar impedir esse ciclo só torna a próxima troca mais urgente.

A saída mais prática é fazer do modelo uma dependência substituível e do comportamento um contrato verificável. Assim, o nome no seletor pode mudar sem transformar cada novidade ou depreciação em uma aposta na produção.