Como migrar código legado com o GPT-6 Sol: fatiando o projeto em etapas que o modelo consegue terminar

Migração de projeto legado quase nunca morre de dificuldade técnica

ela morre de escopo

Você abre a sessão, manda "migra esse projeto todo pro framework novo", o agente sai bem nos primeiros vinte arquivos e depois começa a inventar caminho, perder contexto e afirmar que terminou algo que nem compila

O GPT-6 Sol, que a OpenAI lançou em 22/09/2026 junto com o GPT-6 Luna, é um modelo construído justamente para codificação complexa e fluxos agênticos, com posicionamento oficial de escolha equilibrada para tarefas que se beneficiam de validação cuidadosa em múltiplas etapas

Repare na palavra: validação em MÚLTIPLAS etapas

Isso não é detalhe de marketing, é a instrução de uso do bicho

Então esse post não é promessa de reescrita automática, é método de fatiamento: como definir fronteira de tarefa, o que conta como "pronto" e onde o humano precisa olhar antes de liberar a próxima fatia

Bora?

O que você precisa antes de começar a migração

Antes de sair rodando, três coisas precisam estar de pé

1. Acesso ao modelo certo

O GPT-6 Sol está disponível no ChatGPT Work e no Codex para usuários Plus, Pro, Business, Enterprise e Edu

Quem está no Free ou no Go acessa o GPT-6 Luna no app de desktop

Na API os identificadores são gpt-6-sol e gpt-6-luna

Se o teu fluxo é GitHub Copilot, o GPT-6 Sol aparece nos planos Pro+, Max, Business e Enterprise, e o Luna nos planos Pro, Pro+, Max, Business e Enterprise

Detalhe importante pra quem vive no Codex: o GPT-6 Sol é o modelo padrão de lá, e a documentação recomenda gpt-6-sol pra quem usa login ChatGPT nos planos Plus, Pro, Business, Enterprise e Edu, com gpt-6-luna atendendo Free e Go

2. Repositório em estado migrável

Código versionado, sem alteração solta fora do git

Suíte de testes que rode, nem que seja parcial (ela vira teu critério de pronto lá na frente)

E uma branch base definida, porque é contra ela que você vai comparar cada fatia

Se você já passou por troca de modelo em projeto que estava rodando, vale revisar aquele checklist antes de trocar o modelo pra não misturar duas mudanças grandes na mesma semana

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

3. Noção de custo por fatia

Na API, o GPT-6 Sol custa US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída

Tokens de entrada cacheados saem por 10% da taxa de entrada não cacheada, e escritas de cache são cobradas a 1,25x dessa taxa

Ou seja: repetir o mesmo contexto base entre fatias é barato, empurrar o repositório inteiro a cada pergunta é caro

Tome cuidado com isso desde a primeira fatia, não depois que a fatura chegar 😛

Passo a passo: fatiando o projeto legado em etapas que o GPT-6 Sol termina

A sequência abaixo segue o método de migração que a própria documentação do Codex recomenda, com os pontos onde o vibe coder costuma se ferrar

1. Inventarie as premissas do sistema legado com o agente em modo só leitura

Antes de escrever uma linha, você precisa saber o que o sistema faz hoje: rotas, modelos de dados, autenticação, configuração, tooling de build, testes, deploy e contratos externos

Esse levantamento é leitura pura, então rode o agente sem permissão de escrita:

codex --sandbox read-only --ask-for-approval on-request

O modo read-only é só leitura, e a política on-request faz o agente trabalhar dentro do sandbox e pedir autorização quando precisar sair do limite

Se quiser trocar o perfil no meio da sessão, o comando /permissions abre o seletor

O erro comum deste passo: começar o inventário já com workspace-write ligado, que é o modo padrão de baixo atrito pra trabalho local

Aí o agente "aproveita" e ajeita um arquivo no meio do mapeamento, e você perde a foto do estado original

2. Mapeie o stack antigo para o novo, apontando o que NÃO tem equivalente direto

Essa é a parte que todo mundo pula

Migração fácil é a que tem tradução um pra um, e essa não é a que dá problema

O que trava o agente lá na fatia 7 é justamente o pedaço sem equivalente: um helper de sessão que não existe no framework novo, um ORM que resolvia relação de um jeito que o outro não resolve, um comportamento de config implícito

Peça esse mapeamento explicitamente, com a lista do que não tem correspondente

O erro comum deste passo: aceitar o mapeamento como tabela bonitinha sem revisar o que ficou no vazio

O que ficou sem equivalente é exatamente onde o humano decide, não o modelo

3. Escreva o ExecPlan antes de qualquer implementação longa

O Codex trabalha com um documento de design chamado ExecPlan, cujos requisitos ficam descritos num PLANS.md

A ativação tem duas partes: adicionar o arquivo PLANS.md ao repositório e atualizar o AGENTS.md pra descrever quando usar o PLANS.md

Que AGENTS.md? É o arquivo de memória de projeto que o Codex lê antes de começar o trabalho, montando uma cadeia de instruções uma vez por execução

No escopo global ele lê o diretório home do Codex (padrão ~/.codex, ou o definido em CODEX_HOME), priorizando AGENTS.override.md e, na ausência dele, AGENTS.md

No escopo de projeto ele caminha da raiz até o diretório atual, e os arquivos mais próximos do diretório atual sobrescrevem os anteriores

Regra de ouro do ExecPlan, segundo a documentação oficial: o plano deve tratar o leitor como alguém que NÃO conhece o repositório, com acesso apenas à árvore atual e ao próprio arquivo de plano

Se o plano só faz sentido pra quem já tem o projeto na cabeça, ele não serve como fronteira de tarefa

O erro comum deste passo: escrever plano com atalho mental do tipo "migrar o módulo de pagamento como sempre fizemos"

O agente não tem o "como sempre fizemos"

4. Defina a fronteira de cada milestone com camada de compatibilidade, não com reescrita única

O método recomendado é plano incremental com camadas de compatibilidade ou checkpoints, em vez de trocar tudo de uma vez

E tem uma regra que precisa estar escrita no plano: manter o comportamento inalterado, salvo quando a migração exigir mudança visível

Essa frase é o que impede o modelo de "melhorar" a regra de negócio enquanto migra

Na prática, cada fatia vira uma linha de plano com três campos: o que entra, o que continua igual e o que o rollback derruba

O erro comum deste passo: escopo definido por arquivo ("migrar services/") em vez de por comportamento

Pasta não é fronteira, comportamento é

5. Ajuste o esforço de raciocínio por tipo de fatia

O GPT-6 Sol suporta os níveis none, low, medium (padrão), high, xhigh e max

Esforço menor favorece velocidade e gasta menos token, esforço maior entrega resposta mais completa

Dentro da sessão interativa, o comando /model troca o modelo ou ajusta o esforço

Na abertura do Codex dá pra escolher com --model ou com o alias -m, e a mesma opção funciona em execução não interativa

Pra fixar por configuração, use a chave model_reasoning_effort no ~/.codex/config.toml:

model_reasoning_effort = "high"

A chave aceita esses mesmos níveis de esforço, conforme o modelo e o cliente suportarem

O erro comum deste passo: deixar tudo no max "pra garantir"

Fatia mecânica (renomear import, trocar assinatura repetida) não precisa de raciocínio pesado, e você paga a diferença em token de saída

6. Rode cada fatia em worktree isolada (suporte experimental)

Um aviso antes de você apoiar o isolamento das fatias nisso: o suporte a worktree no Codex é experimental, então trate como conveniência e não como garantia

O recurso cria checkouts isolados pra sessões novas ou bifurcadas, com navegação e retomada dessas sessões:

codex --worktree

Dentro da sessão, o comando equivalente é /worktree

A vantagem é óbvia: fatia que deu errado morre no checkout dela, sem contaminar a branch base

O erro comum deste passo: rodar três fatias na mesma árvore de trabalho e depois não saber qual mudança veio de qual milestone na hora de reverter

7. Critério de pronto: lint, type-check e testes focados depois de CADA milestone

Aqui está o coração do método

"Pronto" não é o agente dizer que terminou

Pronto é rodar lint, type-check e testes focados após o milestone, e se a validação falhar, corrigir ANTES de seguir pra próxima fatia

Dívida de validação acumulada é o que transforma migração em bola de neve

Vale lembrar que teste verde não garante código no padrão da casa, então olha também as convenções do projeto e não só o que roda

O erro comum deste passo: rodar a suíte inteira e demorar tanto que você começa a pular a checagem

Teste focado existe por isso

8. Ponto de checagem humana com /review

O Codex CLI tem o comando /review, que roda uma revisão não interativa e reporta achados priorizados SEM modificar a árvore de trabalho

Ele funciona sobre mudanças não commitadas, sobre o diff contra uma branch base, sobre um commit específico ou com instruções customizadas

É o encaixe perfeito pro fim de fatia: o agente implementou, a validação passou, e agora vem uma leitura crítica do diff contra a branch base antes de você aprovar

O erro comum deste passo: tratar o /review como carimbo

Ele prioriza achados, quem decide o que é aceitável continua sendo você

9. Gerencie o contexto ao longo da sessão longa

Migração é conversa comprida, e conversa comprida entope contexto

O comando /compact resume o histórico, substituindo os turnos anteriores por um sumário e liberando espaço

Pra automatizar, existe a configuração model_auto_compact_token_limit (em tokens), com model_auto_compact_token_limit_scope aceitando total (padrão) ou body_after_prefix

O erro comum deste passo: compactar no meio de uma fatia, perdendo a decisão de design que justificava o que estava sendo feito

Compacte na fronteira entre milestones, com o ExecPlan atualizado no repositório servindo de memória de verdade

10. Migração maior? Conduza pelo /goal

Pra migrações de porte maior, a documentação de casos de uso sugere usar o /goal pro Codex conduzir o processo, com prompt do tipo:

migrar este projeto de <stack legado> para <stack alvo>

E mantenha rollback ou fallback visíveis até o fim da transição

Não é frescura: enquanto a camada de compatibilidade estiver de pé, você tem saída

O erro comum deste passo: derrubar o caminho antigo na metade da migração porque "já tá funcionando"

Já vi projeto virar refém disso

Como o fatiamento muda conforme o tipo de migração

Fronteira de tarefa não é uma só, ela depende do que está migrando

O cookbook oficial de modernização de codebase organiza o trabalho em 5 fases que giram em torno do ExecPlan, e o plano piloto é escopado a um ÚNICO fluxo, cobrindo quatro entregas: inventário e diagramas, relatório técnico de modernização, design e especificação do alvo, e plano de testes de paridade

Essas quatro entregas são o esqueleto que você adapta nos três cenários abaixo

Troca de versão de framework: fatia por módulo

Aqui o mapeamento costuma ter muito equivalente direto, e o perigo é o excesso de confiança

Fatie por módulo, com camada de compatibilidade segurando a ponta entre o módulo migrado e o resto do sistema ainda na versão antiga

O critério de pronto do módulo é comportamento idêntico, então o plano de testes de paridade vale ouro

Troca de linguagem: fatia por fluxo

Esse é o caso em que a lista de "não tem equivalente direto" fica comprida

Fatie por fluxo de negócio inteiro, não por camada, e use o piloto escopado a um único fluxo antes de prometer prazo pra qualquer outra coisa

O inventário e os diagramas aqui não são burocracia, são o que permite o ExecPlan ser lido por quem não conhece o repositório

E o relatório técnico de modernização é onde as decisões difíceis ficam registradas, em vez de morarem na cabeça de uma pessoa

Infraestrutura e contratos externos: fatia por contrato

Quando o que muda é deploy, configuração ou integração com terceiro, a fronteira natural é o contrato

Uma fatia = um contrato externo migrado, com fallback visível até o fim da transição

É o cenário em que mais dói pular o passo de rollback, porque a quebra não aparece no teste local, aparece no cliente 😀

Janela de contexto, esforço e custo: o que cabe em cada fatia

O tamanho da fatia não é gosto pessoal, ele sai de números concretos

A leitura prática é direta: fatia grande demais custa desproporcionalmente mais

Passou de 272 mil tokens de entrada, a multiplicação vale pra requisição toda, não só pro excedente

Então o fatiamento não é só disciplina de engenharia, é decisão de custo

O GPT-6 Sol dá conta de uma migração de verdade?

Vou ser honesto: esse post não traz teste próprio

O que dá pra fazer é ler os números divulgados sem inventar conclusão em cima deles

No DeepSWE v1.1, o GPT-6 Sol em esforço max marca 68,8%, contra 69,9% do Claude Fable 5 em xhigh, com custo por tarefa cerca de 80% menor

Ou seja: fica ligeiramente atrás no placar e MUITO à frente na conta

O GPT-6 Luna em max marca 66,6%

Nos benchmarks de agente de código a evolução contra o antecessor aparece: Terminal-Bench 4.0 em 43% contra 37% do GPT-5.6 Sol, e SWE-Atlas-QnA em 58% contra 54%, ambos em esforço max

No Coding Agent Index da Artificial Analysis, que combina modelos com harnesses agênticos e reúne DeepSWE, Terminal-Bench v2 e SWE-Atlas-QnA, o GPT-6 Sol faz 57 pontos em max, 2 pontos acima do GPT-5.6 Sol em max, com cerca de metade do custo por tarefa do antecessor

No Artificial Analysis Intelligence Index, a página do modelo marca 48 pontos pro GPT-6 Sol em max

E tem o preço: os modelos Sol e Luna vieram com corte de 50% frente ao preço promocional dos equivalentes GPT-5.6, sendo que o GPT-5.6 Sol custava US$ 4 e US$ 20 por milhão de tokens de entrada e saída

Agora a parte que mais interessa em migração

Na avaliação interna de factualidade da OpenAI, baseada em conversas reais desidentificadas em que usuários sinalizaram erros dos modelos, o GPT-6 Sol comete cerca de METADE dos erros do antecessor, chegando a uma confiabilidade próxima da do GPT-6 Astra a custo bem menor

E tanto Sol quanto Luna apresentam taxas menores de afirmações enganosas sobre o trabalho de código que realizaram, em comparação com os equivalentes GPT-5.6

Isso importa pra caramba num projeto legado, porque o custo alto não é o modelo errar, é o modelo errar dizendo que acertou

Mas repare no verbo: reduz

Não elimina

Por isso o /review e a validação por milestone não saem do método

Veredito: dá conta de migração de verdade DESDE QUE o trabalho chegue fatiado até ele

O que os números sugerem é um modelo forte em fluxo agêntico com custo que permite iterar bastante, não um botão de reescrita

Próximo passo: comece pelo ExecPlan de um fluxo só

Se eu pudesse resumir tudo em uma frase, seria: resista à vontade de migrar o projeto inteiro na primeira sessão

Pega UM fluxo

Escreve o ExecPlan dele, com PLANS.md no repositório e o AGENTS.md dizendo quando usar esse plano

Roda o inventário em sandbox de leitura, mapeia o que não tem equivalente direto, define a camada de compatibilidade e só então libera escrita

Fecha o milestone com lint, type-check e testes focados, passa o /review no diff contra a branch base e só depois abre a próxima fatia

Depois é repetir o ciclo, fatia a fatia, mantendo rollback visível, até o dia em que a camada de compatibilidade não tem mais ninguém do outro lado

Aí você derruba ela e a migração acabou de verdade

Sem heroísmo, sem sessão de madrugada, sem reescrita mágica…

até o próximo post! 😀