Durante bastante tempo, minha forma de trabalhar com IA no desenvolvimento de software foi altamente integrada. Eu começava explicando o que queria construir, discutia requisitos funcionais e não funcionais, arquitetura, padrões de código e testes e, quando fazia sentido, mostrava exemplos do resultado esperado. Ao mesmo tempo, o agente podia explorar o projeto, consultar o código existente e começar a aplicar as decisões que surgiam durante a conversa.
Era uma experiência muito conveniente. Pensar sobre o problema e trabalhar sobre o código aconteciam praticamente no mesmo fluxo. Se alguma característica da implementação contrariasse uma hipótese levantada durante a discussão, a conversa se ajustava ao que havia sido encontrado e seguia adiante.
Os benefícios que eu percebia nem sempre apareciam como produtividade no sentido mais simples de “fazer a mesma coisa mais rápido”. Havia ganho de velocidade, sem dúvida, mas parte desse tempo economizado acabava sendo reinvestida no próprio software: discutir melhor uma decisão arquitetural, considerar alternativas que talvez fossem ignoradas sob pressão de prazo, criar mais testes, melhorar o tratamento de erros, rever interfaces e dedicar mais atenção à robustez da solução.
Repensando o workflow
Há algum tempo, as ferramentas disponíveis e a minha forma de trabalho mudaram. Em alguns projetos, eu uso o ChatGPT principalmente como espaço de conversa, inclusive para discutir arquitetura e soluções de software; em outros, uso o Codex para trabalhar diretamente sobre os repositórios.
A partir daí, comecei a notar um padrão: conversas complexas e longas no ChatGPT estavam consumindo menos créditos do que tarefas aparentemente simples realizadas pelo Codex, usando configurações comparáveis de modelo e nível de raciocínio. Quando eu conversava muito com o Codex, a diferença de consumo aumentava ainda mais.
Na forma como eu estava usando o Codex, a tarefa não se limitava à conversa. Ele examinava o projeto, lia arquivos, acompanhava dependências, executava ferramentas, testava alterações e podia voltar ao código várias vezes. Modelo, contexto, raciocínio e uso de ferramentas participavam do consumo, ainda que boa parte desse trabalho não aparecesse diretamente na interação.
Essa diferença de custo me levou a uma pergunta simples:
Se boa parte da exploração de uma solução já pode acontecer no ChatGPT, quanto dessa exploração precisa acontecer dentro do Codex?
Reavaliando o contexto
Uma sessão de desenvolvimento cresce rapidamente. Ao longo do trabalho, ela acumula decisões, código, resultados de comandos, erros, testes, explicações e caminhos que foram considerados e depois abandonados.
Compactação de contexto, handoffs e novas sessões continuam sendo úteis para administrar esse histórico. Essas técnicas, porém, atuam principalmente depois que o contexto já foi produzido. Passei a me perguntar quanto dele poderia simplesmente nascer fora da sessão do Codex.
Imagine uma discussão sobre uma decisão arquitetural. Durante a conversa, quatro alternativas são consideradas. Uma parece promissora no início, outra revela um problema, um requisito muda e finalmente surge uma solução diferente das primeiras opções. Toda essa exploração foi útil para chegar à decisão. Depois que ela existe, aquilo que precisa chegar ao Codex pode ser muito menor: a solução escolhida, algumas restrições e o comportamento esperado.
Foi aí que passei a separar duas coisas: descobrir o que fazer e trabalhar sobre o código para fazer aquilo funcionar.
Isso não elimina o contexto que o próprio Codex produz durante a implementação. Mesmo uma tarefa bem definida pode exigir exploração do projeto, testes, correções e várias iterações. A diferença é que compactação, handoffs e novas sessões passam a lidar principalmente com o histórico gerado pelo trabalho sobre o repositório, enquanto boa parte da exploração anterior nem chega a entrar nessa sessão.
Separando descoberta e implementação
Passei então a usar o ChatGPT como o espaço principal para a parte mais exploratória do trabalho. É ali que posso discutir uma ideia, abandoná-la, comparar arquiteturas, questionar requisitos, voltar atrás e tentar outro caminho. A conversa pode ser longa porque seu objetivo ainda é descobrir uma direção.
Quando essa direção fica suficientemente clara, transformo o resultado em uma tarefa para o Codex. Ele trabalha diretamente sobre o repositório, executa as validações previstas e gera um snapshot, uma cópia do estado do código naquele momento. A resposta do Codex e esse snapshot voltam para o mesmo contexto do ChatGPT que produziu a tarefa.
O workflow fica mais ou menos assim:
exploração → decisão → tarefa → implementação → revisão
Quando necessário, a revisão gera ajustes que retornam à implementação.
A revisão feita no ChatGPT é essencialmente uma validação estática do código. Como a conversa que originou a tarefa ainda está no contexto, posso apresentar a resposta do Codex junto com o snapshot do código e pedir que o ChatGPT confira se decisões, restrições e comportamentos esperados aparecem na implementação. A resposta também acrescenta informações que não existiam antes da execução: resultados de testes, erros encontrados, limitações do ambiente ou premissas que não se confirmaram na prática.
Essas informações podem revelar uma restrição não atendida, uma decisão interpretada de outra forma ou um aspecto do problema que ainda não havia sido considerado. Os ajustes retornam ao Codex, que altera o código e executa novamente as verificações necessárias. Em alguns casos, o próprio resultado obriga a rever o que havia sido definido. O ciclo continua até que a implementação e as decisões revisadas estejam consistentes entre si.
Dentro do repositório, o Codex ainda precisa compreender o código existente, encontrar os pontos corretos de alteração, perceber dependências, adaptar a solução, executar testes e resolver os problemas encontrados. A diferença é que ele começa a trabalhar quando algumas das decisões mais abertas já foram tomadas.
Passei a pensar nisso como uma espécie de compressão antes da implementação. A conversa exploratória pode ser grande porque o caminho até uma boa decisão raramente é linear. O resultado da conversa, por sua vez, costuma ser muito menor que a conversa que o produziu. É esse resultado que passa de uma ferramenta para a outra.
A mesma separação vale para os modelos
Quando passei a enxergar exploração, implementação e revisão como atividades diferentes, percebi que a escolha do modelo também não precisava valer para o workflow inteiro.
Posso, por exemplo, usar o GPT-5.6 Sol no ChatGPT para a exploração e o GPT-5.6 Luna no Codex para a implementação. Cada etapa passa a usar um modelo escolhido de acordo com o tipo de trabalho realizado.
Na tabela de créditos vigente enquanto escrevo, em agosto de 2026, esses modelos têm custos bastante diferentes por milhão de tokens. Faço essa comparação em uma assinatura ChatGPT Business, usando o ChatGPT na interface web e no aplicativo para desktop e o Codex para trabalhar sobre os repositórios. Esses números refletem o ambiente que eu estava usando naquele momento.
Na minha experiência, a diferença de custo entre os modelos se somou ao maior volume de uso que vinha observando no Codex. Passei a atribuir a economia menos à interface em si e mais ao modo como distribuía o trabalho. Na prática, eu via essa economia aparecer em dois lugares: no contexto exploratório que deixava de levar para a implementação e na possibilidade de escolher um modelo diferente para cada atividade.
Em vez de olhar para uma sessão inteira como a unidade a ser otimizada, passei a olhar para uma sequência de atividades, cada uma com seu contexto e suas necessidades.
O que mudou?
Uma discussão longa pode ser exatamente o que ajuda a chegar a uma solução melhor. O ponto não é reduzir a conversa por si só, e sim evitar transportar automaticamente toda essa conversa para uma etapa que precisa principalmente do resultado dela.
Ao preparar uma tarefa para o Codex, procuro levar adiante aquilo que sobreviveu à exploração: decisões, restrições, comportamento esperado e o contexto necessário para a implementação. O Codex produz então o contexto próprio do trabalho sobre o repositório, e o resultado volta ao ChatGPT com as informações necessárias para a revisão.
Não é uma busca pelo menor prompt possível. É uma busca pelo contexto suficiente para cada etapa.
A ideia que deu origem a esse experimento continua simples:
Antes de tentar reduzir o contexto de uma sessão, vale perguntar quanto daquele contexto precisava estar nela.
Ideias relacionadas
Spec-Driven Development tem em comum com esse workflow a separação entre definição e implementação. Na forma como tenho trabalhado, porém, a definição é mais informal, conversacional e incremental: não começo necessariamente produzindo uma especificação; começo discutindo o problema, e parte dessa conversa pode se transformar em uma tarefa quando as decisões se estabilizam.
Loop Engineering se aproxima ainda mais do ciclo de implementação, revisão e ajustes, no qual agentes executam tarefas, os resultados são verificados e novas ações são disparadas em direção a um objetivo. Neste momento, porém, faço manualmente a orquestração entre o ChatGPT, que ajuda a definir a tarefa e revisa o resultado, e o Codex, que implementa e executa as validações dinâmicas.
Embora este relato trate de ChatGPT e Codex, essas foram apenas as ferramentas que usei. Presumo que um arranjo semelhante possa ser reproduzido com outras combinações, desde que uma ferramenta sustente a exploração e a revisão e outra consiga atuar sobre o repositório, executar ferramentas e realizar validações dinâmicas.
Sobre o autor
Jorge Ramos
Engenheiro de Software | Prill Tecnologia
Glossário
Agente — Sistema capaz de combinar um modelo de IA, contexto e ferramentas para realizar uma tarefa, observar os resultados e ajustar suas próximas ações.
ChatGPT — Produto da OpenAI usado neste relato como espaço principal para exploração, discussão de requisitos, decisões arquiteturais e revisão do resultado.
ChatGPT Business — Plano da OpenAI usado neste relato para acessar o ChatGPT e o Codex.
Codex — Ferramenta de desenvolvimento de software capaz de trabalhar diretamente sobre repositórios, ler e alterar arquivos, executar comandos, usar ferramentas e realizar testes.
Compactação de contexto — Redução do histórico acumulado, preservando o que ainda é necessário para continuar o trabalho.
Contexto — Informações disponíveis para o modelo em uma interação: conversa, instruções, código, arquivos e resultados de ferramentas.
Crédito — Unidade usada para contabilizar o consumo dentro do plano. A quantidade necessária pode variar conforme o modelo e o tipo de trabalho executado.
Handoff — Resumo do estado atual usado para continuar o trabalho em outra sessão ou ferramenta.
Modelo — Modelo de IA escolhido para processar uma interação ou executar uma tarefa. Modelos diferentes podem apresentar características distintas de capacidade, velocidade e consumo.
Snapshot — Cópia do estado do código em determinado momento, usada neste workflow para levar a implementação de volta ao ChatGPT para revisão.
Token — Unidade em que textos e outros conteúdos são divididos para serem processados pelo modelo e contabilizados no uso.