"Qual modelo de IA devo usar para programar?"
Se eu ganhasse um dólar por cada vez que alguém me perguntou isso nos últimos seis meses, teria o suficiente para cobrir meus custos de API por uma semana. Talvez.
Aqui está a questão — a maioria das comparações de modelos de IA são inúteis. Executam benchmarks sintéticos, testam trechos de código isolados e declaram vencedores com base em métricas que não têm nada a ver com a forma como realmente trabalhamos. Ninguém está sentado pedindo à IA para escrever implementações de bubble sort. Estamos tentando construir software real.
Então fiz algo diferente. Peguei um monstruoso Documento de Requisitos do Produto — derivado de uma aplicação real e completa que eu havia construído — e joguei para cinco modelos de IA diferentes. O mesmo PRD. As mesmas instruções. Cronômetro de duas horas. Vamos ver quem sobrevive.
Os resultados me surpreenderam. E não da forma que eu esperava.
A configuração que quebra a maioria dos modelos
Antes de mergulharmos, deixe-me explicar o que eu estava realmente testando. Isto não era um projeto de brinquedo ou um prompt de "construa um app de tarefas". O PRD que usei era massivo — documentação técnica detalhada cobrindo componentes de UI, arquitetura backend, funcionalidades alimentadas por IA, prompts de personalidade, motores de recomendação e mais.
Pense nisso como um dashboard de plataforma de streaming. Usuários navegam por shows, recebem recomendações alimentadas por IA, exploram conceitos temáticos, veem informações de elenco e equipe, verificam avaliações de múltiplas fontes e interagem com uma funcionalidade de "alquimia" que permite combinar shows para descobrir novo conteúdo baseado em conceitos combinados.
O tipo de coisa que levaria semanas para uma equipe especificar adequadamente. Dei a cada modelo o documento completo e disse "comece aqui".
Os competidores:
- GPT-5.1 Codex Max (o campeão anterior)
- GPT-5.2 Medium (o nível recomendado pela OpenAI)
- GPT-5.2 Extra High (pensamento máximo, custo máximo)
- Claude Opus 4.5 (o carro-chefe da Anthropic)
Eu queria saber: Esses modelos conseguem realmente executar requisitos complexos do mundo real? Não apenas escrever funções — mas construir aplicações coerentes a partir de especificações densas?
Os primeiros 30 minutos: Onde as personalidades emergem
Algo interessante aconteceu quase imediatamente.
GPT-5.1 Codex Max pulou direto para a ação. Arquivos começaram a aparecer. Dependências foram instaladas. Um servidor subiu nos primeiros dez minutos. Parecia rápido. Produtivo. Como assistir a um desenvolvedor que tomou café demais simplesmente começar a produzir código.
Os modelos GPT-5.2 — tanto Medium quanto Extra High — adotaram uma abordagem diferente. Passaram mais tempo pensando. Processando. Quase dava para vê-los lendo o PRD, tentando entender o escopo completo antes de escrever uma única linha.
E então havia o Opus 4.5.
Aqui é onde as coisas ficaram interessantes. Opus não simplesmente começou a programar. Começou a conversar comigo. Uma lista de tarefas apareceu. Verbalizou o que entendeu do PRD. Fez perguntas esclarecedoras. Disse coisas como "Com base nos requisitos, vou estruturar isso como..." antes de fazer qualquer coisa.
Não vou mentir — no início, isso pareceu mais lento. Mas algo naquilo parecia certo.
A lacuna de comunicação de que ninguém fala
Deixe-me pausar aqui porque isso se tornou a percepção mais importante de todo o experimento.
Modelos GPT começam a programar imediatamente. Leem seu prompt e executam. Sem confirmação. Sem "aqui está o que eu entendi". Apenas ação.
Modelos Opus comunicam primeiro. Reconhecem o que você pediu. Explicam sua interpretação. Mostram o roteiro antes de construir a estrada.
Por que isso importa?
Porque quando você trabalha com IA em tarefas complexas, precisa saber o que ela realmente entendeu. Se GPT-5.2 interpreta mal um requisito e constrói a coisa errada, você só saberá quando vir a saída quebrada. Se Opus interpreta algo errado, ele te diz antecipadamente — e você pode corrigir antes que qualquer código seja escrito.
Não se trata de qual modelo é "mais inteligente". Trata-se de qual faz a colaboração parecer menos com apostas.
Trabalhei com desenvolvedores juniores que programam mais rápido que seniores. Velocidade não é o mesmo que produtividade. Os melhores colaboradores — humanos ou IA — confirmam entendimento antes de executar.
Hora um: A corrida de funcionalidades
Na marca de sessenta minutos, as diferenças ficaram evidentes.
GPT-5.1 Codex Max tinha uma aplicação rodando. Parecia... funcional. CSS básico, algum estilo faltando, mas a estrutura central estava lá. Funcionalidades faltantes eram óbvias — sem motor de recomendação, exibição limitada de metadados, navegação incompleta.
GPT-5.2 Medium mostrou melhoria em relação ao 5.1. A UI parecia mais polida. Atingiu mais das funcionalidades solicitadas. Mas a arte-chave faltava. Alguns elementos interativos não estavam conectados. O "medium" no nome parecia preciso — meio do caminho.
GPT-5.2 Extra High foi mais lento mas mais completo. A interface era mais limpa. Mais acessível. Layout lógico. O motor de recomendação funcionou. Metadados foram recuperados corretamente. Informações de elenco e equipe foram exibidas corretamente. Foi genuinamente impressionante — até eu notar que as listas de episódios sob as temporadas dos programas de TV estavam completamente ausentes.
Opus 4.5 estava construindo algo diferente. Elementos visuais mais ricos. Animações que eu não havia solicitado especificamente mas que faziam sentido. Exibições de dados financeiros (lucro, ROI). Decomposições claras de avaliações e gêneros. E — isto é fundamental — um player de trailer inline que nenhum dos modelos GPT sequer tentou.
Mas a UI do Opus também era mais complexa. Mais carregada. Mais difícil de navegar à primeira vista. Otimizou para completude sobre simplicidade.
A revelação do documento de lacunas
Aqui está algo que mudou tudo.
Nenhum dos modelos completou totalmente o PRD de uma só vez. Nem de perto. Todos perderam funcionalidades. Todos fizeram suposições. Todos tinham lacunas.
Então criei o que estou chamando de "documento de lacunas" — um segundo prompt que listava tudo que a construção inicial perdeu, essencialmente pedindo a cada modelo que se auditasse contra os requisitos originais e preenchesse as lacunas.
É aqui que GPT-5.2 Extra High e Opus 4.5 avançaram dramaticamente.
Ambos os modelos responderam ao documento de lacunas abordando sistematicamente funcionalidades ausentes. Listas de episódios apareceram. Lógica de recomendação melhorou. Polimento da UI aumentou. Dentro de mais uma hora de iteração, ambos haviam alcançado o que estimo em 90-95% de completude funcional.
O antigo GPT-5.1? Teve dificuldades. Ficava confuso sobre o que já havia construído versus o que estava sendo solicitado. Gerenciamento de contexto se tornou um problema.
A lição: Nenhum modelo de IA hoje pode executar totalmente um PRD complexo de forma autônoma. Mas os melhores podem chegar notavelmente perto com uma rodada de feedback estruturado. A lacuna não está na capacidade bruta — está na autoauditoria.
Filosofia de UI: Elegância vs Completude
Deixe-me falar sobre as saídas visuais porque revelam algo importante sobre como esses modelos pensam.
GPT-5.2 Extra High produziu o que eu chamaria de interfaces "amigáveis para desenvolvedores". Limpas. Previsíveis. O tipo de UI que é fácil de usar porque não tenta fazer demais de uma vez. Bom espaçamento. Hierarquia lógica de informação. Se você mostrasse a um gerente de produto, ele provavelmente aprovaria sem muitas mudanças.
Opus 4.5 construiu algo mais ambicioso. Cada ponto de dados possível veio à superfície. Múltiplos padrões de interação. Riqueza visual que beirava o avassalador. Parecia que Opus estava tentando provar que entendia cada requisito mostrando todos simultaneamente.
Nenhuma das abordagens está errada. Mas servem para propósitos diferentes.
Se você precisa de um protótipo rápido para validar uma ideia, a saída mais limpa do GPT-5.2 te leva lá mais rápido. Se precisa de cobertura funcional abrangente e não se importa em refinar a apresentação depois, Opus te dá mais para trabalhar.
Descobri que usava a saída do GPT-5.2 como referência de UI enquanto pegava implementações de funcionalidades do Opus. A combinação funcionou melhor do que qualquer um sozinho.
As funcionalidades de IA: Onde fica interessante
Ambos os modelos implementaram funcionalidades alimentadas por IA — extração de conceitos, recomendações temáticas, exploração dinâmica baseada em preferências do usuário. É aqui que o PRD ficou complicado, e onde eu esperava que os modelos tivessem dificuldades.
Não tiveram. Não realmente.
Os motores de recomendação funcionaram. Entenderam relações semânticas entre shows. Conseguiam explicar por que duas séries aparentemente diferentes poderiam atrair o mesmo espectador.
A funcionalidade de "alquimia" do Opus se destacou. Permitia que os usuários combinassem múltiplos shows e extraíssem conceitos temáticos sobrepostos para encontrar novas recomendações. Isso estava no PRD, mas exigia entendimento de um conceito bastante abstrato. Opus acertou em cheio. A interface de mashup era intuitiva, e as recomendações geradas realmente faziam sentido.
GPT-5.2 implementou alquimia também, mas mais literalmente. Combinou shows e cuspiu recomendações. A magia — a meta-análise de por que certas combinações funcionavam — não estava lá.
Para programação assistida por IA de funcionalidades de IA, Opus tinha a vantagem. Entendeu a intenção por trás dos requisitos, não apenas as especificações literais.
O que ninguém acertou
Vamos falar sobre falhas porque importam tanto quanto os sucessos.
Arte-chave. Todo modelo teve dificuldade com imagens dos shows. O PRD especificava integração com APIs externas para arte de pôster e miniaturas. Nenhum modelo as recuperou e exibiu de forma confiável. Alguns fizeram caixas de espaço reservado. Alguns as ignoraram completamente. Nenhum conseguiu funcionar completamente.
Trailers. Apenas Opus tentou reprodução de trailer inline. Os outros pularam ou geraram implementações quebradas.
Autoauditoria. Nenhum modelo verificou naturalmente seu próprio trabalho contra o PRD original. Todos necessitaram documentos de lacunas explícitos para identificar funcionalidades ausentes. Isso sugere que modelos de IA atuais são bons em executar mas ruins em validar sua própria saída.
Manuseio de mídia em geral. Funcionalidades baseadas em texto foram sólidas. Tudo envolvendo assets externos — imagens, vídeos, integrações de API — ficou aquém. Os modelos conseguiam escrever o código, mas depurar respostas de API e lidar com casos extremos ainda exigia intervenção humana.
Velocidade vs Qualidade: A verdadeira compensação
Deixe-me dar números concretos.
GPT-5.1 Codex Max: Saída inicial mais rápida. Menor completude funcional. Mais bugs. Tempo até protótipo "utilizável": ~45 minutos. Tempo até aplicação "completa": Não conseguiu em duas horas.
GPT-5.2 Medium: Velocidade moderada. Cobertura funcional razoável. Alguns problemas de polimento. Tempo até protótipo utilizável: ~60 minutos. Tempo até quase completo: ~100 minutos com documento de lacunas.
GPT-5.2 Extra High: Saída inicial mais lenta. Alta completude funcional. UI limpa. Tempo até protótipo utilizável: ~75 minutos. Tempo até quase completo: ~110 minutos com documento de lacunas.
Opus 4.5: Saída inicial razoavelmente rápida (servidor iniciou cedo). Maior completude funcional. UI complexa. Tempo até protótipo utilizável: ~50 minutos. Tempo até quase completo: ~95 minutos com documento de lacunas.
Se você está otimizando puramente por velocidade, GPT-5.2 Medium faz sentido. Se está otimizando por completude e não se importa com iteração, Opus 4.5 entrega mais funcionalidades por dólar gasto.
A equação de custos de que ninguém quer falar
Esses modelos não são gratuitos. E o nível "Extra High" do GPT-5.2 custa significativamente mais que Medium.
Aqui está minha opinião honesta: GPT-5.2 Extra High não justificou seu prêmio sobre Medium para esta tarefa. Sim, a saída foi mais limpa. Sim, capturou mais alguns requisitos. Mas a melhoria marginal não valia 3-4x o custo.
Opus 4.5, apesar de caro, pareceu valer a pena. Só o estilo de comunicação economizou tempo de depuração. A completude funcional reduziu ciclos de iteração. O entendimento de requisitos complexos de IA significou menos retrabalho.
Eficiência de custos importa. O modelo da Anthropic entregou mais valor por turno de conversa do que o nível mais alto da OpenAI. Isso não é declaração de fã — é contabilidade.
O que isso significa para o desenvolvimento real
Serei direto: Nem GPT-5.2 nem Opus 4.5 substituirá desenvolvedores tão cedo.
Mas estão substituindo meses de trabalho por horas de trabalho. Isso não é nada. Isso é transformador.
A aplicação que usei como base para este PRD levou uma equipe várias semanas para construir originalmente. Esses modelos de IA alcançaram 90-95% de paridade funcional em menos de duas horas. Os 5-10% restantes — os casos extremos, o polimento, a depuração — ainda precisam de atenção humana. Mas o trabalho pesado? Feito.
Isso muda como pensamos sobre prototipagem. Muda como validamos ideias. Muda a economia de construir software.
Ainda não estamos em "prompt e envie". Estamos em "prompt, revise, itere e envie mais rápido do que nunca". Isso ainda é uma mudança massiva.
Minha recomendação
Após executar este experimento, aqui está o que eu diria a outro desenvolvedor:
Use Opus 4.5 quando:
- Estiver construindo algo complexo com funcionalidades impulsionadas por IA
- Precisar de alta completude funcional e não se importar com refinamento de UI
- Valorizar comunicação e quiser verificar entendimento antes da execução
- Estiver disposto a pagar um prêmio por ciclos de iteração reduzidos
Use GPT-5.2 Medium quando:
- Precisar de protótipos rápidos para validação
- A UI importar mais que profundidade funcional
- Orçamento for uma restrição primária
- Se sentir confortável com mais depuração prática
Pule GPT-5.2 Extra High. Para a maioria dos casos de uso, não justifica o prêmio de custo sobre Medium. As melhorias incrementais não são suficientes.
Não se preocupe com GPT-5.1 Codex Max. Foi superado. Os modelos mais novos são significativamente melhores.
O quadro geral
Estamos assistindo as ferramentas de codificação IA evoluírem em tempo real. Seis meses atrás, pedir a um modelo para executar um PRD complexo seria risível. Hoje, é viável — com ressalvas.
A lacuna entre "código gerado por IA" e "código pronto para produção" está diminuindo. Não desapareceu. Mas está diminuindo rápido.
Os desenvolvedores que descobrirem como colaborar efetivamente com essas ferramentas — que aprenderem a escrever PRDs melhores, que dominarem a arte dos documentos de lacunas, que entenderem qual modelo usar para qual tarefa — terão uma vantagem enorme.
Não se trata de ser substituído. Trata-se de ser amplificado.
Os melhores desenvolvedores humanos usarão IA para multiplicar sua produção. Aqueles que resistirem vão se perguntar por que todos os outros entregam mais rápido.
Eu sei de que lado estou.
Considerações finais
Se você tirar uma coisa deste experimento, que seja esta: Pare de avaliar modelos de IA em benchmarks sintéticos. Teste-os no seu trabalho real. Dê a eles seus requisitos confusos, complexos e do mundo real. Veja o que acontece.
Os resultados podem surpreendê-lo.
Certamente me surpreenderam.
🤝 Contratar / Trabalhar comigo:
- 🔗 Fiverr (builds personalizados, integrações, performance): fiverr.com/s/EgxYmWD
- 🌐 Mejba Portfólio Pessoal: mejba.me
- 🏢 Ramlit Limited: ramlit.com
- 🎨 ColorPark Agência Criativa: colorpark.io
- 🛡 xCyberSecurity Serviços Globais: xcybersecurity.io
