Três dias atrás carreguei um monolito Laravel inteiro — 847 arquivos, aproximadamente 120.000 linhas de código — em uma única janela de contexto do GPT 5.4. Sem fragmentação. Sem resumos. Sem os truques de "aqui está o arquivo relevante" que vinha fazendo há anos. Apenas todo o codebase, cru, jogado numa sessão.
Então pedi para encontrar uma condição de corrida no meu queue worker que estava assombrando a produção por duas semanas.
Encontrou o bug em noventa segundos. Não um chute. Não um "isso pode ser o problema." Rastreou o caminho de execução através de quatro serviços, identificou o momento exato em que dois workers podiam pegar o mesmo job, e escreveu uma correção com um advisory lock a nível de banco de dados que eu tinha sido teimoso demais para considerar. Fiquei olhando para a tela por um minuto inteiro antes de sequer testar o patch.
Esse momento — esse específico e visceral "espera, o que acabou de acontecer?" — é a razão de eu estar escrevendo este post. GPT 5.4 não é uma atualização incremental. É o primeiro modelo de IA para programação que me fez genuinamente repensar como estruturo todo o meu fluxo de desenvolvimento. Mas não é perfeito, e parte do hype ao redor dele já está saindo de controle. Preciso separar o que é real do barulho de marketing, porque se você está prestes a reorganizar sua cadeia de ferramentas ao redor desse modelo, merece uma avaliação honesta de alguém que realmente o testou a fundo.
A Janela de Contexto de Um Milhão de Tokens Muda Tudo na Forma de Trabalhar
Venho reclamando das limitações de janela de contexto desde o limite original de 8K tokens do GPT-4 em 2023. Cada ferramenta de programação com IA que usei exigia alguma versão da mesma dança: selecionar cuidadosamente quais arquivos incluir, escrever resumos detalhados das partes que não cabem, e torcer para o modelo não alucinar conexões entre código que não pode realmente ver. Com Claude Code e Opus 4.6, o gerenciamento de contexto ficou mais inteligente — as ferramentas lidam com boa parte automaticamente — mas a restrição fundamental sempre esteve lá. Você sempre trabalhava com uma imagem parcial.
GPT 5.4 suporta até um milhão de tokens de contexto. Isso não é um máximo teórico enterrado na documentação. É uma janela de contexto utilizável e prática que preenchi com codebases reais em múltiplas ocasiões na última semana.
Eis o que muda quando contexto deixa de ser um gargalo.
Primeiro, você para de pensar no que incluir. Eu costumava passar de cinco a dez minutos no início de cada sessão complexa de depuração decidindo quais arquivos eram relevantes. Às vezes errava, percebia no meio do caminho que precisava de um arquivo de configuração ou middleware que não tinha incluído, e tinha que reiniciar a conversa. Com GPT 5.4, simplesmente carrego tudo. O modelo descobre o que é relevante. Essa fadiga de decisão desaparece completamente.
Segundo, preocupações transversais se tornam triviais de analisar. Quer entender como a autenticação flui por toda sua aplicação? Como uma única variável de ambiente se propaga através de configurações, serviços e scripts de deploy? Perguntas que antes exigiam traçar caminhos manualmente através de dezenas de arquivos — GPT 5.4 simplesmente responde. Tem a imagem completa. Pode ver a migration, o model, o controller, a rota da API, a chamada do frontend e o teste, tudo simultaneamente.
Terceiro — e isso me surpreendeu — a qualidade de geração de código do modelo melhora dramaticamente quando pode ver mais contexto. Fiz um experimento informal: pedi ao GPT 5.4 para adicionar uma nova funcionalidade a um projeto duas vezes. Uma vez com apenas os arquivos relevantes (uns 15 arquivos, talvez 3.000 tokens de código). Outra com todo o codebase carregado. A segunda tentativa produziu código que combinava com meus padrões existentes, usava minhas funções helper personalizadas em vez de reinventá-las, e seguia as convenções de nomenclatura que eu tinha estabelecido meses atrás. A primeira tentativa produziu código genérico, correto mas estranho. Mesmo modelo. Mesmo prompt. A única diferença foi o contexto.
Devo mencionar a restrição prática: carregar um milhão de tokens não é grátis. Os custos da API escalam com tokens de entrada, e carregar o codebase inteiro a cada interação queimaria créditos rápido. Para sessões exploratórias e depuração complexa, vale cada centavo. Para tarefas rotineiras de "escreva essa função", você está pagando demais. Me estabeleci num padrão onde carrego o codebase completo para trabalho de arquitetura e uso contextos menores e direcionados para programação do dia a dia. Esse equilíbrio parece certo — mas você precisará encontrar o seu.
Computer Use: Quando Sua IA Começa a Testar Seu Próprio Código
Esse é o recurso que me fez sentar direito. GPT 5.4 pode interagir com aplicações como um humano faria — clicando botões, lendo telas, navegando interfaces. A OpenAI chama de "computer use," e embora o nome soe como papo de marketing, a capacidade é genuinamente território novo para um modelo de programação.
Testei num dashboard React que venho construindo. Pedi ao GPT 5.4 para adicionar uma funcionalidade de exportação de dados, e em vez de apenas escrever o código e me devolver, ele escreveu o código, abriu o app no navegador, navegou até o dashboard, clicou no botão de exportação que acabou de criar, verificou que o CSV baixou corretamente, notou que a formatação de data estava errada numa coluna, voltou e corrigiu o código, depois testou de novo. Tudo sem eu tocar em nada.
Deixa eu ser realista sobre o estado atual: é impressionante mas não está pronto para produção em fluxos de teste complexos. O modelo lida bem com interações de UI simples — preenchimento de formulários, cliques em botões, navegação. Mas tem dificuldade com aplicações que dependem muito de estados hover, arrastar e soltar, ou timing de animações complexas. Fiz ele tentar testar uma funcionalidade de quadro Kanban e não conseguia arrastar cartas entre colunas de forma confiável. Sabia o que queria fazer. As habilidades motoras não estavam lá ainda.
Onde o computer use já brilha é no ciclo de feedback que cria. Tradicionalmente, o fluxo de programação com IA é: escrever código → testar manualmente → reportar problemas para a IA → iterar. Esse passo do meio — o teste manual — é onde vai a maior parte do tempo. Não porque testar é difícil, mas porque traduzir resultados visuais em descrições de texto para a IA é lento e perde informação. "O botão está lá mas está posicionado errado" perde informação comparado com o modelo realmente vendo o botão.
O computer use do GPT 5.4 colapsa esse ciclo. O modelo escreve, testa, vê o resultado e itera — tudo dentro de uma única interação. Para funcionalidades simples, isso reduz o ciclo de desenvolvimento de quatro passos para um. Construí e testei um formulário de contato completo — validação, estados de erro, mensagem de sucesso, envio de email — em um único prompt. O modelo passou por três iterações por conta própria antes de apresentar a versão final. Cada iteração corrigiu problemas reais que descobriu ao usar o formulário.
Espero que essa capacidade melhore rapidamente. O modelo de visão subjacente é forte. A camada de interação só precisa de polimento. Em seis meses, suspeito que computer use será requisito básico para modelos de IA de programação. GPT 5.4 chegou primeiro, e mesmo na forma atual, mudou como penso sobre a fase de testes do desenvolvimento.
Os Modos de Raciocínio que Realmente Importam
GPT 5.4 vem com modos de raciocínio selecionáveis — "high" e "ultra-high" — e minha reação inicial foi ceticismo. Modos de raciocínio pareciam uma checkbox de marketing. "Nosso modelo pensa mais duro se você pedir educadamente." Mas depois de usar ambos os modos extensivamente, mudei de ideia. A diferença é real, mensurável e vale a pena entender.
O modo de raciocínio high é o que você quer para 80% das tarefas de programação. Escrever funções, refatorar código, gerar testes, explicar lógica complexa. É rápido, preciso e confiável. Os tempos de resposta são comparáveis ao que experimentei com outros modelos de primeiro nível — você não fica esperando.
O modo de raciocínio ultra-high é para os problemas que te fazem fechar o laptop e sair para caminhar. Decisões arquiteturais com implicações em cascata. Depuração de condições de corrida em sistemas concorrentes. Análise de vulnerabilidades de segurança por todo um codebase. Otimização de performance onde o gargalo não é óbvio. Esses são problemas onde "pensar mais duro" realmente produz respostas diferentes — e melhores.
Fiz uma comparação direta com um problema real: otimizar uma query de banco de dados que levava 14 segundos numa tabela com 2.3 milhões de linhas. No modo high, GPT 5.4 sugeriu adicionar um índice e reescrever uma subquery como JOIN. Conselho padrão de otimização. Correto, mas eu já tinha tentado ambos. No modo ultra-high, o mesmo modelo analisou o plano de execução da query, identificou que o otimizador estava escolhendo um hash join quando um merge join seria mais rápido dada a distribuição dos dados, sugeriu um hint de query para forçar o merge join, recomendou um índice parcial na coluna filtrada, e apontou que minha cláusula WHERE estava impedindo o uso do índice por causa de um cast de tipo implícito que eu não tinha notado. A resposta ultra-high levou uns doze segundos a mais. Me economizou aproximadamente três horas de análise manual de queries.
A lição que tirei disso: não use ultra-high por padrão. Comece com high. Escale quando estiver travado ou quando o problema genuinamente exigir uma análise mais profunda. O modo ultra-high usa mais tokens e leva mais tempo — é uma ferramenta, não uma configuração para deixar permanentemente habilitada. Mas quando você precisa, a diferença entre "boa sugestão" e "isso é exatamente o insight que me faltava" vale a espera.
GPT 5.4 vs Opus 4.6: A Comparação Honesta que Ninguém Quer Fazer
Uso os dois. Diariamente. Não vou fingir que um é categoricamente melhor que o outro, porque seria desonesto e inútil. Aqui está o que encontrei depois de semanas rodando ambos os modelos nos mesmos projetos.
GPT 5.4 vence em complexidade de backend. Para codebases grandes, depuração complexa, arquiteturas multi-serviço e tarefas que requerem manter grandes quantidades de contexto simultaneamente, GPT 5.4 é atualmente o modelo mais forte. A janela de contexto de um milhão de tokens é a vantagem óbvia, mas não se trata apenas de capacidade. A habilidade do modelo de raciocinar através de partes distantes de um codebase — conectando uma mudança de schema de banco de dados com seus efeitos cascata através de uma camada de API, um sistema de gerenciamento de estado do frontend e uma suíte de testes — parece qualitativamente diferente do que obtenho com outros modelos.
Opus 4.6 vence em frontend e trabalho de UI. Isso me surpreendeu, honestamente. Esperava que GPT 5.4 dominasse em todas as áreas. Mas quando estou construindo componentes React, desenhando layouts, trabalhando com animações CSS ou iterando em design visual, Opus 4.6 consistentemente produz melhores resultados. Os componentes parecem mais polidos. O CSS é mais limpo. A sensibilidade de design — e percebo que estou atribuindo julgamento estético a um modelo de IA — parece mais refinada. Testei isso múltiplas vezes, alternando entre modelos na mesma tarefa de UI, e o padrão se mantém.
Ambos os modelos lidam com trabalho de desenvolvimento padrão igualmente bem. Para as tarefas do dia a dia — endpoints CRUD, migrations de banco de dados, testes unitários, documentação, revisões de código — genuinamente não consigo notar uma diferença significativa. Escolha qualquer modelo que encaixe no seu fluxo de trabalho existente.
Aqui está minha configuração atual, caso ajude: uso GPT 5.4 através do Cursor para trabalho de backend e sessões complexas de depuração. Fico no Claude Code com Opus 4.6 para desenvolvimento frontend, fluxos baseados em agentes, e qualquer coisa que se beneficie do excelente gerenciamento de contexto de projeto do Claude Code. Quando começo uma funcionalidade nova que abrange tanto frontend quanto backend, tipicamente começo com GPT 5.4 para a arquitetura e camada de API, depois mudo para Opus 4.6 para a implementação da UI.
Isso é ótimo? Provavelmente não. Vou consolidar num único modelo eventualmente? Talvez. Mas agora, as forças de cada modelo são diferentes o suficiente para que usar ambos produza trabalho melhor do que se comprometer exclusivamente com um.
Matt Shumer — CEO da HyperWrite e alguém cujas avaliações técnicas geralmente confio — chamou GPT 5.4 de "essencialmente perfeito" e disse que programação está "resolvida." Acho que isso é aproximadamente 70% correto. O modelo é assombrosamente capaz. Mas "resolvido" implica que não há nada para melhorar, e posso apontar pelo menos uma dúzia de interações dessa semana onde o modelo produziu código sutilmente errado, interpretou mal uma restrição, ou precisou de múltiplas iterações para acertar. É o melhor modelo de IA para programação que usei. Não é perfeito. A distância entre "o melhor disponível" e "impecável" ainda é real, e importa quando você está deployando código em produção.
Começando Sem Desperdiçar Suas Primeiras Duas Horas
Desperdicei minha primeira sessão com GPT 5.4 porque não entendia o cenário de ferramentas. Deixa eu te poupar esse tempo.
Passo 1: Escolha sua interface. Você tem três opções principais agora.
O app Codex é a interface de programação dedicada da OpenAI. Apesar do nome, o app não usa mais um modelo "Codex" separado — você seleciona GPT 5.4 num menu dropdown dentro do app. Isso me confundiu inicialmente porque ficava procurando uma opção de modelo Codex dedicado que não existe mais. O app conecta diretamente aos seus repositórios GitHub, o que significa que pode importar seu codebase sem downloads manuais. Para trabalho em nível de projeto — revisões de arquitetura, refatorações grandes, planejamento de funcionalidades — o app Codex é provavelmente seu melhor ponto de partida.
Cursor é onde faço a maioria do meu trabalho com GPT 5.4. Se você já é usuário de Cursor, a integração é perfeita — GPT 5.4 aparece como opção no seletor de modelos. A força do Cursor é a assistência de programação inline: você está escrevendo código, destaca um bloco, faz uma pergunta, recebe uma resposta em contexto. A velocidade e precisão do GPT 5.4 fazem esse fluxo parecer particularmente fluido. Se vem do VS Code com Copilot, Cursor com GPT 5.4 é um upgrade significativo.
A API diretamente é a terceira opção, e é o que uso para fluxos automatizados. Tenho scripts que rodam GPT 5.4 para revisão de código em pull requests, geração automatizada de testes para novos arquivos, e atualizações de documentação quando APIs mudam. A API dá controle total sobre gerenciamento de contexto, prompts de sistema e formatação de saída. Dá mais trabalho configurar, mas a flexibilidade não tem igual.
Passo 2: Prepare seu codebase. Se seu código vive no GitHub, tanto o app Codex quanto o Cursor podem conectar diretamente. Para Cursor, simplesmente abra a pasta do projeto local. Para o app Codex, conecte sua conta GitHub e selecione o repositório. Se não usa GitHub, baixe seu codebase como ZIP, extraia localmente e abra no Cursor. Recomendo ter uma cópia local limpa e atualizada independente de qual ferramenta use.
Passo 3: Comece com o modo de raciocínio high. Não pule direto para ultra-high. O modo high lida com 80% das tarefas de programação eficientemente, e você terá respostas mais rápidas. Reserve ultra-high para quando genuinamente estiver travado num problema complexo — você saberá quando precisa porque as sugestões do modo high não estarão resolvendo seu problema real.
Passo 4: Teste com uma tarefa real, não um exemplo de brinquedo. A pior forma de avaliar GPT 5.4 é pedir para escrever um app de tarefas ou inverter uma string. Essas tarefas não exercitam suas verdadeiras forças. Em vez disso, pegue um bug real que vem adiando, ou uma funcionalidade que requer mudanças em múltiplos arquivos, ou um problema de performance que não teve tempo de investigar. É aí que GPT 5.4 mostra seu valor.
Dica profissional: Se está migrando de outra ferramenta de programação com IA, não tente replicar seu fluxo de trabalho exato. A janela de contexto do GPT 5.4 é tão maior do que o que você está acostumado que seus velhos hábitos — curar cuidadosamente quais arquivos incluir, escrever resumos detalhados da sua arquitetura — são sobrecarga desnecessária. Deixe o modelo ver tudo. Deixe ele descobrir o que é relevante. Isso parece desconfortável no início, como soltar o volante. Mas o modelo navega melhor com o mapa completo do que você com uma rota destacada.
As Limitações Honestas de que Ninguém Fala
Fui entusiasta sobre GPT 5.4 ao longo deste post. Intencionalmente, porque o modelo merece. Mas faria um desserviço se não falasse sobre o que ainda está quebrado, limitado ou frustrante.
A qualidade de design frontend ainda não chegou lá. Mencionei na comparação com Opus, mas vale repetir porque muita gente está apostando tudo no GPT 5.4 para tudo. Se está construindo interfaces de usuário — especialmente qualquer coisa que precise parecer polida, ser responsiva e lidar com casos extremos de layout com graça — GPT 5.4 vai dar resultados funcionais mas visualmente medianos. O CSS que gera funciona. Os componentes renderizam corretamente. Mas as escolhas de design são seguras, genéricas e sem inspiração. Opus 4.6 é visivelmente melhor aqui, e ferramentas dedicadas de UI como fluxos Figma-to-code ainda produzem resultados visuais superiores.
A janela de um milhão de tokens tem um problema de custo. Aludi a isso antes, mas deixa eu ser explícito: carregar 500K+ tokens de contexto em cada interação é caro. Numa sessão de depuração particularmente intensa, queimei o que estimo foram $15-20 em créditos de API em umas três horas. Tudo bem pra mim — o bug que corrigi teria me tomado um dia inteiro sem o modelo. Mas se você é um desenvolvedor solo de olho nos custos, precisa de uma estratégia para quando usar contexto completo e quando ser seletivo.
As alucinações não desapareceram. São menos frequentes com GPT 5.4 do que qualquer modelo que usei antes, mas ainda acontecem. Terça passada, o modelo me disse com confiança que o Laravel 12 tinha introduzido um método Model::withoutTimestamps() para operações em massa. Não tinha. O método não existe. A sugestão era plausível o suficiente para que eu passasse quinze minutos procurando na documentação antes de perceber que o modelo inventou. Sempre verifique. Confie mas verifique. O modelo é mais inteligente que qualquer versão anterior, mas ainda é capaz de ficção criativa quando encontra lacunas nos dados de treinamento.
Tarefas de longa duração podem desviar. Em sessões estendidas — pense duas horas de vai e vem contínuo sobre uma funcionalidade complexa — notei que o modelo ocasionalmente perde o rastro de decisões tomadas antes na conversa. Sugere uma abordagem que contradiz algo que já tínhamos concordado que estava errado. A janela de um milhão de tokens ajuda porque tecnicamente pode "ver" a discussão anterior, mas a atenção sobre contextos muito longos não é uniforme. Decisões importantes no início de uma sessão longa podem receber menos peso que mensagens recentes. Minha solução: para decisões arquiteturais críticas, declaro-as explicitamente como restrições no início de cada fase principal de trabalho. "Decidimos X. Não vamos revisitar isso. Agora vamos trabalhar no Y."
Sem integração com Anti-Gravity ainda. Se você está no ecossistema Anthropic e usa Anti-Gravity para orquestrar fluxos multi-modelo, GPT 5.4 não está disponível lá ainda. Isso pode mudar — o cenário de ferramentas de IA se move rápido — mas até hoje, usar GPT 5.4 significa sair da cadeia de ferramentas Anthropic para essas tarefas específicas. Pra mim, isso significa manter dois fluxos de trabalho separados, o que adiciona fricção.
Listo essas limitações não para enfraquecer o modelo mas porque vi opiniões demais de "GPT 5.4 é perfeito, programação está resolvida" online. É o melhor modelo de IA para programação disponível agora. Também é uma ferramenta com restrições reais que você precisa entender antes de construir seu fluxo de trabalho ao redor dela.
O Que Isso Significa para os Próximos Seis Meses
Venho construindo com ferramentas de programação com IA desde o primeiro preview da API do GPT-4. A cada poucos meses, há um modelo que me obriga a atualizar meu modelo mental do que é possível. GPT 5.4 é um desses momentos.
A combinação de uma janela de contexto de um milhão de tokens, capacidades de computer use e raciocínio genuinamente melhorado cria algo que parece qualitativamente diferente do que veio antes. Não é apenas um autocomplete melhor. É mais próximo de um desenvolvedor junior que pode ler todo seu codebase, testar seu próprio trabalho e explicar seu raciocínio quando perguntado.
Aqui está minha previsão, e vou revisitá-la em seis meses: a próxima onda de ferramentas de programação com IA não vai competir apenas em qualidade de modelo. GPT 5.4 e Opus 4.6 provaram que múltiplas organizações podem produzir modelos de programação de classe mundial. O diferencial será o tooling — como o modelo se integra no seu fluxo de trabalho, como gerencia contexto, como lida com tarefas multi-passo e como se recupera de erros. O modelo é o motor. A experiência do desenvolvedor é o carro. Agora, temos ótimos motores em carros medianos.
Os desenvolvedores que mais se beneficiarão do GPT 5.4 não são os que o usam como autocomplete mais rápido. São os que reestruturam seus fluxos de trabalho para aproveitar suas verdadeiras forças: raciocínio sobre o codebase completo, testes autônomos e análise profunda de problemas complexos. Isso requer mudar hábitos. Requer deixar o modelo fazer coisas que você está acostumado a fazer manualmente. Requer um nível de confiança que leva tempo para construir — e deveria levar tempo, porque confiança cega em qualquer ferramenta é receita para deployar bugs.
Se você esteve em cima do muro sobre ferramentas de programação com IA, GPT 5.4 é o modelo que deveria te empurrar. Não porque é perfeito. Porque é bom o suficiente para que não usá-lo te coloca em desvantagem mensurável contra desenvolvedores que usam.
E aquela condição de corrida no meu queue worker? Aquela que passei duas semanas depurando manualmente? A correção do GPT 5.4 está rodando em produção há cinco dias. Zero incidentes. Zero jobs falhados. A abordagem de advisory lock foi mais limpa do que qualquer coisa que eu teria escrito, e o modelo levou noventa segundos para encontrar uma solução que me escapou por catorze dias.
Não tenho certeza se isso me faz sentir brilhante por usar a ferramenta certa, ou humilde que a ferramenta é melhor no meu trabalho do que eu. Provavelmente os dois. Definitivamente os dois.
Vamos Trabalhar Juntos
Quer construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.
- Fiverr (builds personalizados e integrações): fiverr.com/s/EgxYmWD
- Portfólio: mejba.me
- Ramlit Limited (soluções empresariais): ramlit.com
- ColorPark (design e branding): colorpark.io
- xCyberSecurity (serviços de segurança): xcybersecurity.io
