A Inteligência Artificial está mudando rapidamente a forma como desenvolvemos software. Há pouco tempo, utilizar IA durante a programação significava principalmente pedir a geração de uma função, explicar um erro, completar um trecho de código ou produzir alguma documentação. Hoje, com ferramentas como Codex e outros agentes de desenvolvimento, podemos entregar tarefas muito maiores: analisar um repositório, compreender uma arquitetura existente, alterar vários arquivos, executar comandos, compilar o projeto, rodar testes, investigar erros e continuar trabalhando até encontrar uma solução.

Essa evolução trouxe um problema que até pouco tempo praticamente não existia: qual modelo devemos utilizar para programar?

A resposta parece simples. Se existe um modelo mais poderoso, basta utilizá-lo. Porém, quando começamos a usar agentes diariamente, essa estratégia pode se tornar desnecessariamente cara. Modelos diferentes possuem preços bastante diferentes e, principalmente, tarefas de desenvolvimento possuem níveis de complexidade completamente distintos. Utilizar o modelo mais poderoso disponível para alterar um campo de uma API ou criar um CRUD pode representar desperdício de capacidade e dinheiro.

No extremo oposto, escolher sempre o modelo mais barato também não é necessariamente uma boa estratégia. Uma tarefa complexa entregue a um modelo menos capaz pode exigir várias tentativas, consumir mais tokens, produzir alterações incorretas e demandar intervenção humana. No final, aquilo que parecia barato pode custar mais.

Neste artigo quero analisar justamente esse problema, comparando algumas das principais opções disponíveis atualmente para desenvolvimento de software: DeepSeek V4 Flash, DeepSeek V4 Pro, Gemini 3.1 Pro, GPT-5.6 Terra, GPT-5.6 Sol e GPT-6 Astra.

Mais importante do que simplesmente declarar qual deles é “o melhor”, quero chegar a uma pergunta que considero muito mais relevante para quem utiliza IA profissionalmente:

Quanto de inteligência realmente precisamos comprar para cada tarefa de desenvolvimento?

O modelo mais poderoso nem sempre é a melhor escolha

Para entender o problema, imagine duas solicitações feitas a um agente de programação.

Na primeira, pedimos:

Crie um endpoint REST em Node.js para cadastrar produtos utilizando TypeScript, validação com Zod e persistência com Prisma.

Na segunda:

Analise este ERP Delphi com centenas de units, identifique por que determinados DataModules permanecem em memória depois que seus Forms são destruídos, encontre possíveis referências circulares e proponha uma correção sem alterar o comportamento atual do sistema.

As duas solicitações envolvem programação, mas a semelhança praticamente termina aí.

No primeiro caso, temos tecnologias modernas, amplamente documentadas e com padrões de implementação relativamente conhecidos. Existem milhares de exemplos de APIs utilizando Node.js, TypeScript, Zod e Prisma. Um modelo atual não precisa realizar uma investigação particularmente sofisticada para produzir uma implementação adequada.

O segundo problema é completamente diferente. Antes de escrever qualquer código, o agente precisa compreender a estrutura do sistema, investigar dependências, analisar ciclo de vida de objetos, ownership, interfaces, eventos e possivelmente código escrito em diferentes épocas e estilos. A maior dificuldade não está em gerar Object Pascal sintaticamente correto. Está em compreender o que está acontecendo antes de alterar alguma coisa.

Isso demonstra uma característica importante da programação assistida por IA: gerar código e fazer engenharia de software não são exatamente a mesma coisa.

Quanto maior o projeto e mais complexas as relações entre suas partes, menos importante se torna simplesmente conhecer a sintaxe da linguagem e mais importante se torna a capacidade do modelo de investigar, relacionar informações, formular hipóteses, utilizar ferramentas e verificar se suas alterações realmente resolveram o problema.

É justamente por isso que utilizar um único modelo para todas as tarefas pode não ser a melhor estratégia.

Quanto custa cada modelo?

Antes de discutir capacidade, precisamos olhar para uma variável muito objetiva: preço.

Os valores mudam com frequência e cada fornecedor possui regras diferentes para cache, tamanho do contexto, processamento em lote e horários especiais. Portanto, a tabela abaixo deve ser entendida como uma fotografia das tarifas consideradas nesta análise em setembro de 2026.

O primeiro ponto que chama atenção é a enorme diferença entre os extremos. O DeepSeek V4 Flash trabalha em uma faixa de preço completamente diferente do GPT-6 Astra. Mesmo o DeepSeek V4 Pro, muito mais capaz para desenvolvimento cotidiano, permanece consideravelmente mais barato do que as opções mais poderosas da OpenAI.

Entretanto, precisamos tomar cuidado para não transformar essa tabela em um ranking de custo-benefício. Preço por token não significa preço por problema resolvido. Modelos diferentes podem consumir quantidades diferentes de tokens para chegar ao mesmo resultado e, principalmente, podem precisar de quantidades diferentes de tentativas.

Existe ainda outro detalhe importante: estamos comparando produtos que podem ser utilizados em ambientes diferentes. No caso da OpenAI, por exemplo, existe a integração direta com o Codex e todo o ambiente de execução do agente. DeepSeek e Gemini podem ser utilizados através de APIs e diferentes ferramentas de desenvolvimento, mas comparar apenas o preço dos tokens não significa necessariamente comparar toda a experiência oferecida pelo Codex.

Por isso, a tabela deve ser utilizada como referência econômica, e não como único critério de decisão.

Quanto custaria uma tarefa real?

Para tornar a diferença mais fácil de visualizar, vamos criar uma tarefa hipotética relativamente grande. Imagine que, durante a análise e implementação de uma funcionalidade, o agente consuma 100 mil tokens de entrada e 20 mil tokens de saída, sem considerar cache.

Aplicando as tarifas anteriores, teríamos aproximadamente:

Individualmente, nenhuma dessas quantias parece particularmente assustadora. Dois dólares para resolver um problema de programação podem ser irrelevantes quando comparados ao custo de uma hora de trabalho de um desenvolvedor. O problema aparece quando multiplicamos isso pelo uso diário de agentes, especialmente em equipes ou processos automatizados que executam centenas ou milhares de tarefas.

Se uma organização executar mil tarefas com exatamente esse perfil, a diferença teórica passa de aproximadamente US$ 210 utilizando DeepSeek V4 Pro para US$ 2.000 utilizando Astra. Evidentemente, isso não significa que ambos resolveriam as mesmas mil tarefas com a mesma qualidade ou utilizando exatamente a mesma quantidade de tokens. O exercício serve para mostrar o impacto que a escolha indiscriminada de um modelo pode ter em escala.

Isso nos leva a uma conclusão importante: o objetivo não deveria ser utilizar sempre o modelo mais barato nem sempre o modelo mais poderoso. Deveria ser utilizar o modelo mais barato capaz de resolver corretamente a tarefa.

Desenvolvimento web: onde os modelos baratos ficam muito interessantes

O desenvolvimento web moderno é um excelente exemplo de ambiente no qual modelos relativamente econômicos podem entregar resultados impressionantes. Tecnologias como Node.js, TypeScript, React, Next.js, Vue, NestJS, Express, Fastify, Prisma e PostgreSQL possuem documentação abundante, grandes comunidades e uma quantidade gigantesca de código público disponível.

Isso significa que muitas tarefas encontradas diariamente por um desenvolvedor são bastante familiares aos modelos atuais. Criar endpoints, implementar validações, construir componentes, escrever testes, gerar migrations, manipular JSON ou implementar regras de negócio relativamente isoladas são problemas que não exigem necessariamente o modelo mais sofisticado disponível.

Nesse cenário, DeepSeek V4 Pro, Gemini e GPT Terra tornam-se opções extremamente interessantes. Dependendo da ferramenta utilizada e da qualidade obtida no projeto específico, o custo pode cair significativamente sem uma perda perceptível de produtividade.

A situação começa a mudar quando a tarefa deixa de ser local e passa a exigir compreensão mais ampla do sistema. Uma refatoração envolvendo backend, frontend, banco de dados, autenticação e testes já exige mais capacidade de planejamento. Um bug de concorrência, uma inconsistência de estado distribuído ou uma alteração arquitetural atravessando vários módulos aumenta ainda mais a dificuldade.

Nesses casos, subir para GPT Sol ou Gemini Pro pode fazer sentido. E somente quando entramos em problemas realmente difíceis, com grande autonomia do agente e múltiplas etapas de investigação, o Astra começa a justificar de forma mais clara seu preço superior.

Portanto, para desenvolvimento web, eu não começaria automaticamente pelo modelo mais poderoso. Começaria por um modelo econômico e aumentaria a capacidade conforme a tarefa demonstrasse necessidade.

Delphi muda um pouco essa equação

Quando transportamos a mesma discussão para Delphi, minha estratégia seria um pouco diferente. Não porque os modelos atuais tenham dificuldade em escrever Object Pascal. Os principais modelos conseguem gerar código Delphi bastante competente, especialmente quando recebem contexto e instruções adequadas.

A diferença aparece quando trabalhamos com sistemas reais.

É bastante comum encontrar aplicações Delphi com dez, quinze ou vinte anos de evolução. Um ERP pode ter começado no Delphi 7, passado por várias versões da IDE, migrado componentes, incorporado novas bibliotecas e recebido centenas de alterações arquiteturais ao longo dos anos. O resultado é um sistema no qual diferentes gerações de código convivem lado a lado.

Podemos encontrar Forms contendo regras de negócio, DataModules gigantes, componentes próprios, bibliotecas de terceiros, FireDAC convivendo com tecnologias anteriores, diretivas condicionais, chamadas WinAPI, RTTI, interfaces, Generics e arquivos DFM com relações que não aparecem diretamente no código Pascal.

Em projetos assim, o maior desafio para uma IA não é saber escrever:

Query.ParamByName('ID').AsInteger := AID;

O desafio é descobrir qual Query deveria ser alterada, quem a cria, quem a destrói, quais Forms dependem dela, quais eventos estão associados, se existe outro DataModule compartilhando aquela conexão e quais consequências uma alteração aparentemente simples pode provocar no restante do sistema.

Quanto mais legado existe, mais a programação assistida por IA se transforma em um problema de compreensão e investigação.

Por isso, para Delphi eu tenderia a utilizar Sol como modelo padrão com maior frequência do que utilizaria em Node.js ou React. DeepSeek e Terra continuariam excelentes para tarefas mecânicas, SQL, pequenas classes, DTOs e alterações localizadas, mas eu subiria de modelo mais rapidamente quando o trabalho envolvesse arquitetura, FireDAC complexo, componentes, RTTI, ToolsAPI ou código legado.

Gemini e o problema dos grandes repositórios

Um aspecto particularmente interessante do Gemini é sua capacidade de trabalhar com janelas de contexto muito grandes. O Gemini 3.1 Pro pode trabalhar com até 1 milhão de tokens de contexto, o que abre possibilidades interessantes para análise de repositórios extensos.

É importante não interpretar isso como “podemos jogar um ERP inteiro no prompt e esperar que tudo seja resolvido”. Contexto grande não elimina a necessidade de selecionar informações relevantes, estruturar a investigação ou utilizar ferramentas adequadas. Entretanto, ele permite que o agente mantenha simultaneamente uma quantidade muito maior de informações sobre o sistema.

Em um projeto Delphi, por exemplo, isso poderia permitir analisar conjuntamente Forms, DataModules, Services, Repositories, arquivos DFM e determinadas bibliotecas internas. Em vez de observar apenas uma unit isoladamente, o modelo pode tentar construir uma representação mais ampla das relações existentes no projeto.

Essa característica sugere uma utilização interessante: Gemini como analista de grandes porções do repositório, enquanto outro modelo fica responsável por implementar alterações menores e bem especificadas.

E aqui chegamos ao ponto que considero mais interessante de toda essa comparação.

Por que utilizar apenas um modelo?

Quando trabalhamos manualmente com ChatGPT, Gemini ou outra interface, naturalmente pensamos em escolher um modelo e permanecer com ele durante toda a conversa. Entretanto, não existe razão técnica para que um agente de desenvolvimento precise seguir essa mesma lógica.

Podemos utilizar modelos diferentes para papéis diferentes.

Imagine que precisamos realizar uma grande refatoração. Um modelo com grande contexto poderia primeiro analisar o projeto, identificar dependências e criar um plano de execução. Esse plano poderia então ser entregue para um modelo muito mais barato implementar alterações específicas. Depois, outro modelo poderia revisar os patches produzidos. Se os testes falhassem ou surgisse um problema particularmente complexo, somente então um modelo mais poderoso seria chamado.

Teríamos algo conceitualmente semelhante a:

Essa arquitetura muda completamente a discussão.

Em vez de perguntar “qual é o melhor modelo para programar?”, começamos a perguntar:

“Qual é o melhor modelo para esta etapa específica do trabalho?”

Essa é uma pergunta muito mais interessante.

O modelo mais poderoso pode funcionar como especialista

Uma analogia com equipes humanas ajuda a compreender a ideia. Em uma equipe de desenvolvimento, não esperamos que o arquiteto ou especialista mais experiente execute cada alteração trivial do projeto. Existem tarefas que podem ser realizadas por profissionais com diferentes níveis de experiência, enquanto problemas críticos são escalados para quem possui maior capacidade de análise.

Com modelos de IA podemos fazer algo semelhante.

O DeepSeek pode funcionar como executor econômico. Gemini pode analisar grandes contextos. Sol pode atuar como engenheiro responsável por problemas mais complexos. Astra pode ser chamado somente quando o restante da “equipe” não consegue encontrar uma solução satisfatória.

Isso não significa que esses papéis sejam fixos ou que um modelo seja incapaz de desempenhar a função atribuída a outro. A ideia é simplesmente utilizar características e preços diferentes de forma estratégica.

Em outras palavras, não precisamos pagar pela inteligência máxima em cada token gerado.

Um roteador de modelos para desenvolvimento

Podemos levar essa ideia um passo adiante e imaginar uma camada responsável por escolher automaticamente o modelo. Vou chamá-la aqui de AI Code Router.

O desenvolvedor entrega uma tarefa ao sistema. Antes de executá-la, o roteador analisa alguns indicadores: tecnologia utilizada, quantidade de arquivos envolvidos, tamanho do contexto necessário, tipo de alteração, complexidade aparente e histórico de tentativas.

Uma tarefa simples poderia ser enviada diretamente para um modelo econômico. Uma tarefa envolvendo dezenas de arquivos poderia ir para Gemini ou Sol. Um problema arquitetural extremamente complexo poderia ser encaminhado diretamente para Astra.

Algo semelhante a:

As regras não precisariam depender apenas da descrição fornecida pelo usuário. O próprio agente poderia observar quantos arquivos precisa alterar, se existem testes, se houve erros de compilação, quantas tentativas já foram realizadas e até se está repetindo estratégias que já falharam.

Isso transforma a seleção de modelo em parte do processo de engenharia.

Escalonamento por falha pode ser ainda melhor

Existe, entretanto, um problema em tentar classificar antecipadamente a dificuldade de uma tarefa: nem sempre sabemos se ela realmente é difícil.

Um bug que parece complexo pode ser causado por uma condição simples. Uma alteração aparentemente trivial pode revelar dependências inesperadas e consumir horas de investigação.

Por isso, considero particularmente interessante uma estratégia de escalonamento progressivo.

Em vez de tentar prever perfeitamente qual modelo será necessário, começamos com uma opção econômica. O agente realiza a alteração, compila o projeto e executa os testes. Se tudo estiver correto, a tarefa termina. Se falhar, podemos subir para um modelo mais capaz, fornecendo não apenas a solicitação original, mas também tudo que já foi descoberto durante a tentativa anterior.

O fluxo poderia ser:

Essa estratégia possui uma característica econômica muito poderosa: compramos inteligência adicional somente quando a tarefa demonstra que precisa dela.

Além disso, o trabalho realizado pelo primeiro modelo não precisa ser perdido. Logs, erros, hipóteses descartadas e resultados dos testes podem ser repassados ao modelo seguinte, reduzindo o trabalho necessário para continuar a investigação.

Não use Astra para escrever CRUD

O GPT Astra pode ser extremamente valioso quando utilizado para investigar um problema que consumiria horas ou dias de trabalho humano. Nesse cenário, pagar alguns dólares por uma sessão de agente é praticamente irrelevante quando comparado ao valor do tempo economizado.

O desperdício acontece quando utilizamos essa mesma capacidade para tarefas que um modelo significativamente mais barato conseguiria resolver com facilidade. Criar um CRUD, adicionar um campo em uma API, escrever um teste unitário simples, gerar uma migration ou ajustar uma consulta SQL são exemplos de trabalhos nos quais o ganho obtido com um modelo muito mais caro pode ser praticamente imperceptível.

É importante perceber que estamos saindo de um mundo no qual o custo da IA era quase sempre irrelevante para um cenário em que agentes podem executar dezenas ou centenas de operações em sequência. Uma única tarefa pode abrir arquivos, pesquisar símbolos, reescrever trechos, executar testes, interpretar erros, modificar novamente o código e continuar trabalhando por vários ciclos. Quando isso é multiplicado por várias tarefas diárias, a escolha do modelo começa a ter impacto real no custo.

A lógica que considero mais saudável é simples: não utilizar menos inteligência do que a tarefa exige, mas também não comprar muito mais inteligência do que ela precisa.

O custo por token não é a métrica mais importante

As tabelas de preço são úteis, mas existe uma armadilha importante ao compará-las isoladamente. Quando olhamos apenas para o preço por milhão de tokens, somos naturalmente levados a considerar que o modelo mais barato terá sempre o menor custo operacional. Isso não é necessariamente verdade.

Imagine dois modelos.

O primeiro custa apenas US$ 0,20 para executar uma determinada tentativa, mas não consegue compreender completamente o problema. Ele produz uma alteração, os testes falham, tenta novamente, corrige um ponto e quebra outro. Depois de cinco ciclos, o custo total chegou a US$ 1,00 e ainda houve intervenção humana.

O segundo modelo custa US$ 0,60 por tentativa, mas compreende a arquitetura, identifica o problema corretamente e produz uma solução funcional logo na primeira execução.

Nesse caso, o modelo aparentemente mais caro terminou sendo mais barato.

Por isso, uma métrica muito mais interessante para agentes de desenvolvimento seria:

Custo por tarefa concluída com sucesso.

Podemos ir ainda além.

Uma tarefa não deveria ser considerada concluída simplesmente porque o modelo produziu código. Ela deveria atender a critérios objetivos de qualidade. Por exemplo: o projeto compila, os testes passam, os requisitos foram cumpridos, nenhuma regressão conhecida foi introduzida e não ficaram alterações incompletas pelo caminho.

Nesse cenário, a métrica ideal seria algo semelhante a:

Custo por tarefa concluída corretamente.

Essa diferença de perspectiva muda completamente a forma como analisamos modelos de IA para programação.

O custo da intervenção humana também precisa entrar na conta

Existe outra variável que raramente aparece nas tabelas: o tempo do desenvolvedor.

Suponha que um modelo barato produza uma solução razoável, mas exija vinte minutos de revisão e correção manual. Outro modelo custa alguns centavos a mais, porém entrega uma alteração que praticamente pode ser aprovada depois dos testes.

A diferença entre eles não está apenas no custo dos tokens. Está no tempo humano utilizado para corrigir, revisar e validar o resultado.

Para equipes de desenvolvimento, esse custo pode ser muito maior do que a própria API.

Isso significa que uma análise madura de custo deveria levar em consideração pelo menos quatro elementos:

• custo dos tokens;
• quantidade de tentativas;
• tempo de execução;
• tempo de intervenção humana.

Um sistema multimodelo realmente eficiente deveria tentar otimizar o conjunto dessas variáveis, não apenas escolher a API com menor preço.

DeepSeek: a camada agressiva de custo

O DeepSeek chama atenção principalmente porque opera em uma faixa de preço muito baixa quando comparado aos modelos premium. Isso o torna extremamente interessante para tarefas de execução, principalmente quando temos especificações claras e verificações automáticas.

Imagine um agente recebendo uma tarefa já bem definida:

Adicione o campo NCM ao cadastro de produtos, atualize o DTO, a migration, o schema de validação e os testes existentes.

Esse tipo de trabalho é bastante estruturado. O agente sabe onde precisa chegar e existe uma forma relativamente objetiva de verificar o resultado.

Nesse cenário, utilizar um modelo muito barato pode ser extremamente eficiente.

O DeepSeek também se torna interessante em atividades como geração de testes, pequenas refatorações, documentação, transformação de código, criação de estruturas repetitivas e implementação de tarefas previamente planejadas por outro modelo.

Isso cria um papel muito interessante para ele dentro de uma arquitetura multimodelo:

executor.

Não necessariamente o modelo responsável pelas decisões arquiteturais mais difíceis, mas aquele que recebe uma instrução bem definida e executa o trabalho pelo menor custo possível.

Gemini: contexto e análise como diferencial

Gemini ocupa uma posição diferente.

Além de apresentar um custo competitivo, a família Gemini possui modelos com janelas de contexto muito grandes e forte capacidade de trabalhar com código, ferramentas e tarefas agentic. Isso o torna especialmente interessante quando precisamos analisar uma grande quantidade de informações simultaneamente.

Em projetos grandes, esse comportamento pode ser muito valioso.

Imagine uma modernização de sistema em que precisamos compreender:

• camada de apresentação;
• serviços;
• acesso a dados;
• banco;
• testes;
• configurações;
• documentação;
• integrações externas.

Em vez de analisar cada arquivo isoladamente, um modelo com grande contexto pode manter uma visão mais ampla das relações existentes. Isso não significa que contexto grande resolve automaticamente todos os problemas, mas melhora a capacidade de preservar informações relevantes durante uma investigação extensa.

Para Delphi, particularmente em sistemas legados, isso pode ser bastante útil. Um projeto antigo pode possuir relações importantes espalhadas entre .pas, .dfm, DataModules, units utilitárias e bibliotecas próprias. Quanto mais dessas relações o agente consegue observar simultaneamente, maior a chance de construir uma interpretação coerente da aplicação.

Por isso, vejo Gemini desempenhando muito bem o papel de:

analista de grandes contextos e arquiteto auxiliar.

Terra: a opção econômica dentro do ecossistema OpenAI

O GPT Terra continua sendo uma opção relevante principalmente quando queremos permanecer completamente dentro do ecossistema OpenAI e do Codex.

Ele possui custo menor do que Sol e Astra e ainda entrega capacidade suficiente para uma grande quantidade de tarefas comuns de desenvolvimento. Para aplicações web, especialmente em tecnologias amplamente conhecidas, ele pode ser uma escolha bastante equilibrada.

O problema aparece quando ampliamos a comparação para um cenário multiprovedor. DeepSeek e Gemini passam a competir diretamente com ele em preço e capacidade, tornando sua posição menos evidente.

Isso não significa que Terra deixa de fazer sentido. Integração, confiabilidade do ambiente, experiência do Codex, ferramentas disponíveis e facilidade operacional também possuem valor.

Em outras palavras, escolher um modelo não significa simplesmente comprar tokens. Estamos escolhendo também o ambiente no qual esses tokens serão utilizados.

Sol: um excelente modelo para o trabalho sério do dia a dia

Entre os modelos da OpenAI analisados aqui, considero o Sol particularmente interessante porque ele ocupa uma região que faz muito sentido para desenvolvimento profissional.

Ele é mais caro do que as alternativas econômicas, mas ainda muito mais barato do que Astra. Ao mesmo tempo, possui capacidade suficiente para lidar com problemas significativamente mais complexos do que tarefas triviais de geração de código.

É justamente por isso que, para Delphi, eu tenderia a utilizá-lo com bastante frequência.

Quando estamos trabalhando com FireDAC, componentes próprios, arquitetura de aplicações VCL ou FMX, integrações fiscais, código legado ou refatorações envolvendo múltiplas units, vale pagar um pouco mais por um modelo que tenha maior capacidade de compreensão e investigação.

Para desenvolvimento web, eu provavelmente utilizaria Sol de forma mais seletiva. Para Delphi, ele pode facilmente se tornar o modelo padrão.

Essa diferença não está relacionada apenas à linguagem. Está relacionada ao tipo de problema encontrado em cada ecossistema.

Astra: o especialista que entra quando o problema ficou realmente difícil

O GPT Astra faz mais sentido quando tratamos a IA como um especialista de alto nível.

Uma grande migração, um bug que atravessa dezenas de módulos, uma refatoração arquitetural, uma investigação de concorrência ou um sistema legado com relações difíceis de mapear são situações nas quais sua capacidade adicional pode justificar o preço.

O erro seria confundir “modelo mais poderoso” com “modelo que deve ser utilizado sempre”.

Um especialista humano não é utilizado para preencher cada campo de uma tela ou escrever toda função trivial de um sistema. Ele entra justamente onde sua experiência produz maior retorno.

Eu aplicaria a mesma lógica ao Astra.

Se DeepSeek, Gemini ou Sol resolveram o problema, não existe motivo para continuar escalando. Se não resolveram, então o custo adicional começa a se justificar.

Como eu estruturaria o desenvolvimento web

Depois de analisar preço, capacidade e tipo de trabalho, uma estratégia prática para desenvolvimento web poderia ser semelhante a esta:

Node.js, TypeScript, React, Vue, Next.js, NestJS, Prisma e tecnologias semelhantes estão muito bem representados nos modelos atuais. Por isso, existe espaço para utilizar modelos econômicos em uma parcela grande das tarefas sem comprometer a produtividade.

O modelo mais caro entraria principalmente quando surgisse a necessidade de investigar arquitetura, comportamento inesperado, condições de corrida, grandes refatorações ou mudanças atravessando várias partes da aplicação.

Como eu estruturaria o desenvolvimento Delphi

Para Delphi, minha pirâmide seria um pouco diferente:

Aqui eu manteria Sol no centro da operação.

DeepSeek continuaria excelente para tarefas mecânicas, geração de código, SQL, pequenas classes e alterações localizadas. Gemini poderia ser especialmente útil para análise ampla de grandes projetos. Astra ficaria reservado para os problemas nos quais todo o restante já demonstrou dificuldade.

Essa estratégia é especialmente interessante em projetos Delphi porque nem sempre uma alteração aparentemente pequena é realmente local. Um método pode depender de um componente configurado no DFM, que dispara um evento em um DataModule, que utiliza uma conexão compartilhada e possui dependências históricas com outras partes do sistema.

Nesses casos, capacidade de investigação vale mais do que simples velocidade de geração.

Um agente pode usar vários modelos na mesma tarefa

Talvez esta seja a ideia mais importante de todo o artigo.

Não precisamos necessariamente escolher um modelo antes da tarefa e permanecer presos a ele até o fim.

Imagine que o sistema receba uma especificação para modernizar determinada parte de um ERP.

O processo poderia começar com Gemini analisando uma grande quantidade de código e criando um mapa das dependências. Sol poderia revisar esse plano e identificar riscos. DeepSeek poderia executar várias alterações mecânicas. Um modelo econômico poderia gerar testes adicionais. Somente se surgisse um problema particularmente difícil Astra seria chamado.

Isso poderia ser representado assim:

Essa arquitetura lembra muito mais uma equipe do que uma simples chamada para um chatbot.

E talvez seja exatamente nessa direção que os agentes de programação estejam caminhando.

O AI Code Router

Podemos transformar essa ideia em uma camada específica responsável pelo roteamento dos modelos.

Um AI Code Router poderia receber a tarefa e analisar informações como:

• linguagem e framework;
• tamanho do repositório;
• quantidade de arquivos afetados;
• existência de testes;
• complexidade da alteração;
• necessidade de contexto longo;
• quantidade de tentativas anteriores;
• erros de compilação;
• falhas nos testes;
• custo acumulado.

Com base nessas informações, o roteador poderia escolher automaticamente o modelo mais adequado.

Uma configuração hipotética poderia ser semelhante a:

routing:
  trivial:
    model: deepseek-v4-flash

  simple:
    model: deepseek-v4-pro

  normal:
    model: gemini-pro

  complex:
    model: gpt-sol

  expert:
    model: gpt-astra

escalation:
  build_failure: true
  test_failure: true
  repeated_failure: 2
  architecture_problem: true

A configuração ainda poderia variar por projeto.

Um projeto Node.js poderia começar pelo DeepSeek. Um grande ERP Delphi poderia começar pelo Sol. Um repositório enorme poderia utilizar Gemini na etapa de análise.

Ou seja, a escolha do modelo passa a fazer parte da configuração da engenharia do projeto.

Não precisamos decidir tudo antes da execução

Existe uma abordagem ainda mais interessante: deixar o próprio sistema aprender quais modelos funcionam melhor em cada tipo de tarefa.

Imagine que o agente registre informações como:

Tipo: CRUD Node.js
Modelo: DeepSeek V4 Pro
Tentativas: 1
Testes: OK
Custo: US$ 0,18

Em outra tarefa:

Tipo: Refatoração Delphi legado
Modelo: DeepSeek V4 Pro
Tentativas: 4
Resultado: falhou

Modelo: Sol
Tentativas: 1
Resultado: sucesso

Depois de centenas de execuções, o roteador poderia descobrir padrões reais do próprio ambiente.

Talvez percebesse que DeepSeek resolve 95% dos CRUDs de primeira. Gemini funciona melhor em grandes análises. Sol possui melhor taxa de sucesso em FireDAC. Astra só é necessário em uma pequena parcela das tarefas.

Nesse momento, a escolha do modelo deixa de ser uma opinião e passa a ser baseada em dados.

Esse, para mim, seria um dos usos mais interessantes de uma arquitetura multimodelo.

O benchmark que realmente interessa pode ser o seu próprio projeto

Benchmarks públicos são importantes. Eles ajudam a comparar capacidade de raciocínio, programação, uso de ferramentas e desempenho geral.

Mas nenhum benchmark conhece seu código.

Nenhum deles sabe como funciona seu ERP, quais frameworks sua equipe utiliza, como os testes são estruturados ou quais padrões arquiteturais existem no seu projeto.

Por isso, para uma empresa ou desenvolvedor que utiliza IA intensamente, talvez faça sentido construir um benchmark próprio.

Podemos separar uma coleção de tarefas reais:

• corrigir determinado bug;
• implementar uma feature;
• adicionar um endpoint;
• refatorar uma classe;
• criar testes;
• corrigir um problema FireDAC;
• modernizar uma unit Delphi;
• alterar uma aplicação React.

Executamos essas tarefas com diferentes modelos e medimos:

• sucesso na primeira tentativa;
• quantidade de tokens;
• custo;
• tempo;
• testes aprovados;
• necessidade de intervenção humana.

Isso produziria uma resposta muito mais útil do que simplesmente perguntar qual modelo lidera determinado ranking público.

A pergunta passa a ser:

Qual modelo funciona melhor no meu código?

E o cache muda bastante a economia

Outro elemento importante em agentes de programação é o cache de contexto.

Quando trabalhamos várias vezes no mesmo repositório, grandes partes do contexto podem ser reutilizadas. Arquivos, instruções, documentação e informações arquiteturais aparecem repetidamente em diferentes tarefas.

Os fornecedores cobram valores significativamente menores para tokens reaproveitados via cache. Isso significa que agentes capazes de reutilizar contexto de forma eficiente podem reduzir substancialmente o custo total.

Esse fator também reforça uma conclusão importante: comparar apenas o preço nominal da entrada e da saída não é suficiente.

A arquitetura do agente influencia diretamente quanto custa utilizar determinado modelo.

Modelos baratos também permitem novas estratégias

Existe ainda um efeito secundário interessante do barateamento dos modelos.

Quando uma execução custa muito pouco, podemos utilizar IA em situações nas quais anteriormente não valeria a pena.

Por exemplo, podemos ter agentes especializados apenas em:

• revisar SQL;
• escrever testes;
• procurar problemas de segurança;
• revisar documentação;
• analisar naming;
• verificar padrões arquiteturais;
• detectar duplicações;
• revisar migrations.

Em vez de pedir para um único modelo caro fazer tudo, podemos criar vários pequenos agentes especializados utilizando modelos baratos.

Isso transforma custo baixo em paralelismo.

Um agente principal implementa a feature enquanto outros revisam aspectos específicos da alteração.

No final, um modelo mais capaz pode consolidar os resultados apenas quando necessário.

Desenvolvimento com IA começa a parecer infraestrutura

Essa mudança é importante porque altera o papel da IA dentro do desenvolvimento.

Hoje ainda pensamos muito em IA como uma ferramenta individual: abrimos o Codex, escolhemos um modelo e fazemos uma solicitação.

Mas, à medida que os agentes se tornam mais autônomos, a IA começa a parecer uma camada de infraestrutura.

Passamos a pensar em:

• roteamento;
• fallback;
• observabilidade;
• custo;
• cache;
• testes;
• escalonamento;
• especialização;
• métricas de qualidade.

São conceitos muito semelhantes aos que já utilizamos em sistemas distribuídos e infraestrutura de software.

A diferença é que agora estamos distribuindo raciocínio e capacidade de engenharia entre diferentes modelos.

Então qual é o melhor modelo para programar?

Depois de toda essa análise, minha resposta seria:

depende da tarefa.

Essa resposta pode parecer pouco satisfatória, mas é justamente a conclusão mais importante.

DeepSeek oferece uma relação de custo extremamente agressiva e pode ser excelente como executor.

Gemini combina forte capacidade de programação com contexto grande e pode funcionar muito bem em análise e tarefas agentic.

Terra oferece uma alternativa econômica dentro do ecossistema OpenAI.

Sol ocupa uma posição muito interessante para desenvolvimento profissional mais complexo.

Astra entrega capacidade adicional para problemas nos quais modelos menores começam a encontrar limites.

Nenhum deles precisa substituir completamente os outros.

Eles podem trabalhar juntos.

Minha estratégia hoje

Se estivesse montando uma infraestrutura de desenvolvimento assistido por IA hoje, eu provavelmente começaria com algo próximo disso.

Para desenvolvimento web:

Para Delphi:

Não interprete essa tabela como uma regra universal. Ela representa a estratégia que considero mais racional com base nas características e custos analisados.

O ideal é medir isso dentro do próprio projeto.

Conclusão

A disputa entre GPT, Gemini e DeepSeek normalmente é apresentada como se precisássemos escolher um vencedor.

Acredito que essa visão ficará rapidamente ultrapassada.

À medida que os agentes de desenvolvimento se tornam mais sofisticados, faz cada vez menos sentido perguntar qual é o único modelo que devemos utilizar. A pergunta mais interessante passa a ser como combinar modelos diferentes para maximizar qualidade e minimizar custo.

Modelos baratos podem executar tarefas mecânicas. Modelos com grandes contextos podem analisar repositórios. Modelos mais sofisticados podem resolver problemas arquiteturais. Modelos premium podem entrar somente quando os demais não conseguirem avançar.

O resultado é uma espécie de equipe artificial:

Não significa que esses papéis sejam rígidos. O importante é a ideia por trás deles.

Não precisamos usar a inteligência máxima disponível o tempo todo. Precisamos utilizar a quantidade adequada de inteligência para cada problema.

Quando essa escolha passa a ser automática, podemos chegar a um modelo de desenvolvimento no qual o próprio agente decide quando vale a pena gastar mais para pensar melhor.

Talvez essa seja uma evolução tão importante quanto o surgimento de modelos mais poderosos.

Porque, no final, a pergunta deixa de ser:

“Qual IA programa melhor?”

e passa a ser:

“Qual é a forma mais eficiente de combinar diferentes IAs para construir software melhor?”

E essa segunda pergunta provavelmente será muito mais importante nos próximos anos.

Agora o artigo está fechado e com a linha de raciocínio completa. Eu manteria essa versão longa para o blog, porque o assunto merece profundidade e a parte de AI Code Router + escalonamento por custo e falha diferencia o artigo de um comparativo superficial de preços.