Migração é a tarefa que eu mais procrastino. Esta veio com encrypt, decrypt e teste de segurança no meu próprio sistema — exatamente o que o safeguard do modelo travava. Testei o 5.1 no meio do serviço quente e conto o que mudou.
Resposta rápida: no Fable 5.1, manipular criptografia parou de derrubar a sessão pro modelo anterior. Antes, cada encrypt/decrypt ou migração de senha batia no safeguard, o modelo trocava sozinho e eu tinha que ficar na frente do computador o tempo todo. Agora a migração — mais de 3 TB e milhares de contas de e-mail de clientes — roda e me manda relatório, que eu confiro pelo celular. Tentativa de ataque ao próprio sistema ainda esbarra no safeguard, mas bem menos: caiu uma única vez.
O caso, em números:
Este artigo é a versão escrita do vídeo publicado no canal em 4 de setembro de 2026 — gravado como todos os outros: sem corte, por quem cuida de datacenter e tem o "trem em produção, pau quebrando". Assista e leia junto:
8 minutos, sem edição — do canal @josimarjmv. Se preferir o texto, a tradução completa está abaixo.
No vídeo anterior eu já tinha reclamado do safeguard — o modelo é excelente, mas eu passava raiva. Os casos que ele barrava eram sempre os mesmos, e todos legítimos:
Validação de segurança no meu próprio sistema. Testar a casa por dentro, no ambiente que é meu.
Tentativa de ataque controlada. Atacar o próprio sistema pra saber onde ele cede — rotina de quem opera infraestrutura, não travessura.
Encrypt e decrypt. Migração de senhas, migração de sistema legado pra sistema novo: manipular coisa criptografada de um lado pro outro é o feijão com arroz de qualquer migração.
O efeito prático não era só um "não posso ajudar". Quando batia no safeguard, a sessão trocava de modelo sozinha — e caía no modelo anterior, o Opus 4.8, que não faz o que eu preciso. Nem pro Opus 5 ia. Resultado: eu tinha que ficar plantado na frente do computador, monitorando o tempo todo, pra reconduzir o trabalho a cada queda.
A alternativa seria montar um harness — camada minha em volta do modelo pra contornar isso. Não fiz e não vou fazer. Uso o modelo top e acabou: gasto um pouco mais, e esse gasto maior me devolve o recurso que é escasso de verdade, que é tempo.
Quando saiu o 5.1, eu estava com a migração andando. Trocar de modelo no meio do processo é chato — perde-se todo o contexto, a sessão começa do zero. Mesmo assim troquei, porque a promessa do comunicado era exatamente sobre o que estava me atrapalhando: soltaram as rédeas do bichão. Não é acesso irrestrito, mas melhorou demais.
O que eu observei rodando o mesmo processo que já estava rodando antes:
Criptografia: liberou. Manipular dado criptografado de lá pra cá parou de derrubar a sessão. Esse era o meu gargalo, e ele sumiu.
Ataque: ainda bate, bem menos. Na hora de fazer a tentativa de ataque o safeguard apareceu — mas em todo o processo a sessão caiu pro modelo anterior uma vez só.
Erros menores. O modelo continua errando, como todo modelo erra. Só que os erros vêm ficando cada vez menores.
Uma ressalva honesta: eu disse no vídeo passado que testaria o Codex nas mesmas regras e não deu tempo. Não testei, e talvez nem teste — meu processo já está terminando. Então isto aqui não é comparativo de ferramenta; é caso de uso real de uma, na minha operação.
O que estava em jogo: mover mais de 3 TB e milhares de contas de e-mail de clientes pro sistema de e-mail novo que a gente criou aqui dentro. Um sistema que responde a comando por áudio — eu falo "faz o e-mail pro Yuri avisando que quinta, dia 2 de setembro, é dia de gravação, e a gente começa às 7 da manhã"; ele seleciona o contato, cria o assunto, escreve o e-mail, eu dou a conferida e mando enviar. Ficou lindo demais.
Quanto tempo levou pra ficar pronto e entrar em produção? Três meses. E aqui vai a parte que costuma ser omitida na comparação: eu já tinha conhecimento prévio de como e-mail funciona, de validação, de tudo que sustenta isso. Não peguei um SaaS do zero. Se você é vibe coder e está mirando produção, guarde essa diferença.
O ganho concreto do 5.1 nessa história é operacional: a migração roda e me manda o relatório por automação, e eu acompanho pelo telefone, conferindo contra o meu pipeline. É um processo mais ou menos fechado, com suas nuances, mas fechado o bastante pra ele ir desembolando sozinho. Antes eu não conseguia — cada queda de modelo me trazia de volta pra cadeira.
Essa migração é um pedaço de uma coisa maior, que é a parte que quase ninguém mostra: subir software pra produção quando existe usuário do outro lado. Aqui o caminho de uma funcionalidade é mais ou menos este:
Desenvolve e volta. Sai do desenvolvimento, o time testa, a gente valida o código. Tive uma tarefa complexa que voltou cinco vezes nesse ciclo — e isso é normal.
Testes, QA e staging. Passou nos testes, vai pro QA validar de novo; depois valida em ambiente de staging.
Pré-produção e liberação parcial. Depois pré-produção e, muitas vezes, 10% ou 20% da funcionalidade em produção pra sentir o comportamento antes de soltar geral.
Trocar o pod é o último passo e o mais fácil. Se você não tem usuário, tudo bem — vai lá e troca. Se você tem, o cenário muda bastante. É por isso que eu insisto: deploy não é apertar um botão. Teve um comentário no canal dizendo que o DevOps, com deploy automático na nuvem, acabou com o pessoal de infraestrutura. É o contrário: quem coordena é quem entende de infraestrutura, quem sabe escovar bit.
Quer aprender a botar o seu SaaS em produção de verdade? Abrimos a quarta imersão: Imersão de SaaS — presencial em São Paulo, 3 dias (sexta, sábado e domingo), investimento de R$ 3.700, com pré-inscrição pela lista de espera. É pipeline, deploy, infraestrutura e uso de IA no processo, do jeito que a gente faz aqui. Se o seu caminho é a infraestrutura por baixo ou chatbot em produção, tem imersão pra isso também. Veja as quatro imersões →
Baseado no vídeo do canal @josimarjmv publicado em 04/09/2026, com transcrição própria das legendas do vídeo. Preço e formato da imersão são os citados no vídeo; data ainda a definir.