Técnicas Avançadas e Aceleração: O que atrasa você não é o modelo, é o contexto ruim que você fornece

📚 Navegação da Série: O artigo anterior "30 Como Escolher o Modelo" falou sobre "qual modelo enviar para a mesma instrução e com qual intensidade de inferência executá-lo". Este artigo vai mais longe — apenas escolher o modelo certo não é suficiente. O que realmente determina quanto trabalho você consegue fazer em um dia é como você alimenta o contexto, como gerencia as sessões e como executa várias linhas de trabalho simultaneamente. O próximo artigo "32 Migrando do Claude Code" falará sobre como os usuários antigos podem migrar suavemente.

No final do artigo anterior, deixei uma frase: Muitas vezes, o que atrasa você não é o fato de o modelo não ser forte o suficiente, mas sim o contexto muito bagunçado que você fornece, fazendo com que ele siga pelo caminho errado. Este artigo veio para pagar essa dívida.

Primeiro, deixe-me mostrar a minha própria conta. Em março de 2025, eu estava fazendo uma pequena ferramenta em Python, e uma funcionalidade me fez ir e voltar com o Codex a tarde inteira — mais tarde consultei o histórico de sessões do /status e contei: só essa demanda rodou 11 rodadas. Durante esse tempo, ele alterou o arquivo errado duas vezes e, de quebra, "otimizou" uma configuração que eu não tinha pedido para ele mexer. Ao revisar, percebi: não era que o gpt-5.5 fosse ruim, era que na minha primeira frase eu apenas soltei um "me ajude a adicionar uma função de exportação", e as outras dez rodadas foram todas para complementar o contexto que eu deveria ter explicado claramente de primeira.

Para ser sincero, a maior lentidão na programação com AI nunca são os poucos segundos que o modelo leva para processar, mas sim o retrabalho. Se você não explicar claramente na primeira vez, ele pegará um caminho errado, você terá que trazê-lo de volta, e três idas e vindas custam meia hora. Por mais rápido que seja o modelo, ele não supera as rodadas economizadas ao "fazer certo de primeira".

Este artigo não vai te ensinar nenhuma fórmula mística, mas sim seis ações práticas que podem reduzir drasticamente o retrabalho e fazer com que todo o fluxo de trabalho corra bem.

Ao terminar de ler este artigo, você obterá:

• Uma mentalidade de aceleração contraintuitiva: Menos retrabalho > Buscar velocidade cegamente, fazer certo de primeira é a forma de "rapidez" que mais economiza tempo
• Uma receita fixa para um "bom prompt": Objetivo + Contexto + Restrições + Critérios de Aceitação, acompanhado de uma tabela comparativa de prompts Antes/Depois
• Três técnicas para gerenciar a janela de contexto: compactação com /compact, abrir uma nova sessão quando necessário e usar @ para enviar arquivos de forma precisa em vez de carregar todo o repositório
• Uma mentalidade de reduzir a marcha conforme a tarefa para economizar tempo e dinheiro (continuação da escolha de modelos do artigo anterior)
• Abordagens avançadas para executar várias linhas de trabalho em paralelo e deixar o Codex se auto-validar
• Um exercício prático que você pode fazer imediatamente: reescrever uma demanda vaga no formato de quatro seções e ver com os próprios olhos a taxa de retrabalho cair

⚠️ Os comandos, chaves de configuração e comportamentos padrão deste artigo baseiam-se na documentação oficial do Codex; nomes de modelos, multiplicadores de créditos (credit, unidade de cobrança para conversão de uso no Codex), /fast, etc., mudarão com as versões, prevalecendo o que estiver no seu codex --help local e na documentação oficial.

---

01 A Essência da Aceleração: Menos Retrabalho, Não Busca Cega por Velocidade

Primeiro alinhe sua mentalidade, caso contrário, todas as técnicas seguintes serão em vão.

Quando os iniciantes pensam em "acelerar", a primeira reação costuma ser "mudar para um modelo mais rápido", "reduzir a intensidade da inferência" ou "ativar um modo acelerado". Falaremos sobre isso mais tarde, mas esses são detalhes secundários. O grande gargalo é o retrabalho.

Analogia: Cozinhar. Se você demora para preparar um prato, raramente é porque o fogo está baixo. Geralmente é porque, no meio do corte, percebeu que esqueceu de comprar a cebolinha, colocou sal demais e teve que recomeçar, ou errou o passo da receita. O que realmente consome tempo são esses momentos de "começar do zero", não o tamanho da chama. Aumentar o fogo ao máximo não vai salvar um cozinheiro que cozinha e refaz o trabalho ao mesmo tempo.

Na programação com AI é exatamente igual. Se o Codex pegar um caminho errado, alterar o arquivo incorreto ou entender mal sua intenção, você precisará trazê-lo de volta e repetir — o custo desse vai e vem supera muito o fato de ele pensar por mais alguns segundos.

Há uma frase na documentação oficial que me marcou bastante, que significa: o Codex produz uma qualidade visivelmente superior quando consegue validar o seu próprio trabalho. Em outras palavras, garantir que ele acerte de primeira e com segurança é muito mais importante do que fazê-lo ir rápido.

Eu mesmo tive uma experiência muito típica. No final do ano passado, pedi para ele "otimizar esta função", sem dizer o que otimizar, o que não tocar e o que contaria como uma otimização bem-sucedida. Ele reescreveu a função com entusiasmo, alterou a assinatura da minha interface no processo, e todos os três chamadores retornaram erros. Levei vinte minutos para arrumar a bagunça que ele havia gerado ao "otimizar". Depois dessa vez, defini uma regra rígida: nunca usar o termo vago "otimizar", prefiro digitar mais duas linhas de texto.

Lembre-se desta ordem; as próximas cinco seções detalharão cada um desses aspectos:

O que você acha que é acelerar	Aceleração real
❌ Mudar para um modelo mais rápido sem pensar	✅ Explicar claramente na primeira frase, reduzindo as rodadas de retrabalho
❌ Diminuir a intensidade da inferência sem critério apenas por velocidade	✅ Alinhar o poder computacional com a dificuldade da tarefa (mencionado no artigo anterior)
❌ Enviar o projeto inteiro para ele ler	✅ Usar @ para alimentar com precisão os arquivos relevantes
❌ Manter uma única sessão aberta do início ao fim do dia	✅ Uma sessão por tarefa, compactando ou iniciando uma nova a tempo
❌ Verificar linha por linha visualmente após a alteração	✅ Fornecer critérios de aceitação e deixá-lo executar os testes para validação

💡 Resumo em uma frase: A maior lentidão na programação com AI é o retrabalho; o princípio fundamental da aceleração é "fazer certo de primeira", e não "rodar mais rápido".

---

02 Forneça Contexto Suficiente, Não o Deixe Adivinhar: A Receita Fixa de um Bom Prompt

Na seção anterior, dissemos que o retrabalho é o grande vilão. De onde ele vem? A esmagadora maioria vem de não explicar as coisas claramente na primeira frase, forçando o Codex a adivinhar. Quando ele adivinha, há uma chance de errar a direção, e você terá que refazer o trabalho.

Analogia: Observações no pedido de delivery. Se você escrever apenas "quero um arroz frito", o motoboy e a cozinha farão o padrão — pode vir com cebolinha, apimentado ou salgado. Se você escrever "arroz frito de Yangzhou, sem cebolinha, pouco apimentado, arroz mais macio", virá correto de primeira. O mesmo vale para as instruções ao Codex: cada palavra que você economiza é algo que ele terá de adivinhar. Se ele adivinha errado, você terá retrabalho.

A equipe oficial forneceu em suas "Melhores Práticas" uma receita que adoto até hoje. Um bom prompt, por padrão, contém estes quatro elementos:

• Objetivo (Goal): O que você realmente quer alterar ou criar?
• Contexto (Context): Quais arquivos, documentações ou erros estão relacionados a isso? Use o @ para indicá-los.
• Restrições (Constraints): Quais padrões ou arquiteturas devem ser seguidos? O que não deve ser tocado?
• Critérios de Aceitação (Done when): Sob qual condição o trabalho é considerado concluído? Testes executados, comportamento alterado, bug não reproduzível?

Não é necessário preencher detalhadamente todos esses quatro itens sempre, mas o Objetivo e os Critérios de Aceitação quase nunca podem ser omitidos. Hoje em dia, mesmo com pressa, passo por esses quatro campos mentalmente antes de enviar uma instrução.

A tabela comparativa abaixo foi baseada em prompts ruins que eu mesmo escrevi no passado e reescrevi depois, para que você perceba a diferença:

❌ Before (Vago, retrabalho garantido)	✅ After (Formato de quatro seções, alta chance de sucesso de primeira)
Me ajude a adicionar uma função de exportação	Objetivo: Adicionar uma função ao report.py para exportar relatórios como CSV. Contexto: Consultar a implementação existente em @export/json_export.py. Restrições: Reutilizar a classe de dados Report existente e não alterar seus campos. Aceitação: Capaz de exportar CSV com cabeçalhos e passar no tests/test_export.py
Esta função está um pouco lenta, otimize-a	Objetivo: Reduzir o tempo de search() de 2 segundos para menos de 200ms em 10 mil registros. Contexto: A função está em @core/search.py. Restrições: Não alterar a assinatura da função e a estrutura de retorno. Aceitação: Rodar pytest tests/test_search.py::test_perf e passar na asserção de tempo de execução < 0.2s
Corrija este bug	Objetivo: Corrigir o problema de redirecionamento para tela em branco após o login. Contexto: Os passos de reprodução são "digitar usuário e senha corretos → clicar em entrar → tela em branco", com o código relacionado em @auth/login.py. Restrições: Não alterar a lógica de verificação de permissões. Aceitação: Passar novamente pelos passos de reprodução e acessar a página inicial normalmente

Percebeu a diferença? O lado direito não é mais prolixo; ele apenas complementa as informações que já estavam na sua cabeça, mas que você teve preguiça de digitar. Se você não as fornecer, o Codex terá que adivinhar; se você as fornecer, ele irá direto ao ponto.

Quando revisei aquela pequena ferramenta em Python, calculei que, para a mesma demanda, eu precisava de 5 a 8 rodadas em média usando a abordagem da esquerda. Com o formato de quatro seções da direita, na maioria das vezes resolvia em 1 ou 2 rodadas. As duas linhas adicionais digitadas economizaram três idas e vindas posteriores.

Outro truque preguiçoso, mas eficaz: se a tarefa for muito difícil e você mesmo não souber como描述它时，别硬写，让 Codex 先帮你理。 (Wait! Let me check the translation for "如果你自己都没想清楚怎么描述时，别硬写，让 Codex 先帮你理" -> "se a tarefa for muito difícil e você mesmo não souber como descrevê-la, não tente forçar; deixe o Codex ajudar a estruturá-la primeiro." Let me correct this sentence carefully.) A documentação oficial recomenda usar o modo de plano (Plan mode), alternando com /plan ou Shift+Tab na CLI. Ele primeiro coletará o contexto, fará algumas perguntas adicionais e listará uma proposta de solução, aguardando sua aprovação antes de iniciar o código. Em vez de deixá-lo programar de forma incorreta por conta de um mal-entendido, gaste um minuto para que ele estruture a proposta de solução primeiro.

💡 Resumo em uma frase: Um bom prompt = Objetivo + Contexto + Restrições + Critérios de Aceitação. Cada palavra que você economiza é algo que o Codex terá de adivinhar. Se ele adivinhar errado, você terá retrabalho.

---

03 Gerencie a Janela de Contexto: Não Carregue o Repositório Inteiro

A segunda seção resolveu a questão de "explicar claramente", esta seção resolve a questão de "não falar demais". Embora pareçam contraditórias, não são — o objetivo é incluir todas as informações relevantes e descartar as irrelevantes.

Cada sessão (chamada de thread no Codex) tem um limite de informações que pode carregar. Esta é a janela de contexto (context window), que representa a quantidade total de conteúdo que o modelo consegue "lembrar" de uma só vez. Quando ela fica cheia, as informações mais antigas são compactadas ou descartadas, e a qualidade das respostas começa a cair.

Analogia: Uma mesa de escritório. O espaço da mesa é limitado. Se você espalhar as três pastas de documentos necessárias para a tarefa atual, trabalhará com facilidade. Se você despejar todas as centenas de documentos do armário de arquivos sobre a mesa, não conseguirá encontrar o que precisa. A janela de contexto do Codex é essa mesa: quanto mais precisa for a alimentação, mais focado ele estará; se você jogar o repositório inteiro, ele acabará se perdendo em meio a informações irrelevantes.

Para gerenciá-la bem, lembre-se destas três técnicas:

Primeira técnica: use @ para indicar os arquivos com precisão, não deixe que ele procure às cegas pelo repositório. Se você sabe quais arquivos precisam ser alterados, use o @ para apontá-los diretamente. Ele não gastará contexto fazendo buscas exaustivas com grep, sendo muito mais rápido e preciso. Um dos motivos do meu problema naquela tarde foi que eu não indiquei os arquivos, e ele leu sete ou oito módulos irrelevantes antes de encontrar o local correto — e todo aquele conteúdo desnecessário ocupou espaço na "mesa".

Segunda técnica: use /compact se a sessão ficar muito longa. Quando uma conversa se estende, o conteúdo anterior acumula bastante. O comando /compact instrui o Codex a resumir e compactar o contexto inicial em uma versão simplificada, liberando espaço para continuar trabalhando. Como indicado na documentação oficial, o Codex realiza essa compactação automaticamente quando necessário, mas usar /compact manualmente permite limpar o espaço de forma proativa antes que ele comece a falhar.

Terceira técnica, e que a equipe oficial enfatiza repetidamente: uma sessão por tarefa, não mantenha a mesma sessão aberta o dia todo. A seção de "Erros Comuns" da documentação oficial aponta explicitamente que usar "uma sessão por projeto" em vez de "uma sessão por tarefa" torna o contexto cada vez mais inflado, degradando os resultados obtidos.

Eu mesmo adoto uma regra rígida hoje em dia: assim que uma demanda é concluída, abro uma nova sessão para o próximo requisito não relacionado. Os comandos relacionados na CLI são muito práticos:

/compact    Compacta o contexto inicial da sessão atual em um resumo para liberar espaço
/status     Exibe o status da sessão atual, incluindo quanto contexto ainda resta
/fork       Cria uma nova ramificação baseada na sessão atual, mantendo o histórico original
/resume     Restaura uma sessão salva anteriormente

Um princípio de julgamento: o contexto deve ser "preciso", não "abundante". Mantenha o mesmo problema na mesma sessão para preservar a cadeia de raciocínio; se a tarefa realmente se ramificar, use o /fork ou abra uma nova conversa.

O critério de decisão é simples: se ainda for a continuação do mesmo problema, permaneça na sessão original; se mudou para uma tarefa não relacionada, abra uma nova. Não se apegue ao "histórico de conversas"; um contexto inflado trará resultados piores, o que não vale a pena.

💡 Resumo em uma frase: O contexto deve ser preciso, não volumoso. Usar @ para enviar arquivos com precisão, aplicar /compact para comprimir a tempo e manter uma sessão por tarefa são as três ferramentas essenciais para gerenciar a janela de contexto.

---

04 Reduzir a Marcha Conforme a Tarefa: Não Use o Modelo Top de Linha para Tarefas Simples

Esta seção complementa o artigo anterior — já detalhamos bastante a escolha de modelos lá, então aqui trazemos apenas a perspectiva de "aceleração".

Analogia: Escolha de transporte para o dia a dia. Você não vai tirar o carro da garagem para comprar uma garrafa de água na esquina, basta caminhar um pouco; por outro lado, você não vai viajar para outra cidade de bicicleta compartilhada. A dificuldade da tarefa determina quanto poder de processamento alocar, da mesma forma que a distância determina a escolha do meio de transporte.

Indo para a prática, a regra é uma só: tarefas simples e de escopo bem definido devem rodar em marcha reduzida. As sugestões de intensidade de inferência fornecidas nas "Melhores Práticas" oficiais são bem claras:

• Tarefas rápidas e de escopo definido: use low (ou até menos para tarefas ainda mais simples)
• Alterações complexas e depuração: use medium ou high
• Tarefas longas, pesadas e que exigem muito raciocínio: somente nestas use xhigh

O mesmo se aplica ao nível do modelo: para tarefas triviais ou sondagens feitas por sub-agentes, o modelo leve gpt-5.4-mini é suficiente, sem necessidade de acionar o modelo topo de linha gpt-5.5 para tudo. Para corrigir erros de digitação (typos), alterar o nome de uma variável ou realizar uma busca simples, reduzir para gpt-5.4-mini + low é mais rápido e economiza créditos.

No meu arquivo ~/.codex/config.toml pessoal, o padrão é configurado para a marcha intermediária, e só subo temporariamente na sessão quando enfrento problemas complexos. Não cometa o erro que eu cometia de fixar o padrão em gpt-5.5 + xhigh — esperar um minuto de "reflexão profunda" dele apenas para mudar o nome de uma variável é uma tolice que eu já experimentei. Para saber como configurar detalhadamente e ver os quatro modos de alternância, consulte o artigo 30.

💡 Resumo em uma frase: Rode tarefas simples em marchas mais baixas. Usar gpt-5.4-mini + low é rápido e econômico; reserve o modelo topo de linha para os problemas realmente complexos.

---

05 Trabalhando em Paralelo: Execute Múltiplas Linhas ao Mesmo Tempo

As quatro seções anteriores focaram em fazer uma única linha de trabalho fluir melhor. Esta seção muda a perspectiva — não fique esperando passivamente que uma única tarefa termine, coloque várias para rodar em paralelo.

A documentação oficial traz um ponto bem direto em "Erros Comuns": tratar o Codex como uma ferramenta que você precisa monitorar passo a passo, em vez de um parceiro de trabalho paralelo, é um erro típico de iniciantes. Você pode perfeitamente deixá-lo trabalhando em uma refatoração em segundo plano enquanto continua desenvolvendo outras coisas.

Mas há uma armadilha — nunca permita que duas linhas de trabalho alterem o mesmo conjunto de arquivos simultaneamente. Elas entrarão em conflito e bagunçarão sua área de trabalho. A solução oficial para isso é o uso de git worktrees (árvores de trabalho), abordado em detalhes no artigo 25.

Analogia: Várias equipes de reforma trabalhando ao mesmo tempo. Para que eletricistas, carpinteiros e pintores trabalhem simultaneamente, cada equipe deve ocupar um cômodo diferente, evitando que fiquem se esbarrando no mesmo espaço. O recurso de worktree funciona como se desse um "cômodo" independente para cada linha de trabalho, garantindo que não interfiram entre si.

Trabalhar em paralelo envolve duas abordagens comuns, correspondendo aos artigos abordados anteriormente:

Abordagem	Como isolar	Artigo correspondente
Executar múltiplos trabalhos simultaneamente	Um git worktree para cada linha de trabalho, cada um em um diretório independente	Artigo 25: worktrees
Linha principal + Sub-tarefas	O agente principal foca no problema central e delega a exploração, escrita de testes e depuração para sub-agentes	Artigo 21: subagents

A recomendação oficial para sub-agentes (subagents) é: deixe o agente principal focado no problema central e delegue tarefas com escopo bem definido — como explorar código, escrever testes e depurar erros — para que os sub-agentes as resolvam. Sem interrupções por essas tarefas secundárias na linha principal, o processo como um todo acelera.

Quando trabalho em demandas um pouco maiores, meu hábito atual é: avançar na lógica central pela sessão principal e, ao mesmo tempo, abrir outro worktree para deixar o Codex rodar los testes e o lint. (Wait! "deixar o Codex rodar los testes" -> "deixar o Codex rodar os testes". Let me correct this: "deixar o Codex rodar os testes e o lint".) Quando termino minha linha principal, os resultados das verificações dele já estão praticamente prontos. Conduzir as duas ações em paralelo economiza muito mais tempo do que fazê-low de forma sequencial. (Wait! "fazê-low" -> "fazê-las". Let me correct it: "do que fazê-las de forma sequencial".)

💡 Resumo em uma frase: Execute múltiplas tarefas em paralelo, usando worktrees para isolamento e sub-agentes para tarefas de escopo definido, mas nunca permita que duas linhas de trabalho alterem o mesmo conjunto de arquivos ao mesmo tempo.

---

06 Permita que Ele Se Auto-valide: Reduza as Rodadas de Confirmação Manual

A última técnica, que também é a mais negligenciada e que oferece o maior retorno, é: deixe o Codex validar o próprio trabalho, evite verificar tudo manualmente com os próprios olhos.

Voltando à mentalidade da primeira seção: o retrabalho é o maior gargalo. E as suas idas e vindas de confirmação manual também geram lentidão. Ele termina a alteração, você abre o arquivo para verificar linha por linha, encontra algo incorreto, pede para ajustar novamente — esse ciclo de revisões manuais consome muito tempo.

A documentação oficial deixa claro: o Codex apresenta um desempenho muito melhor quando é capaz de validar seu próprio trabalho, mas a premissa é que ele precisa saber como é um resultado correto. Essa definição de sucesso deve vir no seu prompt ou no arquivo de instruções do projeto AGENTS.md.

Analogia: Lista de checagem antes de entregar uma tarefa. Quando delega um trabalho a um assistente, se você anexar uma lista do tipo "verifique estes cinco itens antes da entrega", ele fará uma auto-revisão antes de entregar, e você só precisará fazer uma inspeção por amostragem. Se não houver essa lista, você precisará encontrar os erros linha por linha, tornando-se o gargalo. Fornecer critérios de aceitação ao Codex é exatamente o mesmo que entregar a ele essa lista de checagem.

Mais especificamente, deixe-o realizar estas ações por conta própria (extraídas das "Melhores Práticas" oficiais):

• Escrever ou atualizar testes para as alterações feitas
• Executar a suite de testes correspondente
• Executar lint, formatação e checagem de tipos
• Confirmar se o comportamento final atende aos seus requisitos
• Fazer uma revisão por conta própria do diff, procurando bugs, regressões ou trechos de código perigosos

Há um comando muito prático na CLI, o /review, que permite realizar revisões no estilo Pull Request com base em uma branch de referência, analisar alterações não integradas ou revisar conforme regras customizadas definidas por você.

Uma solução definitiva: escreva "como definir a conclusão do trabalho" e "quais testes executar" no arquivo AGENTS.md. Dessa forma, ele seguirá automaticamente essas validações em todas as execuções, sem que você precise repetir isso em cada prompt. Esse ponto foi detalhado no artigo 11.

Minha ação padrão atualmente é incluir no prompt uma instrução como: "execute o pytest após as alterações e me avise apenas quando estiver tudo verde". Ele executa as validações e retorna somente quando os testes passam, poupando-me de ciclos desgastantes como "ele diz que está pronto → eu rodo os testes → os testes falham → peço para ele corrigir". Em suma, delegar a etapa de validação a ele é o que realmente liberta você da necessidade de monitorá-lo constantemente.

💡 Resumo em uma frase: Definir critérios de aceitação e permitir que o Codex execute os próprios testes e reviews elimina as etapas de confirmação manual, sendo esta a técnica de aceleração que oferece o maior retorno.

---

07 Apenas uma Observação: Recursos Secundários Como o Modo Rápido

As seis seções anteriores formam a base. Esta seção é apenas um complemento rápido.

O Codex possui o modo rápido (Fast mode), que pode acelerar os modelos compatíveis em cerca de 1,5 vez, ao custo de um consumo maior de créditos. De acordo com as especificações oficiais, ele atualmente suporta o GPT-5.5 e o GPT-5.4; usar o modo rápido no GPT-5.5 consome créditos à taxa de 2,5 vezes o valor padrão, enquanto no GPT-5.4 a taxa é de 2 vezes.

Você pode ativar, desativar e verificar o status na CLI usando estes comandos:

/fast on        Ativa o modo rápido
/fast off       Desativa
/fast status    Verifica o status atual

Se quiser que ele fique ativado por padrão, você pode persistir a configuração em ~/.codex/config.toml:

service_tier = "fast"

[features]
fast_mode = true

Atenção a dois pré-requisitos: o primeiro é que o modo rápido está disponível apenas para conexões autenticadas via ChatGPT; se você estiver utilizando uma chave de API (API key), a tarifação seguirá a tabela da API padrão e o recurso não estará disponível. O segundo é que essa velocidade tem um custo adicional em créditos, não é gratuita.

Para ser sincero, o modo rápido é uma melhoria de fim de linha, não o prato principal. O tempo economizado com as seis seções anteriores (detalhar prompts, gerenciar o contexto, reduzir a marcha das tarefas, paralelizar e auto-validar) é medido em "rodadas inteiras de retrabalho", enquanto o modo rápido economiza apenas aquele fator de 1,5 vez em cada resposta individual. Certifique-se de aplicar as seis técnicas anteriores corretamente antes de decidir gastar mais créditos por essa velocidade extra. Eu mesmo não o mantenho ativo por padrão, usando o /fast on apenas em situações de urgência em que a tarefa justifique o custo.

💡 Resumo em uma frase: O modo rápido troca créditos por uma velocidade 1,5 vez maior, servindo apenas como um detalhe adicional; as seis técnicas anteriores economizam retrabalhos inteiros, portanto, foque nelas primeiro.

---

08 Exercício Prático: Reescrevendo um Prompt Vago no Formato de Quatro Seções

Apenas ler sem praticar não fixará o conhecimento. Dedique cinco minutos a este exercício para sentir a diferença real entre "dar certo de primeira" e "passar por retrabalhos sucessivos".

Passo 1: Encontre um prompt vago que você costuma digitar no dia a dia. Por exemplo:

Me ajude a adicionar um sistema de logs a este projeto

Passo 2: Reescreva o prompt no formato de quatro seções, seguindo a receita da seção 02. Preencha mentalmente (ou digite diretamente) estes quatro campos:

Objetivo: Adicionar uma ferramenta de log unificada ao projeto, capaz de registrar saídas nos níveis INFO/ERROR tanto no console quanto em um arquivo.
Contexto: Consultar a leitura de configurações em @utils/config.py, definindo o nível do log com base nas configurações existentes.
Restrições: Utilizar a biblioteca padrão logging do Python, sem adicionar dependências externas; não alterar nenhuma assinatura de função existente.
Aceitação: Ser capaz de importar (import) a ferramenta no ponto de entrada main e registrar um log INFO em logs/app.log, verificando a criação correta do arquivo.

Passo 3: Envie as duas versões separadamente para o Codex e conte as rodadas. Primeiro, abra uma sessão e envie a versão vaga. Aguarde até que ela seja concluída (observe se ele fará perguntas adicionais ou se tomará decisões por conta própria) e conte quantas rodadas foram necessárias até atingir um resultado satisfatório. Em seguida, abra uma nova sessão, envie a versão em quatro seções e faça o mesmo controle.

O que é esperado que você observe:

• Versão vaga: O Codex provavelmente começará perguntando coisas como "onde salvar a saída", "quais níveis usar" ou "qual biblioteca utilizar", ou simplesmente adotará uma abordagem que talvez não seja a que você deseja. Geralmente, isso exigirá 3 ou mais rodadas de conversa.
• Versão de quatro seções: Ele irá direto ao ponto, entregando a tarefa em 1 ou 2 rodadas na maioria das vezes, e o resultado final estará muito mais alinhado às suas expectativas.

O objetivo principal deste exercício não é a contagem exata de rodadas, mas sim fazer você perceber na prática: as quatro linhas a mais que você digita economizam várias interações e correções posteriores. Esse investimento de tempo sempre vale a pena.

Após concluir este exercício, adicione suas diretrizes de restrição e critérios de aceitação favoritos no arquivo AGENTS.md para que essas regras fiquem registradas em definitivo, evitando ter de digitá-las manualmente no futuro.

💡 Resumo em uma frase: Ao executar as versões vaga e em quatro seções separadamente e comparar o número de rodadas, você verá claramente como digitar algumas linhas a mais elimina o retrabalho.

---

Resumo

Este artigo buscou afastar a ideia de que "aceleração" se resume a "mudar para um modelo mais rápido", direcionando o foco para as seis ações que realmente poupam tempo:

• Mentalidade: Menos retrabalho > buscar velocidade cegamente; fazer certo de primeira é o que mais economiza tempo.
• Detalhamento do prompt: Objetivo + Contexto + Restrições + Critérios de Aceitação; cada palavra economizada é algo que o Codex terá de adivinhar.
• Gerenciamento de contexto: Usar @ para arquivos precisos, /compact para compressão e uma sessão dedicada por tarefa.
• Marcha conforme a tarefa: Tarefas simples com gpt-5.4-mini + low, reservando o modelo topo de linha para desafios reais.
• Paralelização: Isolamento por worktree e delegação a sub-agentes, sem permitir que duas linhas modifiquem os mesmos arquivos.
• Auto-validação: Fornecer critérios de aceitação e deixar que ele execute os testes e o review por conta própria, reduzindo as confirmações manuais.
• Recursos adicionais como o modo rápido funcionam como complementos; domine as seis técnicas anteriores antes de adotá-los.

Agora você deve ser capaz de: ao receber uma demanda, passar mentalmente pela receita de quatro seções em vez de simplesmente digitar uma frase vaga; usar @ e /compact para manter o contexto preciso e limpo; saber quando reduzir a marcha para tarefas simples, rodar tarefas em paralelo e permitir que o Codex se auto-valide. Ao transformar essas práticas em memória muscular, sua produtividade diária aumentará visivelmente — não porque o modelo se tornou mais veloz, mas porque você parou de fazê-lo pegar o caminho errado.

---

O próximo artigo 〔32 Migrando do Claude Code〕 destina-se a um grupo específico de leitores: usuários experientes que estão migrando do Claude Code. A que se refere o arquivo CLAUDE.md nesta nova plataforma? Como transpor conceitos como modos de permissão, Skills e sub-agentes? Quais hábitos podem ser mantidos e quais precisam de ajustes? Uma breve reflexão — qual hábito que você adquiriu no Claude Code pode acabar atrapalhando você ao usar o Codex? Descobriremos no próximo artigo.

---

Leituras Recomendadas

• Glossário
• Gestão e Governança Corporativa: Uso individual versus corporativo
• Integração com Slack / Linear e SDK: Invocando o Codex de outras plataformas para embuti-lo em seu próprio produto